La faille mortelle de React expliquée

Le scénario du pire est arrivé pour React Server Components avec un bug d'exécution de code à distance de CVSS 10.0 d'une gravité maximale que les chercheurs en sécurité ont rapidement qualifié de "catastrophique". En jeu : toute application utilisant le package serveur React vulnérable, des projets Next.js amateurs aux sites de production à fort trafic, soudainement exposés à des attaquants non authentifiés. Une requête HTTP soigneusement élaborée pourrait exécuter du code arbitraire sur le serveur, sans besoin de connexion.

Les responsables de React ont répondu avec un langage particulièrement franc pour une sortie de framework, exhortant les développeurs à « mettre à jour immédiatement » toutes les versions concernées. Les plateformes d'hébergement ont emboîté le pas : Vercel, Cloudflare et d'autres ont publié d'urgence des règles WAF, tout en avertissant que ces filtres n'étaient que des protections partielles. Les équipes de sécurité ont traité cet avis comme une exercise de réaction face à une vulnérabilité de type zero-day, déployant des correctifs en production en quelques heures.

Des listes de diffusion sur la sécurité et des canaux Discord inondés de bannières rouges et de messages tels que « abandonnez tout et corrigez React ». Les équipes DevOps ont gelé les déploiements de nouvelles fonctionnalités pour prioriser les mises à jour des dépendances, le verrouillage des dépendances et les redéploiements. Des pipelines CI qui prennent habituellement des jours pour être modifiés ont soudainement expédié de nouvelles versions de React en quelques minutes.

Le nom du bogue est arrivé tout aussi rapidement. Les chercheurs et la communauté React se sont unis autour de React2Shell, un écho délibéré de Log4Shell qui signalait la même catégorie de cauchemar : un composant omniprésent, une faille de sérialisation et une exécution de code à distance triviale. Le site dédié react2shell.com et un écosystème croissant d'exploits de proof-of-concept sur GitHub ont cimenté la marque.

Les comparaisons avec Log4Shell ne se limitaient pas à une simple stratégie marketing. Tout comme Log4j en 2021, les composants serveur React sont intégrés profondément dans les architectures web modernes, cachés derrière des frameworks, des boilerplates et des modèles. De nombreuses équipes ont nécessité des heures juste pour répondre à une question basique : « Utilisons-nous des composants serveur React quelque part, et sur quelles versions ? »

Des rapports d'exploitation active sont arrivés presque immédiatement. Les équipes de sécurité d'AWS ont averti que des « groupes de menaces cybernétiques essaient rapidement d'exploiter cela », avec des scanners parcourant Internet à la recherche de serveurs Next.js vulnérables. Les chasseurs de bug bounty et les opérateurs criminels ont commencé à échanger des charges utiles qui transforma un simple POST en un invite de commande sur l'infrastructure d'autrui.

React2Shell se situe dans la catégorie cauchemardesque des bugs : exécution de code à distance non authentifiée sur des serveurs accessibles depuis Internet. Pas de connexion, pas de jeton CSRF, pas de tromperie d'un utilisateur pour cliquer sur quoi que ce soit. Une seule requête HTTP malveillante atteint un point de terminaison des composants de serveur React et l'attaquant exécute des commandes arbitraires avec les privilèges dont dispose votre processus Node.

Les spécialistes de la sécurité craignent les RCE car elles annihilent toutes les autres défenses. Une fois qu'un attaquant peut exécuter du code, il peut lire les variables d'environnement, extraire des bases de données, installer des webshells, mettre en place des cryptomineurs ou s'infiltrer plus profondément dans votre cloud. À ce moment-là, vous ne "fuitez pas de données" ; vous hébergez le centre d'opérations de quelqu'un d'autre.

React2Shell ne s'arrête pas à Next.js. Le bogue se trouve dans le package React server et son implémentation du protocole React Flight, donc tout framework qui s'intègre dans cette pile hérite du rayon d'explosion. Cela inclut des projets comme Waku, les fonctionnalités côté serveur de React Router, et tout backend personnalisé qui a décidé de communiquer directement via Flight.

