Article original : React’s Critical "React2Shell" Vulnerability — What You Should Know, and How to Upgrade Your App

Le développement web est en constante évolution, et parfois ces changements se produisent un peu sous le capot. L'un de ces changements concerne le passage aux React Server Components (RSC). Si vous êtes un développeur NextJS ou React, utilisant particulièrement l'App Router, comprendre cette nouvelle alerte de sécurité est crucial pour maintenir vos applications sûres et sécurisées.

Table des matières

Qu'est-ce que « React2Shell » ?

Imaginez que votre serveur reçoit des données comme un service de courrier reçoit des colis.

Habituellement, un service de courrier vérifie si un colis est sûr avant de l'ouvrir. Mais dans les versions vulnérables de React et NextJS, le protocole « Flight » (utilisé pour communiquer entre le serveur et le client) agit comme un service de courrier qui ouvrirait aveuglément chaque colis et suivrait immédiatement toutes les instructions à l'intérieur.

Cette vulnérabilité (CVE-2025-55182) permet à un attaquant d'envoyer un « colis » spécifiquement conçu (requête HTTP) qui force votre serveur à exécuter du code malveillant – comme voler des mots de passe ou installer des virus – sans même avoir besoin de se connecter.

Pourquoi cela arrive-t-il maintenant ?

Tout est question de la manière dont les frameworks modernes gèrent la sérialisation des données. Il y a plusieurs raisons pour lesquelles cela vient d'être découvert.

Premièrement, React utilise une sérialisation complexe. Pour rendre les Server Components transparents, React envoie des structures de données complexes dans les deux sens.

Deuxièmement, il y a le protocole « Flight ». La vulnérabilité a été trouvée dans la manière dont ce protocole spécifique désérialise (déballe) les données. Il faisait trop confiance aux entrées reçues du côté client.

Devez-vous vous inquiéter de ce changement ?

Vous devez prêter attention si votre application remplit l'un des critères suivants :

  • Vous utilisez l'App Router de NextJS : C'est le choix par défaut dans les versions récentes de NextJS (v13+).

  • Vous utilisez React 19 : Spécifiquement les versions où les Server Components sont activés.

  • Vous utilisez des Server Actions : Si votre application prend des entrées utilisateur et les traite sur le serveur en utilisant les Server Actions de React.

Est-ce obligatoire ?

Oui. Il s'agit d'une mise à jour de sécurité critique. Si votre application correspond à l'un des scénarios ci-dessus, vous devez agir immédiatement. En effet, cette vulnérabilité est actuellement exploitée.

Jusqu'où cela peut-il aller ? L'étendue de l'exploitation

Vous vous dites peut-être : « Mon site n'est qu'un simple wrapper de contenu, je ne suis sûrement pas une cible ». Malheureusement, avec une exécution de code à distance (RCE), l'attaquant ne se contente pas de « casser » votre site – il prend le contrôle du serveur sur lequel il tourne.

Voici exactement ce qu'un pirate peut faire une fois qu'il a exploité cette vulnérabilité :

Vol total de l'environnement

Le risque le plus immédiat concerne votre fichier .env. Les attaquants peuvent exécuter du code pour lire vos variables d'environnement, obtenant instantanément accès à vos clés secrètes AWS, vos mots de passe de base de données, vos clés API Stripe et vos tokens OpenAI.

L'accès « Shell »

Comme le nom « React2Shell » l'indique, les attaquants peuvent ouvrir un reverse shell. Cela leur donne une interface en ligne de commande sur votre serveur, leur permettant de parcourir votre système de fichiers comme s'ils étaient assis devant votre ordinateur.

Mouvement latéral

Une fois à l'intérieur de votre serveur NodeJS, ils se trouvent derrière votre pare-feu. Ils peuvent alors attaquer vos services internes (comme Redis, des bases de données internes ou des micro-services privés) qui sont habituellement bloqués du monde extérieur.

Empoisonnement de la chaîne d'approvisionnement

Si votre serveur de build est vulnérable, un attaquant pourrait potentiellement injecter du code malveillant dans votre pipeline de déploiement, affectant chaque utilisateur qui visitera votre site à l'avenir.

