React2Shell : anatomie d'une faille qui a paralysé 28 % du web mondial

Une vulnérabilité critique au score CVSS maximal de 10.0 dans React Server Components a provoqué l’une des plus importantes crises de cybersécurité de l’écosystème JavaScript, révélant les fragilités structurelles d’une infrastructure web devenue dangereusement interdépendante.

Une découverte aux conséquences mondiales

Le 29 novembre 2025, le chercheur en sécurité Lachlan Davidson a transmis à l’équipe de Meta une information qui allait déclencher l’une des mobilisations les plus intenses de l’histoire récente de la cybersécurité. La faille qu’il avait identifiée dans les React Server Components (RSC) permettait à un attaquant non authentifié d’exécuter du code arbitraire sur un serveur distant par le simple envoi d’une requête HTTP malveillante. Aucune interaction utilisateur requise, aucune authentification préalable, une exploitation triviale : le triptyque parfait d’une vulnérabilité catastrophique.

Le 3 décembre 2025, l’équipe React et Vercel ont procédé à une divulgation coordonnée, publiant simultanément les correctifs et les avis de sécurité. La vulnérabilité s’est vu attribuer l’identifiant CVE-2025-55182 et un score CVSS de 10.0, le maximum possible. Ce score n’est attribué que très rarement et signale une menace de la plus haute gravité. Dans le jargon des experts, il s’agit d’une faille de type « game over » : une seule requête suffit à compromettre totalement un système.

Encadré : Qu’est-ce que le score CVSS ?

Le Common Vulnerability Scoring System (CVSS) est un standard international permettant d’évaluer la gravité des vulnérabilités informatiques sur une échelle de 0 à 10. Un score de 10.0 indique une vulnérabilité exploitable à distance, sans authentification, sans interaction utilisateur, avec un impact complet sur la confidentialité, l’intégrité et la disponibilité du système ciblé.

Le protocole Flight au cœur du problème

Pour comprendre la nature de cette vulnérabilité, il est nécessaire de revenir sur l’architecture des React Server Components, une innovation introduite avec React 19. Cette technologie permet d’exécuter certains composants directement sur le serveur plutôt que dans le navigateur de l’utilisateur, réduisant ainsi la quantité de JavaScript envoyée au client et améliorant les performances des applications web.

La communication entre le client et le serveur dans cette architecture repose sur un protocole de sérialisation appelé « Flight ». Ce protocole encode les structures de données complexes en un format transmissible via HTTP, puis les désérialise côté serveur pour reconstituer les objets JavaScript d’origine.

La faille réside précisément dans ce mécanisme de désérialisation. Lorsque le serveur reçoit une charge utile RSC spécialement conçue, il échoue à valider correctement la structure des données entrantes. Cette absence de validation permet à un attaquant d’injecter des clés malveillantes dans la charge utile, de polluer la chaîne de prototypes JavaScript et, in fine, d’influencer le flux d’exécution côté serveur. Dans les versions vulnérables de React, cette pollution de prototype peut être enchaînée jusqu’à l’exécution de fonctions natives de Node.js comme child_process.execSync, ouvrant la voie à l’exécution de commandes shell arbitraires.

L’aspect particulièrement préoccupant de cette vulnérabilité tient au fait que l’exploitation se produit durant la phase de désérialisation, c’est-à-dire avant même la validation de l’action serveur demandée. Il suffit qu’une requête HTTP contienne un en-tête Next-Action avec n’importe quelle valeur pour déclencher le chemin de code vulnérable. Une application peut donc être compromise même si elle n’implémente explicitement aucune fonction serveur, dès lors qu’elle prend en charge les React Server Components.

L’ampleur de la surface d’attaque

L’écosystème React domine le paysage du développement web moderne. Selon l’enquête State of JavaScript 2024, React est utilisé par 82 % des développeurs JavaScript. Le framework Next.js, qui intègre nativement les React Server Components dans son routeur d’application (App Router), constitue le framework serveur le plus populaire de l’écosystème React.