Le CVSS 10.0 n'est pas un discours marketing ; c'est le sommet de l'échelle de risque standardisée. Un score aussi élevé implique trois choses à la fois : une exploitabilité triviale, aucune barrière d'authentification et un compromis complet de la confidentialité, de l'intégrité et de la disponibilité. Vous n'avez pas besoin de bugs en chaîne, de conditions de concurrence ou d'accès local ; l'accessibilité Internet combinée à une version vulnérable suffit.

Selon le CVSS, React2Shell atteint des valeurs maximales dans tous les domaines : Vecteur d'attaque : Réseau, Complexité d'attaque : Faible, Privilèges requis : Aucun, Interaction utilisateur : Aucune. Les métriques d'impact atteignent également leur maximum, car l'exécution de code arbitraire signifie un contrôle total en lecture/écriture sur les données de l'application et la capacité de faire échouer ou de réaffecter le service. C'est pourquoi l'avis le qualifie de "Critique" plutôt que de "Élevé".

Le détail le plus glaçant : vous n'avez pas besoin d'activer des fonctionnalités exotiques pour être exposé. Le code vulnérable se trouve dans le chemin de sérialisation principal utilisé par défaut par les composants serveur React, donc une nouvelle commande “npx create-next-app” utilisant les versions affectées embarque une logique exploitable dès le premier jour. Pas d'actions serveur, pas de désérialiseurs personnalisés, pas de drapeaux expérimentaux nécessaires.

React2Shell transforme le code standard en une surface d'attaque. Si votre stack utilise Flight via le package de serveur React vulnérable et qu'il est accessible par HTTP, vous êtes dans le champ d'application.

React2Shell ne vit pas dans les Server Actions. Il vit dans le protocole React Flight lui-même — le sérialiseur/désérialiseur de bas niveau qui alimente tous les React Server Components. Si votre pile analyse les charges utiles Flight avec une version vulnérable de `react-server`, vous héritez d'un RCE non authentifié, que vous ayez ou non jamais écrit `use server` dans votre code.

Le conseil de Meta signale que le package `react-server` présente des vulnérabilités dans certaines versions spécifiques de la série 19.x. Tout framework qui inclut ces versions et expose un point de terminaison Flight est concerné. Cette liste comprend Next.js, ainsi que d'autres adopteurs de Flight tels que les API de données de React Router et les frameworks RSC émergents.

Le routeur d’application Next.js rend cela particulièrement dangereux car son architecture par défaut connecte automatiquement Flight pour vous. Une nouvelle application `create-next-app` utilisant le routeur d’application et une version vulnérable de Next.js (par exemple, 14.x associée à React 19.0.0–19.2.0) crée des points de terminaison qui acceptent les données de formulaire Flight sans aucune configuration supplémentaire. Construisez, déployez, et vous avez une surface RCE exposée à Internet.

Chaque gestionnaire HTTP qui consomme une charge utile de composant serveur devient un point d'entrée potentiel. Cela inclut : - Les points de données de l'App Router intégrés - Les gestionnaires de routes personnalisés qui appellent `renderToReadableStream` ou des API Flight similaires - Tout proxy ou fonction edge qui transfère des charges utiles Flight à un serveur Node

L'authentification ne vous protège pas par défaut. Si un attaquant peut atteindre un point de terminaison de Flight avant l'authentification, il obtient une exécution de code à distance (RCE) avant authentification. Si votre parsing de Flight est protégé par une connexion mais que vous l'exposez aux navigateurs, toute contrefaçon de requête intersite ou vol de jeton se transforme instantanément en compromission totale du serveur.

La propre note de Meta, Vulnérabilité critique de sécurité dans les composants serveur React (CVE-2025-55182), avertit explicitement que les règles WAF des fournisseurs d'hébergement ne sont qu'un palliatif. Corrigez `react-server` et votre framework, ou supposez que tout point de terminaison Flight exposé est déjà en cours d’analyse.

Une seule requête HTTP suffit à un attaquant. React2Shell transforme un endpoint POST ennuyeux d'une application React Server Components en un shell distant en abusant de la manière dont le protocole React Flight désérialise les données de composants diffusées. Aucune authentification, aucun jeton CSRF, aucune session utilisateur requise.