Recrutement dans un botnet

Les pirates automatisent souvent ces attaques pour installer des crypto-mineurs, utilisant le processeur de votre serveur (que vous payez !) pour miner de la monnaie numérique pour eux, faisant souvent planter votre application au passage.

Quel serait le changement de code pour cela ?

Vous n'avez pas besoin de réécrire le code de votre application, mais vous devez mettre à jour vos dépendances dans votre ligne de version.

La vulnérabilité est entièrement résolue dans les versions corrigées suivantes de NextJS :

  • 15.0.5

  • 15.1.9

  • 15.2.6

  • 15.3.6

  • 15.4.8

  • 15.5.7

  • 16.0.7

Versions canary corrigées pour NextJS 15 et 16 :

  • 15.6.0-canary.58 (pour les versions canary 15.x)

  • 16.1.0-canary.12 (pour les versions canary 16.x)

Ces versions incluent l'implémentation renforcée des React Server Components.

Voici les versions corrigées pour React JS :

  • 19.0.1

  • 19.1.2

  • 19.2.1

Les frameworks et les bundlers utilisant les paquets susmentionnés doivent installer les dernières versions fournies par leurs mainteneurs respectifs.

Alternativement, vous pouvez exécuter npx fix-react2shell-next dans votre projet NextJS pour lancer un outil interactif capable de vérifier les versions et d'effectuer des montées de version déterministes selon les versions recommandées ci-dessus. Consultez le dépôt GitHub pour tous les détails.

Il n'y a pas de solution de contournement autre que la mise à jour vers une version corrigée.

Il est fortement recommandé de renouveler tous les secrets de votre application une fois que vous avez appliqué le correctif et redéployé votre application.

Avancé : Vérifier avec l'exploit original (PoC)

Si vous voulez être sûr à 100 % que votre correctif fonctionne, ou si vous voulez comprendre comment l'attaque fonctionne réellement, vous pouvez utiliser la preuve de concept (PoC) originale créée par le chercheur en sécurité (Lachlan Davidson) qui a découvert le bug.

Dépôt : React2Shell-CVE-2025-55182-original-poc

Lachlan a fourni trois variantes du script d'exploit. La plus importante pour les tests est 01-submitted-poc.js, qui est la version exacte et simplifiée soumise à Meta pour le programme de bug bounty.

Comment fonctionne l'exploit

Selon le dépôt, l'attaque fonctionne en trompant l'analyseur (parser) :

  1. L'attaquant envoie une charge utile (payload) utilisant $@x pour accéder à un Chunk de données spécifique.

  2. Il « plante » une fonction .then sur un faux objet.

  3. Le runtime JavaScript pense qu'il gère une Promise et essaie de la « résoudre ».

  4. Cela permet à l'attaquant de rentrer à nouveau dans l'analyseur avec un faux chunk malveillant, lui donnant accès aux gadgets internes du serveur (comme _response) pour exécuter du code (RCE).

Étapes pour recréer le problème

⚠️ AVERTISSEMENT : Ne lancez cela que contre un serveur de développement local (localhost) qui vous appartient. Ne lancez jamais cela contre des serveurs de production ou des sites web publics.

Note : J'ai forké le dépôt de Lachlan et apporté des modifications mineures pour vous faciliter l'exécution du script.

Étape 1 : Cloner le dépôt

Exécutez les commandes suivantes pour cloner le dépôt, accéder au projet et installer les dépendances :

git clone https://github.com/arunachalam-b/React2Shell-CVE-2025-55182-original-poc.git
cd React2Shell-CVE-2025-55182-original-poc
npm i

Étape 2 : Lancer un serveur local vulnérable