Les données collectées par différents organismes de sécurité dessinent une surface d’attaque considérable. Phoenix Security a rapporté 584 086 systèmes React et 754 139 instances Next.js référencées dans Shodan. Wiz a constaté que 39 % des environnements cloud contenaient des instances de React ou Next.js dans des versions vulnérables. Censys a estimé à environ 2,15 millions le nombre de services exposés sur Internet potentiellement affectés.

Encadré : Les produits et frameworks concernés

La vulnérabilité affecte les versions suivantes :

React : versions 19.0.0, 19.1.0, 19.1.1 et 19.2.0 des packages react-server, react-server-dom-webpack, react-server-dom-turbopack, react-server-dom-parcel et react-server-dom-esm.

Next.js : versions 15.x et 16.x utilisant l’App Router.

Autres frameworks : React Router, Waku, RedwoodSDK, plugins RSC de Parcel et Vite.

Les bibliothèques react et react-dom ne sont pas concernées car elles n’incluent pas le protocole Flight ni de gestion de composants côté serveur.

Trente heures avant le chaos

La chronologie des événements suivant la divulgation illustre la vitesse à laquelle les acteurs malveillants peuvent transformer une annonce de sécurité en campagne d’exploitation de masse.

29 novembre 2025 : Lachlan Davidson transmet sa découverte à l’équipe Meta dans le cadre d’une divulgation responsable.

3 décembre 2025, 9h PT : Publication coordonnée des avis de sécurité par React et Vercel, mise à disposition des correctifs.

4 décembre 2025 : Apparition des premiers codes d’exploitation publics. Parmi eux, plusieurs ne fonctionnent pas réellement mais créent confusion et faux sentiment de sécurité. Le chercheur Moritz Sanft publie un exploit fonctionnel validé par Rapid7.

5 décembre 2025, 6h UTC : Wiz Research observe les premières compromissions réelles d’applications Next.js exposées sur Internet.

5 décembre 2025 : L’agence américaine CISA ajoute CVE-2025-55182 à son catalogue des vulnérabilités activement exploitées (KEV), fixant une échéance de remédiation au 26 décembre pour les agences fédérales. Cette échéance sera ensuite avancée au 13 décembre face à l’intensification des attaques.

5 décembre 2025 : Davidson publie son propre code d’exploitation. Un module Metasploit devient également disponible.

En moins de 30 heures après la divulgation publique, des exploits fiables circulaient librement et les premières victimes étaient déjà identifiées. Cette fenêtre extrêmement réduite entre divulgation et exploitation de masse caractérise une nouvelle réalité du paysage des menaces : les organisations disposent désormais de quelques heures, et non plus de quelques semaines, pour appliquer les correctifs critiques.

L’incident Cloudflare : quand la protection devient panne

Dans la course pour protéger leurs clients, les fournisseurs d’infrastructure ont déployé en urgence des règles de pare-feu applicatif (WAF) capables de bloquer les tentatives d’exploitation. Cloudflare, qui traite une part significative du trafic HTTP mondial, a été parmi les premiers à réagir en publiant des règles de mitigation dès le 3 décembre.

Mais le 5 décembre à 8h56 UTC, c’est une toute autre crise qui a éclaté. Les mesures de protection que Cloudflare tentait de déployer ont provoqué une panne massive, affectant environ 28 % de l’ensemble du trafic HTTP transitant par son réseau pendant environ 25 minutes. Des services majeurs comme Zoom, LinkedIn, Coinbase, DoorDash et Canva se sont retrouvés inaccessibles pour des millions d’utilisateurs à travers le monde.

Dans son rapport d’incident, Dane Knecht, directeur technique de Cloudflare, a clarifié que cette panne n’avait été causée « ni directement ni indirectement par une cyberattaque sur les systèmes de Cloudflare ou par une quelconque activité malveillante ». Le problème provenait de modifications apportées à la logique d’analyse des corps de requêtes HTTP dans le cadre de la mitigation de React2Shell.