Les attaquants commencent par créer une requête POST malveillante qui ressemble à une soumission normale d'un navigateur. Le corps utilise `multipart/form-data`, le même format que React Flight utilise pour diffuser les charges utiles des Composants Serveur et les Actions Serveur. À l'intérieur de ces données de formulaire, l'attaquant cache une série de "morceaux" qui imitent la syntaxe de référence interne précédée du `$` de Flight.

Chaque fragment prétend faire partie d'un arbre de composants légitime, mais la structure est détournée. Un champ pointe vers un autre fragment en utilisant `$0`, `$1`, `$2`, et ainsi de suite, tandis qu'une chaîne de chemin spécialement conçue utilise des séparateurs `:` pour naviguer dans des propriétés imbriquées. Enfouie dans ce chemin se trouve la véritable charge utile : une tentative d'accès à `__proto__` et de pénétration dans les internals des objets JavaScript.

Lorsque le serveur vulnérable reçoit la requête, le désérialiseur Flight de React s'active automatiquement. Il analyse les données du formulaire, reconstruit le graphique des morceaux et commence à résoudre les références `$` et les chemins délimités par des deux-points. Il est crucial de noter que les anciennes versions du serveur React ne vérifiaient jamais si une clé demandée était une propriété « propre », donc `__proto__` passait sans problème.

Cette négligence transforme une simple recherche en une pollution de prototype à part entière. En résolvant un chemin comme `$1:__proto__:execSync`, le désérialiseur peut fournir à l'attaquant une référence live à `child_process.execSync` (ou à des primitives similaires) attachée au prototype pollué. De là, le payload demande au serveur d'exécuter des commandes shell arbitraires dans le cadre du processus de désérialisation lui-même.

Le code de preuve de concept sur React2Shell et les POCs originaux et détaillés transforment cela en un exploit à exploitation unique. Le POST manipulé par l'attaquant amène le serveur à exécuter une commande qui affiche "vous avez été piraté" puis exécute `cat secret.txt`, lisant un fichier placé sur le bureau du serveur. Dans la démonstration, le contenu est directement diffusé dans les journaux du serveur Next.js, mais le même primitive pourrait exfiltrer des secrets via `curl`, déposer un shell inversé ou installer un malware persistant avec une seule requête.

React Flight existe pour résoudre un problème réel : comment diffuser un arbre de Composants Serveur React du backend vers le navigateur sans envoyer la moitié de votre runtime serveur sous forme de JavaScript ? Au lieu du JSON, l'équipe de React a conçu un format de transmission personnalisé qui peut décrire les composants, les props et les références sous la forme d'une séquence de petits "chunks" qui transitent sur le réseau et s'hydratent progressivement sur le client.

Chaque fragment dans le protocole React Flight transporte une petite partie de l'interface utilisateur : peut-être un type de composant, peut-être des props, peut-être un espace réservé pour une promesse. Pour éviter de répéter les données, Flight utilise des jetons de chaîne spéciaux commençant par "$" pour pointer vers d'autres fragments. Une charge utile pourrait indiquer `"$1"` pour signifier « regardez le fragment 1 », ou `"$1:name"` pour signifier « allez au fragment 1, puis suivez le chemin `name` sur l'objet qui s'y trouve. »

Ces références `$` forment un graphique compact d'objets que le désérialiseur recoud. Le morceau 0 peut être simplement `["$1"]`, le morceau 1 peut être un objet qui pointe lui-même vers le morceau 2, et ainsi de suite. Le résultat, côté serveur ou client, est un objet JavaScript propre comme `{ nom: "cerise" }`, même si le format de transmission ressemblait à un mélange étrange d'indices et de chaînes de chemin.

La cause profonde de React2Shell se cache dans cette logique de suivi de chemin. Le désérialiseur de Flight a accepté avec joie des instructions de traversée de chemin contrôlées par des attaquants, telles que `"$1:__proto__:toString"`, et les a traversées sans se demander si ces clés devaient être accessibles. Aucun garde-fou, aucune vérification des propriétés, juste un accès brut à tout ce que la chaîne de chemin décrivait.