Démarrez votre application NextJS localement (assurez-vous qu'elle utilise une version vulnérable, par exemple NextJS 15.0.0, pour que le test réussisse).

npm run dev
# tourne généralement sur http://localhost:3000

Étape 3 : Exécuter le test

Vous devrez modifier le script ou utiliser un outil comme curl pour envoyer la structure de la charge utile trouvée dans 01-submitted-poc.js au point de terminaison de votre serveur (généralement un endpoint de Server Action). Ou exécutez simplement la commande suivante si votre application est accessible sur http://localhost:3000 :

node 01-submitted-poc.js

Si l'exploit réussit (sur la version vulnérable), la console affichera l'exécution du code (RCE). Si l'exploit échoue (après avoir appliqué le correctif), le serveur rejettera la requête ou générera une erreur de manière sécurisée.

Cette réponse lors de l'exécution du script indique que votre serveur est vulnérable

Vous pouvez également confirmer si votre serveur web infecté affiche 50 dans la console. En effet, nous injectons le code pour effectuer un calcul (regardez le champ _prefix dans le JSON ci-dessous) qui donne 50.

La charge utile utilisée pour démontrer ce piratage

Le 50 dans votre console NextJS indique que le code du pirate a été exécuté sur votre serveur

Après avoir appliqué le correctif, vous devriez voir une erreur lors de l'exécution du script. Dans ce cas, comme j'utilise NextJS v15.1, le correctif consiste à mettre à jour le paquet next vers la version 15.1.9. Voici les captures d'écran après la mise à jour du paquet et l'exécution du script.

Réponse lors de l'exécution du script après application du correctif

La console n'affiche pas 50 lors de l'exécution du même script, ce qui indique que le code du pirate n'est pas exécuté sur votre serveur après application du correctif

Étape 4 : Vérification

Une fois que vous avez confirmé que l'exploit fonctionne sur l'ancienne version, mettez à jour vos paquets (comme indiqué dans la section ci-dessus) et relancez le script. Il ne devrait plus déclencher l'exécution de code.

Réponse d'urgence : que faire si vous avez déjà été compromis ?

Si vous soupçonnez que votre serveur a été exposé à Internet avec une version vulnérable, supposez le pire. Un pirate a peut-être déjà volé vos clés ou laissé une « porte dérobée » (backdoor) pour revenir plus tard. Corriger le code seul n'est PAS suffisant dans ce cas.

Suivez immédiatement ce protocole « Nuke and Pave » :

Étape 1 : Isoler et éteindre

Mettez le serveur compromis hors ligne immédiatement. N'essayez pas de le « réparer » pendant qu'il fonctionne.

Étape 2 : Renouveler TOUS les secrets (Étape cruciale)

Considérez que chaque secret de votre fichier .env est entre les mains d'un pirate. Vous devez en générer de nouveaux :

  • Changez le mot de passe de vos utilisateurs de base de données.

  • Renouvelez les clés d'accès AWS, les clés de compte de service Google Cloud, etc.

  • Changez vos clés API Stripe/PayPal/Razorpay.

  • Renouvelez votre NEXTAUTH_SECRET ou toute clé de signature JWT.

Étape 3 : Ne pas « nettoyer » — Reconstruire

N'essayez pas de trouver et de supprimer les fichiers malveillants sur le serveur. Les pirates sont doués pour se cacher.

  • Détruisez entièrement le conteneur, le droplet ou l'instance EC2 existant.

  • Construisez une nouvelle instance à partir de votre code source (après avoir appliqué le correctif).

Étape 4 : Auditer vos logs

Examinez les logs de votre base de données et de votre fournisseur cloud. Quelqu'un a-t-il téléchargé l'intégralité de votre base de données utilisateurs ? Quelqu'un a-t-il lancé des instances GPU coûteuses sur votre compte AWS ? Recherchez toute activité inhabituelle survenue avant que vous n'appliquiez le correctif.

Conclusion

Dans cet article, vous avez découvert la vulnérabilité « React2Shell », comment la vérifier à l'aide des outils du développeur original et comment mettre à jour votre application pour sécuriser vos Server Components. J'espère que vous comprenez mieux pourquoi cette mise à jour est urgente. En étant proactif dès maintenant, vous pouvez éviter une violation de données catastrophique.

Vous pouvez suivre mon compte Twitter/X pour recevoir les meilleures actualités sur l'IA chaque jour. Si vous souhaitez en savoir plus sur la cybersécurité, abonnez-vous à ma newsletter par e-mail et suivez-moi sur les réseaux sociaux.