React2Shell : quand le framework de Meta ouvre la porte de vos serveurs aux attaquants

Depuis plusieurs années, la bibliothèque open source JavaScript React, développée par Meta, anciennement Facebook, domine le marché. Cette bibliothèque permet de construire des interfaces utilisateur côté client, créant des composants interactifs.

L’un de ceux-ci, React Server Component – ou RSC, permet une exécution directement côté serveur avant d’être envoyé au navigateur.

Le framework Next.js, quant à lui, est directement basé sur React. Il facilite le développement d’applications web avec rendu hybride. Pour preuve, s’il en fallait, de l’usage massive de ce framework, le 08 novembre 2025, plus de 55 millions de sites l’utilisait.

Le 03/12/2025, une vulnérabilité critique a été découverte dans React Server Component et par rebond sur Next.js, enregistrées sous deux CVE : CVE-2025-55182 et CVE-2025-66478. Pour anecdote, la CVE Next.js a été rejeté car faisait doublon à la première, et donc sans intérêt.Appelée React2Shell, la CVE-2025-55182 fait partie du cercle très fermé des vulnérabilités avec un score CVSS de 10.0 (sur 10). En effet, l’une des bibliothèques JavaScript les plus utilisées, React de la version 19.0.0 à la 19.2.0 est vulnérable à une exécution de code par un attaquant non authentifié. Plus particulièrement, ce sont les packages suivants qui sont touchés par cette vulnérabilité :

• react-server-dom-parcel, pour le bundle Parcel
• react-server-dom-turbopack, pour le bundle Turbopack
• react-server-dom-webpack, pour le bundle Webpack

D’après les dernières recherches, il est possible d’exploiter la vulnérabilité même si aucune fonction React Server n’est utilisée mais que RSC est pris en charge.Pour Next.js, les versions affectées sont les suivantes :

• 15.x
• 16.x
• 14.3.0-canary.77 et toutes les canary suivantes

Pour React, les frameworks et bundlers suivant utilisent les versions vulnérables de RSC :

• react-router
• waku
• parcel/rsc
• vitejs/plugin-rsc
• rwsdk

Tout part d’une désérialisation mal filtrée. Tout d’abord, la désérialisation est un processus convertissant des données linéaires en objet ou structure lisible par un programme.Ici, une requête POST HTTP contient une charge utile qui lors de sa désérialisation dans une fonction de React Server permet d’exécuter du code et ainsi obtenir un accès sur le serveur. L’exploitation de la vulnérabilité est déjà accessible en ligne mais voici, en quelques mots comment elle marche. La vulnérabilité se base sur la présence de différents modules Node.js exploitables. La chaîne de compromission complète requiert les modules vm ou child_process afin d’obtenir un accès direct au serveur. Pour autant, une variante peut être exploitée si seul le module fs est installé. Dans ce cas, la compromission sera indirecte : un attaquant pourra s’ajouter des accès SSH ou encore déclencher un accès serveur programmé, au redémarrage de l’app ou au prochain npm install par exemple.La vulnérabilité se trouve dans les fichiers

react-server-dom-webpack-server.node.development.js, 

react-server-dom-turbopack-server.node.development.js 

et react-server-dom-parcel-server.node.development.js.

Pour bien comprendre la vulnérabilité, il faut remonter la pile d’exécution :

Une vulnérabilité aussi facile d’exploitation dans une bibliothèque JavaScript aussi massivement utilisée représente un risque considérable. Des milliers d’application Web sont vulnérables à une attaque simple à exploiter.La CVE concernant Next.js est plus complexe à mettre en œuvre, en raison d’une vérification supplémentaire dans la fonction

resolveServerReference

qui rend l’exploitation plus complexe sans la rendre impossible pour autant.

Pour savoir si vous avez été ciblé, vous devez vérifier vos logs. Ciblez les champs

$ACTION_REF_ et $ACTION_ID_

avec des mots clefs tels que #constructor ou encore

#__proto__

dans le champ ID. Regardez également dans les logs de l’application les références aux modules

vm, child_process ou encore process 

par exemple.

Elisa SALFATI, Consultante/Auditrice Sécurité