Au lieu de s'arrêter aux données utilisateur, ces étapes de parcours ont atteint directement les entrailles de JavaScript. En résolvant des chemins comme `__proto__` sur des objets simples, le désérialiseur a ouvert la porte à la classique pollution de prototype. De là, les attaquants ont enchaîné avec des fonctions intégrées puissantes, dirigeant finalement l'exécution vers `child_process` et obtenant une exécution de code à distance avec une seule requête malveillante.

Le JSON aurait été ennuyeux ici - et plus sûr. Le JSON standard manque de références, de chemins ou de sémantiques spéciales `$` ; il ne décrit que les données, pas comment les explorer ou les reconstruire. Le format sur mesure de Flight a ajouté des références croisées et une syntaxe de navigation, mais sans les couches de validation renforcées que les sérialiseurs matures et les analyseurs JSON ont accumulées au fil des années d'examen de la sécurité.

Les protocoles personnalisés échangent toujours la sécurité contre la flexibilité. En inventant un mini-langage ad hoc à l'intérieur de chaînes telles que `"$1:foo:bar"`, le format Flight de React a créé une nouvelle surface d'attaque que les outils génériques—validateurs JSON, vérificateurs de schéma, règles de WAF—ne comprenaient pas. Une fois que ce mini-langage pouvait toucher `__proto__`, chaque serveur utilisant les composants de serveur React héritait du même défaut critique.

La pollution des prototypes semble abstraite, mais en JavaScript, c'est l'une des classes de bogues les plus dangereuses que vous pouvez expédier. Au lieu de corrompre un seul objet, la pollution des prototypes permet à un attaquant de manipuler `Object.prototype` lui-même, l'ancêtre partagé de presque tous les objets dans un processus Node ou navigateur. Une fois que cette racine est compromise, l'ensemble du graphe d'objets commence à hériter des propriétés contrôlées par l'attaquant.

Les composants serveur React sont tombés dans ce piège via la logique de traversée de chemin du protocole React Flight. Le désérialiseur prend en charge une syntaxe basée sur les deux-points pour parcourir des structures imbriquées, donc une référence comme `:$1:fruit:name` signifie « suivre le morceau 1, puis `fruit`, puis `name` ». Les chercheurs ont réalisé qu'il n'y avait rien qui les empêchait d'échanger une clé normale contre des éléments internes de JavaScript et de demander `:__proto__` à la place.

Ce changement unique a transformé une fonctionnalité de commodité en arme. Lorsque le code vulnérable rencontrait un segment de chemin comme `__proto__`, il le traitait comme une simple propriété, se dirigeant aveuglément vers `value['__proto__']`. En JavaScript, ce saut vous remet le `Object.prototype` en direct de la cible, et non un champ inoffensif d'un conteneur de données.

Une fois que le chemin d'exploitation a atteint `__proto__`, les attaquants pouvaient commencer à y écrire. En envoyant des morceaux de vol ciblés, ils pouvaient faire des choses comme `payload: { ":$1:__proto__:pwned": "yes" }`, ce qui définit effectivement `Object.prototype.pwned = "yes"`. À partir de ce moment, chaque objet simple dans le processus a soudainement une propriété `pwned`, même ceux créés longtemps après la fin de la requête d'exploitation.

La pollution ne s'arrête pas aux drapeaux de chaîne. Les attaquants peuvent injecter des fonctions entières dans le prototype, comme `Object.prototype.toJSON` ou des hooks personnalisés que le code en aval considère comme fiables. Si une bibliothèque ultérieure exécute `JSON.stringify(user)` ou appelle `options.onSuccess?.()`, cela pourrait en réalité exécuter du code fourni par un attaquant greffé sur le prototype quelques minutes auparavant.

React2Shell enchaîne cela en exécution de code à distance en ciblant des points puissants et rarement audités dans la pile. Par exemple, des propriétés polluées peuvent influencer la manière dont un framework construit des commandes shell, des chemins de fichiers ou des appels `require` dynamiques. Une fois qu'une valeur polluée pénètre dans `child_process.exec`, un moteur de templating, ou une importation dynamique, le passage de « champ supplémentaire étrange » à « commande arbitraire sur le serveur » se produit en une seule ligne.

