Andrew Hanna
Tekunda Team
TL;DR : début décembre 2025, une vulnérabilité critique appelée React2Shell (CVE-2025-55182) a été divulguée dans React Server Components. Elle permettait l'exécution de code à distance sans authentification dans des configurations courantes React et Next.js, y compris des configurations par défaut. Des exploits sont rapidement apparus dans la nature, avec des serveurs compromis utilisés pour du cryptomining. Si votre application utilise React Server Components ou le Next.js App Router, il faut corriger et redéployer.
Pendant des années, les ingénieurs frontend ont appris un modèle mental rassurant : le navigateur est la frontière.
Le code frontend s'exécutait côté client, les systèmes backend géraient la confiance et la sécurité, et les frameworks aidaient à garder ces responsabilités clairement séparées. Ce modèle influençait la façon dont les équipes raisonnaient sur le risque, les revues et le déploiement.
React2Shell a brisé cette hypothèse de façon très concrète.
Dans les jours qui ont suivi la divulgation de CVE-2025-55182, des équipes aux rôles différents sont arrivées à la même conclusion depuis des angles différents, non pas à cause de la théorie, mais à cause de ce que les attaquants ont fait ensuite.
Les applications React modernes ne sont plus seulement du code UI. Elles s'exécutent comme une partie de l'infrastructure de production, et ce changement a permis à des campagnes opportunistes de transformer des serveurs exposés en charges de cryptomining.
Ce n'était pas dû à une mauvaise utilisation ni à des configurations exotiques. Cela a largement touché des versions adoptées de React et Next.js exécutées exactement comme documenté, ce qui explique la propagation rapide de l'impact.
React2Shell est une vulnérabilité critique dans React Server Components (RSC), une fonctionnalité React qui permet à certaines parties du code frontend de s'exécuter sur le serveur lors du traitement de vraies requêtes utilisateur.
Ce qui rendait cette vulnérabilité différente n'était pas seulement son emplacement, mais la façon naturelle dont elle s'inscrivait dans le traitement normal des requêtes.
Elle permettait aux attaquants de déclencher une remote code execution (RCE), une classe d'attaque où quelqu'un peut exécuter ses propres commandes sur un serveur en envoyant une requête spécialement construite, sans se connecter.
À haut niveau, l'attaque se déroulait ainsi :
Une fois cette chaîne comprise, la gravité était évidente.
Des proof-of-concept sont apparus peu après la divulgation. L'exploitation active a suivi rapidement, laissant peu de temps entre la compréhension et l'exposition.
L'une des leçons les plus importantes de React2Shell est le caractère ordinaire des configurations touchées. C'est précisément cette normalité qui a accéléré l'impact.
Ce n'étaient pas :
C'étaient :
React Server Components change fondamentalement l'endroit où la logique frontend s'exécute. Résultat, le code frontend :
React2Shell n'a pas créé ce changement. Il a forcé les équipes à l'affronter.
Dès que la vulnérabilité est devenue publique, l'exploitation a suivi presque aussitôt.
Les fournisseurs cloud et les chercheurs en sécurité ont rapidement signalé des attaques réelles, souvent opportunistes plutôt que ciblées.
Les systèmes compromis montraient :
Dans plusieurs cas rapportés, les équipes redéployaient les serveurs à répétition, pour être réinfectées ensuite. Ce schéma révélait le vrai problème.
Le problème n'était pas le nettoyage. Le runtime vulnérable était toujours en place.
Les défenses en couches ont aidé, mais elles ne pouvaient pas compenser une dépendance cœur non corrigée.
À haut niveau, React2Shell était rendu possible par la façon dont React Server Components sérialise et désérialise les données via le protocole React Flight. Les attaquants pouvaient abuser de ce chemin de traitement pour atteindre une exécution côté serveur, et dans Next.js ce même chemin pouvait être déclenché par le routage des requêtes lié aux server actions.
Pour l'analyse complète du protocole, du chemin d'exploitation et des mesures d'atténuation, lisez l'analyse technique de Darktrace de bout en bout.
React2Shell a clarifié quelque chose qui évoluait discrètement depuis des années.
Si votre framework frontend :
Alors il mérite le même niveau de contrôle opérationnel qu'un service backend.
Ce n'est pas un échec de l'ingénierie frontend. C'est la conséquence naturelle d'abstractions puissantes devenues infrastructure de production.
Les frameworks modernes échangent les frontières explicites contre la vitesse et l'expérience développeur. Ce compromis ne supprime pas la responsabilité, il la déplace.
À mesure que les recommandations apparaissaient, les réponses convergeaient. Les équipes qui ont réagi vite ont suivi le même plan.
1. Identifier l'exposition
2. Corriger et redéployer
3. Supposer une post-exploitation
4. Traiter les mises à jour de framework comme des changements de
production.
Les mises à jour de framework affectent le comportement runtime. Elles ne sont pas
cosmétiques.
React2Shell n'a pas détruit la confiance dans React. Il a révélé la confiance que les stacks modernes portent déjà par défaut.
Le vrai changement n'est pas "corriger plus vite". C'est reconnaître que le comportement du framework est une infrastructure de production, et le traiter avec la même discipline que les APIs, l'authentification et les déploiements.
Chaque écosystème équilibre :
Il n'existe pas de stack parfaitement sûre, seulement des stacks bien comprises.
Les équipes qui ont le mieux géré cet incident n'étaient pas celles qui avaient le plus d'outils. C'étaient celles qui comprenaient ce qui s'exécutait où, et pouvaient répondre avec méthode.
React2Shell s'est propagé rapidement non parce qu'il était sophistiqué, mais parce qu'il correspondait à la façon dont les frameworks modernes sont construits et déployés.
Si vous exécutez React Server Components ou le Next.js App Router en production, traitez cela comme tout autre incident runtime : corrigez, redéployez et vérifiez que vous n'étiez pas déjà touché.
Et à l'avenir, appliquez la même règle partout : si cela s'exécute sur le serveur, cela mérite une discipline de niveau serveur.
Andrew Hanna
Serpent Team
Tekunda Team
Tekunda Team
Tekunda Team
Andrew Hanna