1. Aperçu de la vulnérabilité

Ces derniers jours, une vulnérabilité RCE par désérialisation dans React a fait grand bruit, le CVSS officiel atteignant directement 10.0, au même niveau que Log4j à l'époque. De nombreuses rumeurs ont rapidement circulé, affirmant qu'il s'agissait du Log4j du développement web moderne, provoquant la panique chez les développeurs de nombreuses entreprises. Ainsi, tout le monde s'est réveillé en se précipitant pour consulter la documentation et appliquer des correctifs... En parallèle, des voix critiques se sont élevées en ligne : après des tests, certains ont constaté que la vulnérabilité n'était pas aussi grave que décrite, et que son exploitation nécessitait certaines conditions. J'ai donc décidé de prendre le temps d'étudier cette vulnérabilité en profondeur.

1.1 Informations sur la vulnérabilité

• Identifiant CVE : CVE-2025-55182
• Score CVSS : 10.0 (Critique)
• Type de vulnérabilité : Pollution de la chaîne de prototypes → Exécution de code à distance
• Versions affectées : react-server-dom-webpack < 19.2.0, react-server-dom-turbopack < 19.2.0
• Périmètre d'impact : Applications utilisant React Server Components

---

2. Analyse du principe de la vulnérabilité

2.1 Cause racine de la vulnérabilité

La cause de cette vulnérabilité est la suivante : dans [email protected], la fonction clé permettant d'analyser une Server Action côté serveur est requireModule (pseudo-code) :

function requireModule(metadata) {
  var moduleExports = __webpack_require__(metadata[0]);
  // ...
  return "*" === metadata[2]
    ? moduleExports
    : "" === metadata[2]
      ? moduleExports.__esModule
        ? moduleExports.default
        : moduleExports
      : moduleExports[metadata[2]];  // ← Point vulnérable
}

2.2 Problème central de la vulnérabilité

Le cœur du problème réside dans la partie moduleExports[metadata[2]] : aucune validation n'est effectuée sur metadata[2], ce qui permet à un attaquant d'accéder non seulement aux propriétés exportées du module, mais aussi aux propriétés de la chaîne de prototypes (telles que constructor, __proto__, etc.). Lorsque l'attaquant construit metadata[0] (par exemple en le pointant vers vm), il peut ensuite construire metadata[2] pour exporter une méthode dangereuse d'un module spécifique, comme vm.runInThisContext, et ainsi exploiter la vulnérabilité.

---

3. Analyse de l'exploitation de la vulnérabilité

Pour mon analyse, je me suis référé à l'environnement de test et à l'exploit fournis par ejpir, en prenant l'exemple du gadget vm_runInThisContext (code exécution). Voici le processus (attention : dans un environnement réel, le processus d'exploitation peut différer !) :

Étape 1 : Réception de la requête

Tout d'abord, après avoir envoyé une requête avec le payload, on place un point d'arrêt à l'endroit où la requête est récupérée :

Étape 2 : Analyse des données du formulaire

Ensuite, le programme atteint la ligne const formData = parseMultipart(buffer, boundaryMatch[1]);, on entre dans parseMultipart :

parseMultipart extrait les données du corps de la requête et les retourne dans formData :

Étape 3 : Appel à decodeAction (point d'entrée de la vulnérabilité)

On entre dans const actionFn = await decodeAction(formData, serverManifest); Emplacement de la vulnérabilité :

On entre dans loadServerReference :

Étape 4 : Code central de la vulnérabilité – requireModule

Nous arrivons maintenant à l'emplacement central du code vulnérable requireModule, on entre :

La valeur de id est divisée par # : la partie avant le # sert de module, la partie après de méthode, et la valeur de bound est passée comme argument de la méthode :

Étape 5 : Exécution du Payload

On entre dans actionFn pour exécuter le payload final :

L'exploitation est terminée !

---

4. Résumé et défense

Cette vulnérabilité est toujours due à un contrôle insuffisant des entrées, comme pour Log4j et fastjson. Dans mon test ci-dessus, j'ai utilisé vm_runInThisContext, mais en réalité cette vulnérabilité dispose de plusieurs gadgets exploitables, par exemple :

• vm#runInThisContext
• vm#runInNewContext
• child_process#execSync
• child_process#execFileSync
• child_process#spawnSync
• fs#readFileSync
• fs#writeFileSync
• #constructor
• #__proto__
• #prototype

Un attaquant peut exploiter cette vulnérabilité pour :

• Exécution de code à distance (RCE) : via vm#runInThisContext ou child_process#execSync pour exécuter des commandes système arbitraires
• Opérations sur le système de fichiers : via fs#readFileSync, fs#writeFileSync pour lire/écrire des fichiers arbitraires
• Attaque persistante : écriture de clés publiques SSH, modification de .bashrc, remplacement de fichiers d’application, etc.
• Fuites d’informations : lecture de fichiers de configuration sensibles (.env, clés privées, identifiants de base de données, etc.)

Sur cette base, voici les mesures de défense associées :

1. Défense temporaire

On peut mettre en place des règles au niveau du WAF pour bloquer ces champs dangereux et ainsi intercepter les attaques malveillantes. On peut également effectuer un filtrage au niveau de nginx, comme suit :

# Exemple de configuration Nginx
location /formaction {
    # Bloquer les requêtes contenant des références de modules dangereux
    if ($request_body ~* "(vm#|child_process#|fs#|module#)") {
        return 403;
    }
    # Bloquer les tentatives de pollution de la chaîne de prototypes
    if ($request_body ~* "(#constructor|#__proto__|#prototype)") {
        return 403;
    }
}

2. Mise à jour rapide