React2Shell est une vulnérabilité critique (CVSS 10) des React Server Components qui permet à un attaquant non authentifié d'exécuter du code à distance sur le serveur. Elle est référencée CVE-2025-55182, exploitée activement, et des correctifs sont disponibles. Si vous exploitez une application React 19 ou Next.js exposée, mettez à jour sans délai.
La faille a été découverte le 29 novembre 2025 par Lachlan Davidson. Contrairement à ce qu'on lit parfois, elle ne touche pas React cœur mais les paquets de rendu serveur (React Server Components), utilisés par de nombreux frameworks de l'écosystème.
Sont vulnérables les versions 19.0, 19.1.0, 19.1.1 et 19.2.0 des paquets suivants :
Les correctifs sont disponibles en versions 19.0.1, 19.1.2 et 19.2.1.
Plusieurs frameworks qui s'appuient sur ces paquets sont également concernés, notamment react-router, waku, @parcel/rsc, @vitejs/plugin-rsc et rwsdk. Leur exposition dépend uniquement de la version de React embarquée.
Lachlan Davidson a référencé une entrée dédiée à Next.js, car le framework n'intègre pas React comme une dépendance classique : il le distribue sous forme vendored, embarquée dans son propre code. Résultat, de nombreux outils d'analyse de dépendances ne détectent pas automatiquement la vulnérabilité. C'est un angle mort à surveiller de près dans vos audits de composition logicielle.
Cette entrée est référencée CVE-2025-66478 (considérée comme un doublon par la NVD). Les versions vulnérables de Next.js sont celles supérieures ou égales à 14.3.0-canary.77, ainsi que les branches 15 et 16. Des correctifs existent en v16.0.7, v15.5.7, v15.4.8, v15.3.6, v15.2.6, v15.1.9, v15.0.5, 15.6.0-canary.58 et 16.1.0-canary.12.
Les React Server Functions permettent au client de déclencher des appels de fonction côté serveur. React traduit ces appels en requêtes HTTP, que le serveur reconvertit en appels de fonction avant de renvoyer les données au client. Ce mécanisme repose sur le protocole React Flight.
React2Shell abuse du désérialiseur de React Flight pour faire exécuter du JavaScript arbitraire sur le serveur, à partir d'une réponse Flight malformée. L'attaque combine quatre propriétés du protocole :
.then et peut donc être attendu avec await.$... laissent l'utilisateur diriger la traversée de propriétés. Par exemple $1:constructor:constructor force React à évaluer chunk1.value.constructor.constructor, ce qui peut renvoyer Function..then() lors de l'attente. Si l'attaquant contrôle .then, il peut faire exécuter du code._response, ce qui permettait d'injecter une fausse structure interne.En combinant ces mécanismes, un attaquant atteint le constructeur Function() et obtient l'exécution de code, donc un shell sur le serveur. Nous décrivons ici le principe à des fins défensives, sans fournir de charge utile exploitable.
Pour rechercher des tentatives d'exploitation dans vos journaux et vos flux réseau, surveillez :
next-action ou rsc-action-id.$@.Next-Action ou des identifiants d'actions RSC.multipart/form-data contenant des marqueurs de charge utile Flight et des motifs resolved_model.Le CERT illicium a constaté que plusieurs acteurs exploitent cette vulnérabilité pour installer un cryptomineur, notamment du Monero via c3pool. Des campagnes ont été documentées publiquement (voir par exemple sebastianb929, duborges, SimoKohonen) ainsi que des listes de serveurs de commande et contrôle suivies par RedDrip7. Le vecteur permettant une RCE complète, l'objectif des attaquants ne se limite pas au minage : toute charge utile est envisageable.
Testez uniquement des actifs que vous exploitez ou que vous êtes autorisé à tester. Deux approches complémentaires :
La preuve de concept du chercheur Moritz Sanft, disponible sur GitHub, permet de confirmer si une application déployée en local est vulnérable. Un environnement Python isolé suffit :
python3 -m venv vpy3-poc
source vpy3-poc/bin/activate
pip install requestsLe script prend en premier argument l'URL cible, et en second argument optionnel la commande à exécuter (par défaut id). Sur une application vulnérable, il renvoie le résultat de la commande ; sinon, il retourne une erreur. Pour une vérification à l'échelle d'un parc, un template Nuclei est disponible et s'intègre à un scan automatisé.
La priorité est claire : mettez à jour React (19.0.1, 19.1.2 ou 19.2.1 selon votre branche) et Next.js vers une version corrigée. Compte tenu de la distribution vendored de React dans Next.js, ne vous fiez pas uniquement à votre gestionnaire de dépendances : vérifiez la version réellement embarquée. En attendant le déploiement, filtrez au niveau du reverse proxy ou du WAF les requêtes présentant les indicateurs ci-dessus, et surveillez vos serveurs pour détecter un mineur ou un processus anormal.
Une vulnérabilité de ce type illustre pourquoi la gestion des vulnérabilités doit être continue et non ponctuelle. Notre plateforme VOC détecte les composants exposés dans votre surface d'attaque, priorise selon le risque réel et suit la correction dans le temps. Notre veille vous alerte dès la publication d'une faille critique comme celle-ci, avant qu'elle ne soit exploitée chez vous. Pour évaluer votre exposition, demandez un diagnostic.