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) :

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 :

2. Mise à jour rapide

L'éditeur a déjà publié un correctif de sécurité. Mettez immédiatement à jour vers une version sécurisée ! :

Versions corrigées :

• react-server-dom-webpack : >= 19.2.0
• react-server-dom-turbopack : >= 19.2.0
• next.js : >= 15.0.5

Lors de mon analyse de cette vulnérabilité, je me suis référé à l'exploit de whiteov3rflow, et j'ai développé un outil de détection pour l'environnement de test, que j'ai placé dans un dépôt GitHub : Les personnes souhaitant vérifier leur propre système peuvent y accéder (note : en raison de l'environnement de test de l'auteur d'origine, cet outil peut actuellement ne fonctionner que sur l'environnement de test d'origine. Une amélioration ultérieure est prévue. Ceux qui en ont besoin peuvent aussi le modifier eux-mêmes...). Attention : une autorisation légale est nécessaire pour l'utilisation ; toute utilisation non autorisée à des fins de destruction est interdite !

3. Prudence dans les propos et les actes !

À ce jour, le 5 décembre 2025, ce que j'ai pu voir en ligne, c'est que la « rumeur » concernant cette vulnérabilité a fluctué comme des montagnes russes : tantôt une « bombe nucléaire », tantôt une « faille anodine », puis à nouveau une « bombe nucléaire »... Les méthodes d'exploitation se multiplient. D'après les informations actuelles, la qualification de « bombe nucléaire » pourrait se confirmer, même si son périmètre d'impact est plus restreint que celui de Log4j. Quoi qu'il en soit, toutes les personnes concernées doivent mettre à jour au plus vite pour éliminer tout risque futur !!!

Un conseil de sécurité pour les développeurs : ne faites jamais confiance aux entrées utilisateur. Log4j, fastjson et maintenant cette RCE React ont tous été victimes de ce principe. Par conséquent, dans le développement réel, assurez-vous de valider strictement les points dangereux en utilisant des mécanismes comme des boîtes à sable ou des listes blanches, afin d'éviter des catastrophes !!!

Ce qu'on apprend dans les livres reste superficiel ; pour vraiment maîtriser une chose, il faut agir avec prudence.

Références

• Annonce officielle CVE-2025-55182
• Avis de sécurité React
• PoC GitHub par ejpir
• Documentation React Server Components