Des détails techniques complets sont disponibles dans l'entrée NVD pour CVE-2025-55182 et la preuve de concept détaillée montre comment une seule requête HTTP pollue à la fois `Object.prototype` et exploite ensuite ces propriétés corrompues dans les API les plus dangereuses de Node. Cette combinaison justifie le score CVSS de 10.0 : une requête non authentifiée, un compromis total du processus.

La pollution de prototype à elle seule ne vous donne pas une shell ; les attaquants ont toujours besoin d'un moyen pour transformer un graphique d'objet corrompu en commandes système exécutables. Le dernier tour de React2Shell a enchaîné ce prototype pollué dans un chemin d'exécution de code à distance entièrement armé, en utilisant rien de plus exotique que les propres fonctionnalités de réflexion de JavaScript et la sémantique asynchrone.

Une fois que l'attaquant a pris le contrôle du prototype de l'objet de base, il pouvait parcourir la chaîne de prototypes pour atteindre le constructeur global Function. En JavaScript, chaque fonction hérite finalement de `Function.prototype`, et `Function` lui-même est accessible via des constructeurs comme `({}).constructor.constructor`.

Avec cet accès, la charge utile fait simplement ce que fait tout contournement de « no eval » : `new Function("require('child_process').execSync('id > /tmp/pwned');")`. Cette chaîne peut contenir n'importe quelle commande shell : `curl` pour exfiltrer des données, `rm -rf` pour effacer des disques, ou une ligne pour lancer un shell inversé. Sur un serveur Next.js, ces commandes s'exécutent avec les mêmes privilèges que le processus Node, offrant souvent un accès direct aux variables d'environnement, aux clés API et aux fichiers privés.

Les attaquants faisaient encore face à un problème : ils pouvaient créer une fonction malveillante, mais ils ne contrôlaient aucun point d'appel évident. Ils avaient besoin du flux de contrôle du serveur pour invoquer leur fonction automatiquement, sans un appel explicite `malicious()` dans le code de l'application.

Le mot-clé `await` de JavaScript constitue le lien manquant. En arrière-plan, `await value` vérifie si `value` est "thenable" et, si c'est le cas, appelle `value.then(resolve, reject)`. Ce comportement discret est exactement ce qui alimente les Promesses—et exactement ce qu'abuse React2Shell.

En polluant le prototype partagé pour définir une propriété `.then` pointant vers l'instance Function de l'attaquant, tout objet attendu est soudainement devenu un déclencheur. Lorsque le code des composants serveur React a atteint un `await` sur une valeur désérialisée, le moteur JS a, avec diligence, invoqué `.then`, qui exécutait désormais des commandes shell arbitraires. Aucun crochet supplémentaire, pas de gadgets étranges—juste des chemins de code asynchrone normaux transformés en trampoline universel RCE.

La correction de React pour React2Shell semble presque insultante de simplicité. Après une chaîne allant du parcours de chemin à la pollution de prototype, en passant par des Promesses détournées et `child_process.execSync`, le correctif officiel de l'équipe React ajoute essentiellement un seul gardien : un `if` unique qui appelle `Object.prototype.hasOwnProperty` avant de lire une propriété lors de la désérialisation de Flight.

Au lieu de faire aveuglément `value = value[path]` pour chaque segment de la traversée, le code corrigé vérifie d'abord `if (!Object.prototype.hasOwnProperty.call(value, path))` et abandonne avec une erreur lorsque la clé est manquante. Cette petite condition change le comportement de « parcourir l'ensemble du modèle d'objet JavaScript » à « ne faire confiance qu'aux champs que cet objet possède réellement ». Les références `__proto__` malveillantes, qui ne vivent que sur la chaîne prototype, rencontrent soudainement un obstacle insurmontable.

Cela fonctionne parce que `hasOwnProperty` ignore complètement la chaîne de prototype héritée. En JavaScript, chaque objet simple hérite de `Object.prototype`, où se trouvent des méta-propriétés dangereuses comme `__proto__` et `constructor`. En insistant pour que chaque clé désignée soit une « propriété propre », le protocole Flight de React empêche les attaquants de toucher à ces éléments internes, de sorte que le prototype pollué ne se matérialise jamais.

