Tous les quelques années, une vulnérabilité débarque avec une telle surface d'attaque qu'elle force l'industrie entière à patcher dans l'urgence. En 2021, c'était Log4Shell. Fin 2025, c'est React2Shell — officiellement CVE-2025-55182, une exécution de code à distance pré-authentification notée CVSS 10.0 qui frappe le cœur de React Server Components (RSC) et, par ricochet, l'immense écosystème Next.js. Six mois après sa divulgation, elle reste activement exploitée : c'est précisément ce qui en fait un cas d'école que tout développeur web déployant du React 19 doit comprendre.
Le surnom n'est pas une coquetterie marketing. Comme Log4Shell, React2Shell coche toutes les cases du cauchemar : une seule requête HTTP suffit, les configurations par défaut sont vulnérables, l'exploit est fiable à près de 100 %, et le code malveillant s'exécute sans authentification. Décortiquons la cause racine, la chaîne d'attaque réelle observée sur le terrain, et la seule remédiation qui tienne la route.
De quoi parle-t-on exactement ?
CVE-2025-55182 (qui englobe également CVE-2025-66478, l'identifiant côté Next.js) est une vulnérabilité de désérialisation non sécurisée dans le traitement du protocole interne de React Server Components. Elle permet à un attaquant non authentifié d'exécuter des commandes système arbitraires sur le serveur via une charge utile HTTP spécialement construite.
La faille a été signalée de façon responsable par le chercheur en sécurité Lachlan Davidson le 29 novembre 2025. Le correctif et la divulgation publique sont intervenus le 3 décembre 2025. La transition vers l'exploitation active a été foudroyante : la télémétrie de plusieurs éditeurs montre un passage de la divulgation à l'exploitation de masse en quelques heures, scanners automatisés et opérateurs manuels confondus.
Cause racine : le protocole « Flight » et la désérialisation
Pour comprendre la faille, il faut comprendre comment fonctionne RSC. React Server Components permet d'exécuter une partie de la logique de rendu sur le serveur plutôt que dans le navigateur, ce qui allège le client et améliore les performances. Pour transférer les arbres de composants et les appels de fonctions serveur entre client et serveur, RSC s'appuie sur un protocole de sérialisation interne baptisé « Flight ».
C'est là que tout se joue. La vulnérabilité réside dans le package react-server et sa gestion du protocole Flight : lorsqu'il reçoit une charge utile RSC malformée, le serveur ne valide pas correctement la structure avant de la désérialiser. Cette désérialisation logique, combinée à des chemins d'exécution de commandes dans le traitement des requêtes RSC, ouvre la voie à l'exécution de code arbitraire. On retrouve le schéma classique des grandes RCE de désérialisation : une donnée contrôlée par l'attaquant est traitée comme du code de confiance.
Pourquoi c'est si dangereux
Ce qui transforme un bug en catastrophe industrielle, c'est qu'il touche les configurations par défaut :
- Une application Next.js standard générée avec
create-next-appet compilée pour la production est exploitable sans aucune modification de code par le développeur. - Les server actions, activées par défaut et accessibles via des routes connues, exposent le vecteur sans que l'équipe en ait conscience.
- L'exploit affiche une fiabilité proche de 100 % et accepte une grande variété de formats de charge utile, ce qui complique le filtrage par signature.
- La simple présence d'un package vulnérable dans l'arbre de dépendances suffit souvent à rendre le système exploitable.
Versions affectées et correctifs
Le périmètre est large, à la hauteur de l'adoption de React 19.
| Composant | Versions vulnérables | Versions corrigées |
|---|---|---|
| React | 19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1 |
| Next.js | 15.0.0 à 16.0.6 | Correctifs 15.x / 16.x publiés |
| Autres frameworks RSC | React Router, Waku, RedwoodSDK, Parcel, plugins Vite RSC — tout ce qui embarque react-server | |
La recherche communautaire intensive qui a suivi la divulgation a d'ailleurs fait émerger trois vulnérabilités React supplémentaires (CVE-2025-55183, CVE-2025-55184 et CVE-2025-67779), d'impact plus limité (divulgation d'informations, déni de service). À noter : CVE-2025-67779 est née d'un correctif incomplet pour CVE-2025-55184 — un rappel que patcher à moitié peut rouvrir une porte.
La chaîne d'attaque observée sur le terrain
Les attaquants ciblent en priorité les frontends Next.js exposés à internet et les charges de travail RSC tournant en environnement cloud : clusters Kubernetes, plateformes PaaS managées. Si vous opérez ce type de stack, l'article sur le durcissement de Kubernetes 1.36 donne le contexte de défense en profondeur pertinent ici.
Phase 1 — Reconnaissance
Une fois le shell obtenu dans un conteneur ou une VM, les opérateurs profilent l'hôte : whoami, hostname, vidage des variables d'environnement, lecture de /etc/passwd. S'ensuit un beaconing DNS et HTTP via des domaines de type OAST pour vérifier la connectivité sortante et cartographier l'environnement.
Phase 2 — Installation des charges utiles
Les attaquants déploient ensuite des scripts via wget, curl, chmod et BusyBox, souvent avec des commandes encodées en Base64. Au menu : droppers Linux pour persistance, loaders Mirai, et — de loin les plus fréquents — des mineurs de cryptomonnaie XMRIG.
Phase 3 — Acteurs et objectifs
Le spectre des attaquants est large. Le Google Threat Intelligence Group a observé une exploitation généralisée allant de cybercriminels opportunistes à des groupes d'espionnage présumés, avec des campagnes déployant un tunneleur MINOCAT, un downloader SNOWLIGHT, et les backdoors HISONIC et COMPOOD. Microsoft a détecté de l'activité dès le 5 décembre 2025, majoritairement des coin miners. Unit 42 (Palo Alto) a documenté un acteur plus sophistiqué, CL-STA-1015 — un courtier en accès initial soupçonné de liens avec le Ministère de la Sécurité d'État chinois — installant les chevaux de Troie SNOWLIGHT et VShell. Wiz, de son côté, a observé un pivot vers le vol de credentials cloud et le minage.
Remédiation : le WAF ne vous sauvera pas
C'est le point le plus mal compris de cet épisode. Un pare-feu applicatif (WAF) n'est qu'un palliatif temporaire. Comme l'exploit accepte de multiples formats de charge utile, les attaquants contournent trivialement le blocage par signature. Les règles WAF achètent du temps, elles ne garantissent rien.
La seule correction fiable tient en deux mots : patcher et redéployer, immédiatement. Concrètement :
- Inventoriez vos dépendances :
npm ls react react-dom nextsur chaque projet, y compris les dépendances transitives. - Mettez à jour vers React 19.0.1 / 19.1.2 / 19.2.1 et la version Next.js corrigée correspondante, puis rebuildez et redéployez en production (un simple
npm updatesans rebuild ne protège pas un artefact déjà compilé). - Chassez la compromission : recherchez des processus
xmrig, des connexions sortantes vers des domaines OAST inconnus, des binaires déposés dans/tmp, des cron jobs suspects. Une RCE exploitée signifie qu'il faut auditer l'hôte, pas seulement patcher. - Faites tourner tout secret accessible depuis le conteneur compromis (clés cloud, tokens) — le vol de credentials a été observé.
Sachez enfin que la barrière à l'exploitation est au plus bas : un dépôt d'exploit public et un template Nuclei officiel circulent désormais. Tout serveur encore vulnérable est une cible à portée de scan automatisé. Pour le durcissement plus large de vos hôtes, voir la checklist de sécurisation d'un serveur Linux.
FAQ
Mon application Next.js est-elle vulnérable si je n'utilise pas explicitement les Server Components ?
Potentiellement oui. Le danger de React2Shell vient justement du fait que RSC et les server actions sont activés par défaut dans les configurations modernes de Next.js (App Router). Une application générée avec create-next-app et déployée telle quelle peut être exposée. Ne partez pas du principe que « je ne m'en sers pas » vous protège : vérifiez les versions installées et patchez. La présence du package vulnérable dans l'arbre de dépendances suffit souvent.
Un WAF ou Cloudflare peut-il bloquer l'exploitation en attendant le patch ?
Partiellement et temporairement seulement. Les règles managées des grands fournisseurs bloquent les charges utiles connues, mais l'exploit accepte de nombreuses variantes qui contournent le filtrage par signature. Traitez le WAF comme un gain de quelques heures pour patcher, jamais comme une protection durable. La seule remédiation fiable reste la mise à jour des packages et le redéploiement.
Comment savoir si mon serveur a déjà été compromis ?
Recherchez les indicateurs typiques de la post-exploitation : processus de minage (xmrig), pics de CPU inexpliqués, connexions sortantes vers des domaines OAST ou des infrastructures de C2 inconnues, binaires récents dans /tmp, modifications de crontab, et tentatives de lecture de /etc/passwd ou de dump de variables d'environnement dans vos logs applicatifs. En cas de doute, considérez l'hôte comme compromis : isolez-le, faites tourner les secrets et reconstruisez à partir d'une image saine.
Pourquoi compare-t-on React2Shell à Log4Shell ?
Parce qu'ils partagent l'ADN des RCE catastrophiques « one-shot » : un chemin de désérialisation, une surface d'attaque massive (un écosystème omniprésent), des prérequis minimaux pour l'attaquant et un déclenchement par une simple requête. Log4Shell avait montré qu'une faille de désérialisation pouvait menacer l'infrastructure mondiale presque du jour au lendemain. React2Shell rejoue le scénario sur l'écosystème JavaScript, où Next.js équipe une part énorme des applications web récentes.
Conclusion : la désérialisation, encore et toujours
React2Shell rappelle une leçon que l'industrie réapprend à chaque cycle : désérialiser une donnée non fiable, c'est lui donner le droit de s'exécuter. Le protocole Flight de RSC n'a fait qu'ajouter une nouvelle façade à un anti-pattern aussi vieux que les RPC. Que la faille touche les configurations par défaut d'un framework aussi répandu que Next.js en fait l'un des incidents de sécurité web les plus marquants depuis Log4Shell.
La bonne nouvelle, c'est que la remédiation est simple et connue : mettre à jour, rebuilder, redéployer, auditer. La mauvaise, c'est que six mois après la divulgation, des scanners continuent de trouver des cibles — preuve que la chaîne d'approvisionnement logicielle reste notre maillon faible collectif. Si vous opérez du React 19 en production et que vous n'avez pas vérifié vos versions depuis décembre, faites-le maintenant : la fenêtre entre « exposé » et « miné » se compte en heures.
Commentaires