Techniquement, l’incident s’est produit lorsque Cloudflare a tenté de désactiver un outil interne de test WAF via un mécanisme de « killswitch » pendant le déploiement progressif des nouvelles règles. Cette action a déclenché un bug latent dans le code Lua d’une ancienne version de leur proxy (FL1), provoquant des erreurs de référence nulle et générant des codes d’erreur HTTP 500 pour le trafic traité par cette version du proxy.

Cet incident a révélé une tension fondamentale dans la gestion des crises de sécurité : la pression pour protéger rapidement contre une menace active peut elle-même introduire des risques opérationnels majeurs. Cloudflare a d’ailleurs qualifié ses deux pannes de novembre et décembre 2025 d’« inacceptables » et a lancé un programme interne baptisé « Code Orange: Fail Small » visant à empêcher qu’une modification de configuration unique puisse affecter l’ensemble du réseau.

Les acteurs de la menace : une exploitation industrialisée

La rapidité et la diversité des acteurs impliqués dans l’exploitation de React2Shell illustrent la sophistication croissante de l’écosystème du cybercrime contemporain.

Groupes d’espionnage étatiques

Les équipes de renseignement sur les menaces d’Amazon Web Services ont détecté des tentatives d’exploitation par plusieurs groupes liés à la Chine dans les heures suivant la divulgation publique. Parmi les clusters identifiés figuraient Earth Lamia et Jackpot Panda, deux groupes APT (Advanced Persistent Threat) associés aux services de renseignement chinois.

Google Threat Intelligence Group a identifié au moins cinq clusters China-nexus distincts exploitant CVE-2025-55182 pour déployer différentes charges utiles malveillantes : le tunneler MINOCAT, le téléchargeur SNOWLIGHT, les portes dérobées HISONIC et COMPOOD. Ces outils sophistiqués visent l’établissement d’accès persistants et discrets dans les réseaux compromis.

Des acteurs liés à l’Iran ont également été observés exploitant la vulnérabilité, selon Google. Palo Alto Networks Unit 42 a de son côté identifié une activité cohérente avec CL-STA-1015, un courtier d’accès initial (Initial Access Broker) suspecté d’entretenir des liens avec le ministère chinois de la Sécurité d’État.

Cybercriminels opportunistes

Les groupes motivés par l’appât du gain ont été parmi les premiers à exploiter la faille. Dès le 5 décembre, des campagnes de cryptominage utilisant XMRig ont été observées. Ces attaques suivent un schéma classique : téléchargement d’un script shell (parfois nommé « sex.sh »), exécution du mineur de cryptomonnaie Monero, établissement d’une persistance via des services systemd.

Les botnets existants ont rapidement intégré React2Shell à leur arsenal. Le botnet RondoDox, actif depuis début 2025, utilise désormais la vulnérabilité comme vecteur d’accès initial pour compromettre serveurs web et objets connectés, déployant des mineurs de cryptomonnaie, des chargeurs de botnets et des charges utiles dérivées de Mirai.

Des malwares diversifiés

La variété des malwares déployés après exploitation reflète la diversité des objectifs poursuivis par les attaquants. Unit 42 a observé : Snowlight, Vshell, NoodlerRat, XMRIG, BPFDoor, Autocolor, Mirai et Supershell. Des portes dérobées sophistiquées comme KSwapDoor, décrite comme « un outil d’accès distant conçu avec la furtivité à l’esprit » capable de créer un réseau maillé interne entre serveurs compromis, ont également été identifiées.

NTT Security a rapporté des attaques ciblant des organisations japonaises via ZnDoor, un cheval de Troie d’accès distant actif depuis décembre 2023 et désormais déployé via React2Shell.

Encadré : Chiffres clés de l’exploitation (mi-janvier 2026)

8,1 millions : tentatives d’attaques observées par GreyNoise depuis la divulgation

300 000 à 400 000 : volume quotidien d’attaques après le pic initial

60+ : organisations directement impactées confirmées par Unit 42

~200 : exploits publics recensés par VulnCheck