Les chercheurs en sécurité aiment dire que la plupart des bogues catastrophiques sont dus à un contrôle manquant, et React2Shell le prouve. Avant le correctif, le désérialiseur faisait confiance de manière implicite à tout chemin envoyé par le client, même s'il pointait directement vers les entrailles de JavaScript. Après, ce seul statement `if` transforme une chaîne RCE avec un CVSS de 10.0 en une banale erreur de “référence invalide”.

Vu dans le contexte des RCE non authentifiés à travers des milliers de déploiements de React Server Components, l'élégance en est presque troublante. Un écosystème tentaculaire construit sur React Server Components et Next.js reposait sur une seule barrière qui aurait dû être là dès le premier jour. Une ligne de code défensive sépare désormais un rendu serveur routinier d'une prise de contrôle complète du serveur.

React2Shell est passé d'un cauchemar théorique à un kit d'attaque pratique en quelques jours. Des dépôts de preuve de concept, des écrits sur les exploits et des charges utiles prêtes à l'emploi sont désormais disponibles sur GitHub, abaissant ainsi le niveau d'accès d'un État-nation à un bricoleur du weekend. Toute application exposée sur Internet exécutant des React Server Components vulnérables annonce efficacement "shell non authentifié disponible sur le port 443".

Les équipes de sécurité constatent déjà les effets en cascade. AWS signale que les "groupes de cybermenaces tentent rapidement d'exploiter cela", avec des scanners balayant de vastes plages d'adresses IP à la recherche des points de terminaison React Flight révélateurs. Des chercheurs indépendants et des fournisseurs de services de sécurité gérés (MSSP) décrivent une augmentation des sondes qui envoient des charges utiles Flight mal formées et surveillent les différences subtiles de timing et d'erreurs pour cartographier les cibles vulnérables.

Les attaquants n'ont pas besoin de copies parfaites de l'exploit original. Avec des PoCs publics et des descriptions détaillées comme CVE-2025-55182 (React2Shell) : Exécution de code à distance dans les composants serveur React, ils peuvent muter les charges utiles à l'infini. Changer les noms de champs, réorganiser les morceaux ou cacher la chaîne de prototypes polluée derrière des niveaux d'indirection supplémentaires, et vous vous éloignez déjà des signatures que la plupart des règles WAF s'attendent à voir.

Les fournisseurs d'hébergement ont déployé des filtres d'urgence. Vercel, Cloudflare et AWS ont mis à jour leurs WAF pour bloquer les motifs d'abus évidents de React Flight, tels que les références `__proto__` dans les données de formulaire multipart ou les références de morceaux suspectes précédées d'un `$`. Ces règles aident à prévenir les attaques par copié-collé, mais elles ne ciblent que les formes connues d'un bug qui réside fondamentalement dans la manière dont le serveur désérialise les entrées.

L'histoire montre que les défenses uniquement WAF vieillissent mal. Une fois qu'une RCE avec un score CVSS de 10.0 devient publique, les auteurs d'exploits itèrent plus vite que les fournisseurs ne peuvent expédier de nouvelles signatures. Les astuces d'obfuscation—homoglyphes Unicode, chemins d'accès alternatifs tels que `constructor.prototype`, tableaux imbriqués, ou charges utiles compressées—contournent régulièrement les filtres génériques "bloquez cette chaîne".

Un seul contrôle change les règles de l'engagement : le patching. La mise à niveau de React, Next.js et de tout cadre qui intègre le paquet serveur React vulnérable élimine complètement la désérialisation Flight non sécurisée. Aucune configuration astucieuse de WAF ne peut égaler la certitude de ne pas exécuter le bogue en premier lieu.

React2Shell invite des comparaisons immédiates avec Log4Shell pour une raison simple : l'impact. Une seule requête POST non authentifiée peut déclencher l'exécution de code à distance sur presque n'importe quelle application utilisant des composants serveur React vulnérables, allant de projets Next.js amateurs à des tableaux de bord SaaS à fort trafic. Comme Log4Shell, le bogue réside dans le code d'infrastructure que des milliers d'équipes ont adopté implicitement, et non dans une fonction « sensible à la sécurité » évidente qu'elles ont activée délibérément.

