React à Shell : L’Exploit critique qui a failli mettre le feu à internet

Au cas où vous l’auriez manqué, une grande partie d’internet s’est mise à courir dans tous les sens comme des poulets sans tête à cause d’une vulnérabilité critique dans React. Ce n’est pas quelque chose que nous avons l’habitude d’avoir sur notre carte de bingo 2025. Il s’agit d’une vulnérabilité d’exécution de code à distance non authentifiée et ils recommandent de mettre à jour immédiatement car il s’agit d’un CVSS 10.0, le plus élevé possible. La vulnérabilité est présente dans les versions 19.0, 19.1.0, 19.1.1 et 19.2.0 de nombreux éléments utilisant le serveur React.

Je tiens à préciser que je ne suis pas un spécialiste du front-end. Je n’utilise pas beaucoup React ou Next.js et, pour être honnête, je ne m’y connais pas beaucoup. Je vais donc m’en remettre aux autres pour cette partie.

Pour être clair, nous suivons ici 2 vulnérabilités différentes. Celle dont j’ai montré à nouveau l’entrée NVD était React, mais 66478 est spécifique à Next.js. La vulnérabilité provient de l’implémentation React en amont. C’est notre référence 55182, mais cet avis avec 66478 est spécifique à l’utilisation du routeur d’application dans Next.js. Encore une fois, le lien se trouve dans la description de la vidéo.

Parlons de la preuve de concept

React propose des fonctions serveur, qui sont essentiellement similaires à RPC ou à un appel de procédure à distance via HTTP. Elles récupèrent des données à partir d’autres instances afin de garantir une faible latence ou d’effectuer des requêtes d’authentification pour lesquelles le client ne dispose pas d’informations d’identification. React utilise pour cela le protocole React Flight. Cela aboutit à la sérialisation ou à la désérialisation des valeurs. Tout cela est représenté ou encapsulé sous forme de différents blocs. Et vous pouvez voir ici un peu de logique à cela.

Zéro, en tant que premier index, est défini avec une sorte de chaîne qui ressemble à un signe dollar entre crochets pour représenter une entité, un objet abstrait. Puis, plus loin dans l’entrée suivante ID de un ici, ils ajoutent plus de structure à cet objet en notant qu’il s’agit d’un fruit avec une propriété donnée, le nom d’un fruit, et que la valeur de cette propriété pourrait être quelque chose comme cerise. Et ensuite, ceux-ci sont référencés. Ils finissent par désérialiser les données pour représenter un objet fruit avec un nom donné, cerise.

Bien sûr, cela peut faire beaucoup plus, mais je pense que cela suffit pour comprendre. La vulnérabilité réside finalement dans le fait que cela ne sera pas vérifié ou que React lui-même ne vérifie pas si la clé est définie pour l’objet. Vous pouvez donc récupérer le prototype ou un peu plus de valeurs de champs de métadonnées inhérentes et implicites à cette idée abstraite. Ils utilisent cela lorsqu’ils prennent cet ID ou cet ID de chunk zéro signe dollar un, mais en accédant en fait à une fonction spéciale proto prototype dunder pour pouvoir accéder non pas à cette fonction, mais au constructeur et au constructeur pour accéder à la fonction d’initialisation de cet objet.

Eh bien, je pense qu’il y a une astuce, car vous ne pouvez pas appeler la fonction aussi facilement, mais vous pouvez récupérer le constructeur de la fonction. Ensuite, vous voudrez éventuellement l’exécuter, mais avec une valeur contrôlée par l’utilisateur, comme ce que vous voulez déclencher et exécuter. Ce n’est toutefois pas aussi facile. Apparemment, je pense qu’il reste d’autres artefacts dans le langage et dans la manière de désérialiser ou de travailler avec les données. Je suppose que slice est une fonction qui gêne.

Je ne vais pas prétendre que je comprends tout ce qui se passe ici, mais ce n’est pas grave. Au final, ils disposent d’une mise en scène suffisante pour créer un objet avec des propriétés vagues que le proto et le prototype sont capables de décorer et de créer un chunk qui pourrait utiliser certaines des fonctionnalités plus natives et naturelles auxquelles nous sommes habitués dans le monde du CTF ou du capture the flag, où nous pouvons exécuter un sous-processus réel et lancer certains processus de commande système. Le processus enfant et l’exécution se synchronisent avec tout ce que vous voulez lancer. Peut-être s’agit-il d’un shell inversé. Peut-être s’agit-il d’un code. Peut-être s’agit-il de la calculatrice comme preuve de concept.

Tout ce travail de désérialisation est effectué avant même que l’action demandée ne soit validée dans certaines des autres fonctions qui font partie du processus ici. Ainsi, le simple fait de définir un en-tête suffit à déclencher la vulnérabilité. Je pense que cela provient des actions du serveur React dans l’une des anciennes représentations ou de la façon dont ils appelaient auparavant de nombreux composants du serveur React.

Vous remarquerez qu’ils font des essais avec cela dans Burp Suite. Ils viennent de lancer OBS pour enregistrer cela. Ils ont lancé une application React et Next par défaut, puis ils ont simplement cliqué sur le bouton « Go » dans Burp Suite lorsque celui-ci était réglé sur la cible pour envoyer cette requête. C’est comme un défi amusant NodeJS ou tout autre défi de runtime JavaScript sur serveur que vous verriez dans un capture the flag.

Conclusion : Patchez et corrigez !

Je pense que cela va probablement exploser et aboutir à un scénario de type log4shell. Je suis désolé pour ce traumatisme et ce syndrome de stress post-traumatique.

Je pense que pour tous ceux qui utilisent Vercel, il semble que Big G partage le fait que leur petit garçon va s’en occuper et verrouiller cela. Cela bloquera la variante. Mais corrigez, mettez à jour, patchez, corrigez tout ce que vous pouvez. Faites ce que vous avez à faire.

Le correctif : une simple vérification

La solution déployée par l’équipe React est étonnamment simple dans son principe : ajouter une vérification stricte pendant la désérialisation.

1. Identifiez et mettez à jour : Vérifiez immédiatement les versions de React (>= 19.2.1) et de Next.js (>= 15.2.4) dans vos projets. Mettez à jour sans délai.
2. Ne sous-estimez pas l’impact : Même si vous n’utilisez pas les Actions Serveur, la composante vulnérable peut être présente. Le principe de précaution s’applique.
3. Pour les utilisateurs de Vercel : La plateforme a appliqué des atténuations, mais mettre à jour votre code source reste impératif.
4. Surveillance : Examinez les logs de vos applications pour détecter toute tentative d’exploitation (requêtes HTTP étranges vers les endpoints d’actions).

Questions fréquentes

Quelles versions de React sont concernées par cette vulnérabilité ?

Les versions concernées sont 19.0, 19.1.0, 19.1.1 et 19.2.0, principalement dans les composants serveur React.

Qu’est-ce que React to Shell ?

C’est une vulnérabilité critique de type RCE (Remote Code Execution) non authentifiée, exploitée via la désérialisation dans les composants serveur React.

Next.js est-il également concerné ?

Oui, Next.js est concerné via le CVE-2024-66478, qui concerne l’utilisation du routeur d’application avec React Server Components.

Comment l’exploit fonctionne-t-il ?

Il exploite une faiblesse dans la désérialisation des chunks React Flight, permettant d’exécuter du code arbitraire côté serveur via des requêtes HTTP spécialement conçues.

Quelle est la solution ?

Mettre à jour immédiatement React, Next.js et tous les composants associés. Le patch consiste à vérifier la présence du prototype dans les chunks désérialisés.