111 000+ : adresses IP vulnérables suivies par Shadowserver Foundation

77 800 : instances vulnérables aux États-Unis (première position mondiale)

La réponse de l’industrie : coordination et improvisation

Face à l’ampleur de la crise, l’écosystème technologique a dû improviser une réponse coordonnée à une échelle rarement atteinte.

Vercel : un million de dollars pour casser leur propre WAF

Vercel, l’entreprise maintenant Next.js, s’est retrouvée en première ligne. Son directeur technique Talha Tariq a décrit une mobilisation « 24 heures sur 24, 7 jours sur 7, pendant au minimum deux semaines ». L’entreprise a fait appel à la communauté de la sécurité via un programme de bug bounty sur HackerOne, offrant 50 000 dollars pour chaque technique de contournement de leur pare-feu applicatif validée.

116 chercheurs ont participé, soumettant des techniques de contournement que les équipes de Vercel corrigeaient en temps réel. Au total, l’entreprise a versé un million de dollars et déployé 20 mises à jour uniques de son WAF en 48 heures. Le WAF de Vercel a bloqué plus de 6 millions de tentatives d’exploitation ciblant des environnements exécutant des versions vulnérables de Next.js, avec un pic de 2,3 millions en une seule journée.

Lachlan Davidson lui-même, accompagné de sa partenaire de recherche Sylvie, a soumis certains des contournements les plus sophistiqués, exploitant notamment des gadgets permettant de forcer le protocole Flight à effectuer des décodages JSON récursifs.

Les fournisseurs cloud en ordre de bataille

AWS a déployé des protections automatisées via son système de défense active Sonaris, mis à jour les règles WAF managées (AWSManagedRulesKnownBadInputsRuleSet version 1.24+) et renforcé les contrôles de sécurité périmétriques. L’entreprise a également partagé publiquement des indicateurs de compromission et des règles de détection pour les pare-feux réseau.

Microsoft a étendu son cadre de détection pour identifier et alerter sur l’activité CVE-2025-55182 dans Microsoft Defender for Endpoint, intégrant ces détections à son système de disruption automatique des attaques. Akamai a déployé une règle rapide (Rapid Rule 3000976) pour ses clients App & API Protector dès le 3 décembre.

Les failles dans les faux correctifs

Un phénomène préoccupant a accompagné cette crise : la prolifération de faux exploits et d’outils de détection défaillants. De nombreux « proof of concept » publiés sur GitHub ne fonctionnaient pas réellement, conduisant à des faux négatifs lors des évaluations de vulnérabilité et donnant à certaines organisations un sentiment de sécurité injustifié.

Le chercheur Kevin Beaumont a tenté de « faire dérailler le train de l’emballement médiatique » en soulignant que seules les instances utilisant effectivement les Server Components étaient vulnérables. Cependant, comme l’ont démontré les données de Wiz (39 % des environnements cloud concernés) et l’ampleur des compromissions observées, cette nuance n’atténuait que marginalement la gravité de la situation.

Trend Micro a identifié près de 145 exploits « in the wild » de qualité variable, certains incluant des techniques de contournement de WAF et des capacités de scan automatisé de masse. Cette prolifération d’outils, fonctionnels ou non, a complexifié le travail des équipes de sécurité cherchant à distinguer les vraies menaces des artefacts non fonctionnels.

Anatomie d’une post-exploitation

Les comportements observés après compromission révèlent des objectifs variés selon les acteurs impliqués.

Reconnaissance et vol de données d’identification

Wiz a observé des attaquants établissant des shells pour récolter les credentials présents dans les variables d’environnement, les systèmes de fichiers et les métadonnées d’instances cloud. Dans un environnement compromis, un acteur a été identifié tentant d’extraire les identifiants AWS et de les encoder en Base64 en préparation d’une exfiltration.

Persistance et mouvement latéral

Les techniques de persistance observées incluent l’ajout d’utilisateurs malveillants, l’utilisation d’outils de surveillance et gestion à distance (RMM) comme MeshAgent, la modification du fichier authorized_keys pour maintenir l’accès SSH, et l’activation de la connexion root.

