Le monde de la cybersécurité est en ébullition à cause de React2Shell (CVE-2025-55182), une vulnérabilité critique d'exécution de code à distance (RCE) affectant React et Next.js. L'ampleur de la menace est massive : les chercheurs ont déjà identifié plus de 77 000 adresses IP vulnérables exposées sur Internet, et confirmé que des acteurs étatiques et des mineurs de cryptomonnaies opportunistes ont déjà compromis au moins 30 organisations.
Mais si l'on y regarde de plus près, ceci n'est pas vraiment une histoire concernant React.
C'est une histoire concernant le vol d'identité d'infrastructure.
Lorsqu'un attaquant exploite React2Shell, il ne se contente pas de pénétrer dans votre réseau ; il devient votre application. Il hérite de l'identité, des clés API et de la confiance implicite que votre backend accorde à vos serveurs frontend. Cela transforme une faille de code en une crise d'identité pour vos API internes, brisant la frontière de confiance entre votre frontend et vos données critiques.
Le « pivot » : de la RCE frontend à la violation d'API
React2Shell exploite une faille dans le protocole « Flight » utilisé par les React Server Components pour sérialiser les données. En envoyant une charge utile malveillante, souvent dissimulée dans une requête HTTP standard utilisant l'en-tête next-action, un attaquant non authentifié peut tromper le serveur pour qu'il exécute du code arbitraire.
C'est là que l'histoire prend un tournant. Une fois qu'un attaquant parvient à exécuter du code sur votre serveur Next.js, il ne s'arrête pas là. Il prend essentiellement le contrôle d'un nœud de confiance au sein de votre réseau.
Selon les analyses approfondies de chercheurs en sécurité, les attaquants utilisent déjà ce point d'ancrage pour dérober des identifiants cloud, accéder aux services de métadonnées et déployer des portes dérobées comme Sliver. Pour vos systèmes backend, les requêtes provenant de ce serveur compromis semblent légitimes. Cela crée une rampe de lancement idéale pour des mouvements latéraux au sein de votre infrastructure.
L'impact réel : 7 façons dont React2Shell compromet vos API
Une fois cette tête de pont établie, l'attaquant peut utiliser le serveur compromis pour cibler votre écosystème d'API interne. Cela ouvre la porte à sept risques distincts :
- Accès aux API fantômes : Les attaquants peuvent scanner et accéder à des API de microservices internes qui n'étaient pas destinées à être exposées sur Internet, contournant ainsi l'obscurité qui les protège habituellement.
- Contournement des contrôles d'accès : Comme la requête provient d'une adresse IP interne de confiance (le serveur web), elle contourne souvent les contrôles d'authentification stricts, les règles de WAF ou les listes d'autorisation IP destinées au trafic externe.
- Vol d'identité cloud : Les attaquants ciblent spécifiquement les API de métadonnées cloud internes (par exemple, 169.254.169.254) pour voler des identifiants IAM temporaires, leur permettant d'élever leurs privilèges au sein de votre environnement cloud.
- Vol de données sensibles : Les attaquants peuvent interroger directement les bases de données backend ou les magasins de données utilisateurs, exfiltrant ainsi des quantités massives d'informations personnelles sans déclencher d'alertes périmétriques.
- Modification de la logique backend : Avec un accès aux API de configuration internes, les attaquants pourraient potentiellement altérer la logique métier ou s'octroyer un accès administratif persistant.
- Détournement de ressources : Les attaquants peuvent abuser de vos ressources API internes pour déployer des mineurs de cryptomonnaie ou lancer des attaques par déni de service (DoS) contre d'autres services internes.
- Compromission totale de l'environnement (mouvement latéral) : Depuis le serveur web, ils peuvent se déplacer latéralement vers d'autres conteneurs, des pipelines CI/CD ou des composants d'infrastructure sensibles.
Pourquoi la défense périmétrique ne suffit pas
Les outils de sécurité traditionnels comme les WAF peinent à détecter ce type de menace.
- L'exploitation initiale : La charge utile malveillante React2Shell contourne souvent les WAF car elle apparaît comme des données d'application sérialisées valides (en utilisant l'en-tête next-action).
- Le trafic interne : Une fois l'attaquant à l'intérieur, son trafic est Est-Ouest (d'un serveur interne à un autre). La plupart des outils de sécurité périmétrique sont aveugles à ce phénomène. Ils protègent la porte d'entrée, mais n'ont aucune visibilité sur ce qui se passe dans le couloir.
Comment Salt Security comble cette lacune
React2Shell démontre précisément pourquoi la visibilité des API Est-Ouest est cruciale. Vous ne pouvez pas vous reposer uniquement sur le périmètre.
Salt Security vous protège de deux manières essentielles :
1. Découverte de la surface d'attaque des API
Vous ne pouvez pas protéger votre backend si vous ne savez pas ce qu'il expose. Salt découvre automatiquement l'intégralité de votre empreinte API, identifiant les API fantômes et les points de terminaison internes qu'une interface compromise ciblerait. En cartographiant l'ensemble de votre parc d'API, Salt vous aide à comprendre le « rayon d'impact » potentiel d'une brèche frontale comme React2Shell, en vous assurant de savoir exactement quelles données et quels services critiques sont accessibles depuis votre couche web.
2. Surveillance de l'« initié de confiance » (trafic Est-Ouest)
L'aspect le plus dangereux de React2Shell est que l'attaque provient d'une source de confiance : votre propre serveur web. Pour votre réseau interne, ces requêtes semblent légitimes car elles proviennent d'une adresse IP valide et autorisée.
Salt Security adopte une approche différente. Nous ne nous contentons pas d'examiner la source du trafic ; nous analysons le comportement de l'identité.
- Établir une base de confiance : Salt établit une base de référence du comportement normal pour chaque actif. Nous savons que votre frontend Next.js appelle généralement des API grand public spécifiques pour récupérer le contenu des pages.
- Détection des abus post-exploitation : Si ce serveur de confiance commence soudainement à scanner des ports internes, à appeler des API administratives qu'il n'a jamais utilisées auparavant ou à interroger des services de métadonnées cloud (un signe clair de la chaîne d'attaque React2Shell), Salt identifie immédiatement cette anomalie. Nous détectons les conséquences de la brèche et le mouvement latéral, même si l'exploitation initiale a contourné le WAF.
Conclusion
React2Shell nous rappelle avec force que votre modèle de sécurité ne peut pas supposer que le frontend est sécurisé. Une simple faille dans un framework web peut retourner votre propre infrastructure de confiance contre vous.
Pour protéger vos données, vous devez regarder au-delà du périmètre et observer ce qui se passe derrière le serveur web. Corriger cette CVE spécifique est nécessaire, mais une véritable résilience exige une stratégie qui part du principe que la brèche a déjà eu lieu. Vous avez besoin de la visibilité approfondie et interne sur les API que seule Salt Security peut offrir, afin de garantir que lorsque la prochaine vulnérabilité zero-day du frontend frappera, vos données backend resteront hors de portée.
Si vous souhaitez en savoir plus sur Salt et sur la façon dont nous pouvons vous aider, veuillez nous contacter, planifier une démonstration, ou visiter notre site web. Vous pouvez également obtenir une évaluation gratuite de votre surface d'attaque API auprès de l'équipe de recherche de Salt Security et découvrir ce que les attaquants savent déjà.