Log4Shell a profité de l’ubiquité de Log4j dans les piles Java ; React2Shell tire parti de la domination de React dans les interfaces web modernes. Tout cadre qui intègre le protocole React Flight—Next.js, les API de données de React Router, les cadres RSC émergents—hérite soudainement d’une responsabilité CVSS de 10,0. Ce type de risque de dépendance au niveau de l'écosystème est précisément ce qui a fait de Log4Shell un incident exceptionnel d'une décennie.

Là où Log4Shell a brisé les idées reçues sur les bibliothèques de journalisation, React2Shell déchire le modèle mental des frameworks “frontend”. Les composants serveur de React estompent la frontière entre le client et le serveur, mais ce bogue prouve que la limite de sécurité est également floue. Un arbre de composants fait désormais double usage en tant que surface de protocole, et un format de sérialisation est devenu discrètement un primitive d'exécution de code à distance.

La responsabilité en matière de sécurité était auparavant bien distincte : les équipes backend protégeaient les APIs et les bases de données, tandis que les équipes frontend s’inquiétaient des XSS et CSRF. Les stacks de l'ère RSC effacent cette frontière. Lorsqu'un composant JSX peut déclencher une logique serveur via un format de connexion personnalisé, un changement “frontend” peut entraîner une vulnérabilité backend, et aucune des deux parties ne peut se sentir pleinement responsable.

Les développeurs doivent maintenant poser une question délicate : les composants serveur ont-ils un modèle de sécurité sur lequel ils peuvent réellement se pencher ? React2Shell a révélé combien de personnes comprenaient mal les rouages internes de Flight avant cette semaine, y compris beaucoup de ceux qui l'ont déployé en production. Si vous ne pouvez pas expliquer quelles entrées touchent le désérialiseur, vous ne pouvez pas modéliser de manière significative les menaces pesant sur votre application.

Les auteurs de frameworks sont confrontés à un mandat plus strict. Des protocoles comme Flight, les chargeurs de données de Remix ou les encodages personnalisés de tRPC méritent la même attention que les générateurs de requêtes ORM ou les piles TLS. Cela implique des modèles de menace formels, des tests de robustesse, des évaluations par des équipes adverses et des audits de tiers axés sur la sérialisation, la résolution des références et les flux de données transfrontaliers.

Le correctif rapide de React a empêché un effondrement à l’échelle de Log4Shell, mais le tir d'avertissement est fort. Tout outil qui déplace de la logique à travers le réseau—peu importe à quel point il semble « frontend »—appartient désormais clairement à la catégorie des surfaces d'attaque critiques.

Quelle est la vulnérabilité React2Shell (CVE-2025-55182) ?

React2Shell est une vulnérabilité critique d'exécution de code à distance (RCE) non authentifiée dans les composants serveur React. Elle permet à un attaquant d'exécuter du code arbitraire sur un serveur en utilisant une seule requête malveillante, et elle a le score de gravité le plus élevé possible de 10,0 selon le CVSS.

Quelles versions de React et Next.js sont concernées ?

La vulnérabilité concerne les versions 19.0.0 à 19.2.0 de React Server. Cela inclut les frameworks qui l'utilisent, comme Next.js. Toute version de Next.js utilisant une version affectée de React Server, comme la version 16.0.6 montrée dans les démonstrations, est vulnérable. Les utilisateurs doivent mettre à jour vers les dernières versions corrigées immédiatement.

Comment fonctionne l'exploitation React2Shell ?

L'exploit tire parti d'une vulnérabilité de désérialisation non sécurisée dans le protocole React Flight. En envoyant une charge utile conçue, un attaquant peut provoquer une vulnérabilité de 'pollution de prototype', modifiant les comportements d'objets JavaScript fondamentaux pour finalement enchaîner des commandes et exécuter du code sur le serveur.

Un WAF suffit-il à protéger mon application contre React2Shell ?

Non. Bien que les pare-feu d'application Web (WAF) de fournisseurs comme Vercel et Cloudflare puissent bloquer des modèles d'attaque connus, ils ne constituent pas une solution complète. Les attaquants peuvent souvent obscurcir les charges utiles pour contourner les règles des WAF. La seule solution fiable est de mettre à jour vos dépendances React et Next.js vers des versions corrigées.