Microsoft a documenté des shells inversés se connectant à des serveurs Cobalt Strike connus, témoignant de l’implication d’acteurs disposant d’une infrastructure professionnelle d’attaque.

Extraction de valeur économique

L’opération « PCPcat », documentée par des chercheurs italiens, aurait déjà compromis 59 128 serveurs selon leurs estimations. L’opération est décrite comme présentant les « caractéristiques d’opérations de renseignement à grande échelle et d’exfiltration de données à une échelle industrielle ».

Les enseignements d’une crise structurelle

React2Shell dépasse le simple incident de sécurité pour révéler des failles systémiques dans l’architecture du web moderne.

La concentration des risques

L’écosystème web s’est construit autour d’un nombre restreint de frameworks et de bibliothèques, créant des monocultures technologiques où une seule vulnérabilité peut affecter des millions d’applications simultanément. React, présent dans 82 % des projets JavaScript, constitue un point de défaillance unique d’une criticité comparable aux vulnérabilités historiques comme Log4Shell.

Kelly Shortridge, directrice produit chez Fastly, a résumé la situation : « C’est une vulnérabilité du type “un clic et c’est fini”. Elle touche littéralement tout le monde. » La comparaison avec Log4Shell est instructive : bien que l’adoption de React ne soit pas aussi universelle que celle de Log4j, l’impact potentiel de React2Shell est considéré comme pire et la vulnérabilité plus facile à exploiter.

La course contre la montre de la divulgation

Le débat autour de la divulgation responsable s’est intensifié à l’occasion de cette crise. Pascal Geenens, vice-président de l’intelligence des menaces chez Radware, a plaidé pour une plus grande transparence : « Les informations limitées ont conduit à des hypothèses inexactes et à des informations invalides circulant dans la communauté, affectant potentiellement les mitigations que certaines organisations avaient mises en place et leur donnant un faux sentiment de sécurité. »

Les acteurs étatiques disposant de ressources de recherche en vulnérabilités sophistiquées ont probablement pu développer des exploits fonctionnels avant même la publication de PoC publics, leur conférant un avantage temporel sur les défenseurs.

L’inertie organisationnelle face à l’urgence

Plusieurs semaines après la divulgation, les données de Shadowserver Foundation montraient encore plus de 90 000 instances vulnérables, majoritairement aux États-Unis. Alon Schindel, vice-président de la recherche IA et menaces chez Wiz, notait que « la moitié des ressources publiques exposées à CVE-2025-55182 restent non patchées ».

Kelly Shortridge a observé avec surprise que « les équipes de sécurité ne prennent pas toutes cette menace au sérieux. C’est très inégal et surprenant de voir ce genre de désinvolture de la part d’équipes de sécurité ».

Cette inertie s’explique partiellement par la complexité des environnements modernes. Next.js intègre React en mode « vendored », c’est-à-dire directement incorporé dans le framework plutôt qu’installé comme dépendance traditionnelle. De nombreux outils d’analyse de dépendances ne détectent donc pas automatiquement la présence de versions vulnérables.

La chaîne de dépendances comme vecteur de risque

L’architecture contemporaine du développement web repose sur des chaînes de dépendances profondes où le code de l’application finale ne représente qu’une fraction de l’ensemble exécuté. Une application créée avec create-next-app utilisant un template par défaut et construite pour la production peut être exploitée sans aucune modification de code par le développeur.

Cette réalité pose la question de la responsabilité et de la visibilité : comment les équipes de développement peuvent-elles maintenir une posture de sécurité adéquate lorsque les vulnérabilités se trouvent dans des couches de l’infrastructure qu’elles n’ont jamais directement manipulées ?

Les correctifs et la remédiation

L’équipe React a publié des versions corrigées pour toutes les branches affectées :

React : versions 19.0.1, 19.1.2 et 19.2.1 contenant l’implémentation durcie du protocole Flight.

Next.js : versions 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 et 16.0.7 incorporant les composants React corrigés.

Des vulnérabilités additionnelles ont été identifiées dans la même période de divulgation. CVE-2025-55183 permet une exposition limitée du code source (CVSS 5.3). CVE-2025-55184 et CVE-2025-67779 permettent des dénis de service pré-authentifiés (CVSS 7.5). CVE-2025-67779 est considérée comme un contournement du correctif original de React2Shell. Les versions 19.0.3, 19.1.4 et 19.2.3 de React corrigent l’ensemble de ces failles.

Recommandations de remédiation

Mise à jour immédiate : Les organisations doivent mettre à jour vers les versions corrigées en dehors des cycles de correctifs normaux. Le caractère critique de la vulnérabilité justifie une intervention d’urgence.

Audit des dépendances : En raison du mode « vendored » de React dans Next.js, les outils traditionnels d’analyse de dépendances peuvent manquer les versions vulnérables. Une vérification manuelle ou l’utilisation d’outils spécialisés est recommandée.

Protection WAF : Les règles de pare-feu applicatif constituent une première ligne de défense mais ne remplacent pas le correctif. Les techniques de contournement évoluent constamment.

Surveillance comportementale : La mise en place de règles de détection pour identifier les comportements post-exploitation (téléchargements suspects, création d’utilisateurs, modifications de fichiers d’autorisation) permet de détecter les compromissions même lorsque l’exploitation initiale a échappé aux défenses.

Isolation réseau : Les applications React Server Components devraient être segmentées du reste de l’infrastructure pour limiter l’impact d’une compromission éventuelle.

Une nouvelle normalité des crises

React2Shell s’inscrit dans une série de vulnérabilités critiques ayant affecté des composants fondamentaux de l’infrastructure web : Log4Shell en 2021, Spring4Shell en 2022, et désormais React2Shell en 2025. Chaque incident renforce le constat que les fondations logicielles du web contemporain présentent des fragilités structurelles insuffisamment anticipées.

La réponse à cette crise a néanmoins démontré une capacité de coordination remarquable. La divulgation responsable de Lachlan Davidson, la réaction rapide de Meta et Vercel, le programme de bug bounty innovant, la mobilisation des fournisseurs cloud : ces éléments témoignent d’un écosystème capable de répondre aux urgences, même si la prévention reste lacunaire.

Pour les organisations dépendantes de ces technologies, React2Shell constitue un rappel brutal que la dette technique et la négligence des mises à jour de sécurité peuvent avoir des conséquences catastrophiques en quelques heures. La question n’est plus de savoir si une nouvelle vulnérabilité majeure sera découverte, mais quand, et si les processus de remédiation seront suffisamment rapides pour devancer les attaquants.

Dans les mots de Tariq de Vercel : « Du point de vue du risque et de l’exposition, c’est fondamentalement aussi grave que cela puisse être. » Une affirmation qui, au regard des événements de décembre 2025 et janvier 2026, s’est révélée malheureusement prophétique.

Sources et références :

Google Cloud Blog, « Multiple Threat Actors Exploit React2Shell », 13 décembre 2025
AWS Security Blog, « China-nexus cyber threat groups rapidly exploit React2Shell vulnerability », décembre 2025
Microsoft Security Blog, « Defending against the CVE-2025-55182 vulnerability », 15 décembre 2025
Wiz Blog, « React2Shell (CVE-2025-55182): Critical React Vulnerability », 3 décembre 2025
Cloudflare Blog, « Cloudflare outage on December 5, 2025 », 10 décembre 2025
Vercel Blog, « Our $1 million hacker challenge for React2Shell », janvier 2026
Unit 42 Palo Alto Networks, « Exploitation of Critical Vulnerability in React Server Components », décembre 2025
CyberScoop, « Inside Vercel’s sleep-deprived race to contain React2Shell », janvier 2026
Shadowserver Foundation, CVE-2025-55182 Dashboard
CISA Known Exploited Vulnerabilities Catalog