React2Shell est le moment Log4j pour le développement front-end

Les attaquants ont augmenté la mise en exploitant une vulnérabilité de gravité maximale récemment révélée dans React Server Components (RSC), Next.js et les frameworks associés.

Des attaquants motivés par des raisons financières ont trouvé un moyen d’utiliser la faille, baptisée React2Shell (CVE-2025-55182), pour exécuter du code arbitraire sur des serveurs vulnérables via une seule requête HTTP malveillante. Cela leur permet d’accéder rapidement et facilement à un réseau d’entreprise et de déployer des ransomwares, selon les chercheurs de la société de cybersécurité S-RM et l’équipe de recherche sur la sécurité de Microsoft Defender.

Les attaquants ont initialement exploité cette vulnérabilité pour introduire des logiciels malveillants par porte dérobée et des mineurs de crypto ; Cette nouvelle méthode représente une escalade, et les experts affirment qu’elle révèle une faille de sécurité fondamentale dans le développement front-end.

« Pendant trop longtemps, nous avons traité le développement frontal comme un travail bas de gamme et à faible risque », a déclaré David Shipley de Beauceron Security. « C’est au front-end des applications ce que Log4j était au back-end, une énorme opportunité pour les attaquants. »

Comment les attaquants obtiennent facilement un accès « hautement privilégié »

React est largement utilisé dans les environnements d’entreprise, les chercheurs de Microsoft identifiant « des dizaines de milliers d’appareils distincts dans plusieurs milliers d’organisations » exécutant React ou des applications basées sur React.

React2Shell est une vulnérabilité d’exécution de code à distance (RCE) de pré-authentification affectant React Server Components (RSC), le framework open source Next.js et d’autres frameworks associés. Il a été noté 10 sur le Common Vulnerability Scoring System (CVSS) car il est facile à exploiter, met en danger de nombreux systèmes exposés et est très vulnérable aux attaques automatisées car son exécution ne nécessite pas d’authentification.

La vulnérabilité affecte spécifiquement le protocole Flight, une fonctionnalité essentielle de la bibliothèque de développement React et Next.js. RSC contient des packages, des frameworks et des bundles qui permettent aux applications React d’exécuter une partie de leur logique sur le serveur plutôt que dans le navigateur.

Flight permet au serveur et au client de communiquer ; lorsque le client demande des données, le serveur reçoit et analyse une charge utile, exécute la logique côté serveur et renvoie un progiciel lisible par l’homme.

Avec la vulnérabilité React2Shell, les RSC concernés ne parviennent pas à valider les charges utiles entrantes, permettant aux acteurs malveillants d’injecter des composants malveillants que React identifie comme légitimes. Les attaquants peuvent envoyer des requêtes HTTP pour inciter le serveur à exécuter du code compromis, leur donnant potentiellement un accès « hautement privilégié » à des systèmes non corrigés, selon les chercheurs de S-RM.

Selon les premiers rapports sur React2Shell, les acteurs étatiques ont commencé à exploiter la vulnérabilité quelques heures après sa divulgation publique. Alors que les premiers impacts se limitaient à l’installation de portes dérobées persistantes dans les réseaux et à l’extraction de cryptomonnaies, React2Shell est désormais utilisé comme vecteur d’accès initial dans une attaque de ransomware.

S-RM note qu’il est probablement utilisé par des « acteurs moins sophistiqués » ciblant les serveurs Web publics.

Les chercheurs de Microsoft mettent en garde contre les dangers de cette vulnérabilité : elle peut être exploitée avec une seule requête HTTP ; les configurations par défaut sont vulnérables, ce qui signifie qu’il n’y a pas de configuration spéciale et que les attaquants n’ont pas à attendre les erreurs des utilisateurs ; l’exploitation ne nécessite pas d’authentification car elle se produit avant l’authentification ; et les exploits de preuve de concept montrent une fiabilité proche de 100 %.

« Malgré tous les discours excessifs sur la confiance zéro, voici un excellent exemple de cas où cela aurait été utile », a déclaré Shipley de Beauceron. « Beaucoup trop de confiance et d’accès ont été intégrés au modèle React. Et les attaquants ont compris comment l’exploiter. »

Que chercher

Dans une attaque suivie par S-RM, immédiatement après que l’acteur malveillant ait accédé au réseau d’une entreprise ciblée, ils ont exécuté une commande PowerShell cachée, établissant le commandement et le contrôle (C2) en téléchargeant un stager Cobalt Strike PowerShell, une tactique régulièrement utilisée par les équipes rouges, et en installant une balise pour leur permettre de communiquer avec leurs serveurs externes. Ils ont ensuite désactivé la protection en temps réel dans Windows Defender Antivirus.

Le binaire du ransomware a été abandonné et exécuté « moins d’une minute après l’accès initial », rapportent les chercheurs de S-RM. Les attaquants ont modifié les fichiers cryptés, laissé des notes de récupération, créé des fichiers texte contenant l’adresse IP publique de la cible et effacé les journaux d’événements et les instantanés de sauvegarde.

Les chercheurs ont noté qu’ils n’avaient pas observé de mouvement latéral vers d’autres systèmes ni de tentatives de vol de données. Le serveur compromis a été mis hors service le lendemain de sa découverte.

S-RM conseille aux entreprises utilisant RSC de vérifier qu’il s’agit d’une version entièrement corrigée ; cependant, React a averti que même les correctifs initialement publiés (versions 19.0.2, 19.1.3 et 19.2.2) sont vulnérables.

Au-delà de l’application des correctifs, les organisations doivent effectuer des examens médico-légaux pour vérifier :

• Connexions sortantes inhabituelles pouvant indiquer que C2 a été exécuté ;
• Désactivation de l’antivirus et de la protection des points finaux, ou suppression ou falsification des journaux ;
• Des pics inhabituels dans l’utilisation des ressources, qui pourraient indiquer des mineurs de crypto ;
• Journaux d’événements Windows ou télémétrie de détection et de réponse des points de terminaison (EDR) indiquant que les attaquants ont exécuté des fichiers en mémoire à partir de binaires liés à Node ou React.
• Indicateurs de compromission (IOC) détaillés dans l’avis, à la fois basés sur l’hôte et sur le réseau.

Le front-end n’est plus à faible risque

Cette vulnérabilité révèle une lacune fondamentale dans l’environnement de développement qui a été largement négligée, affirment les experts.

« Il y a un mensonge dangereux et réconfortant que nous nous disons dans le développement Web : ‘Le frontend est sûr.’ Ce n’est pas le cas », note l’ingénieur Web Louis Phang. Il a qualifié cela d’« erreur logique dans la façon dont les serveurs modernes communiquent avec les clients », qui transforme une requête Web standard en une arme. C’est le résultat de développeurs qui se concentrent sur la fiabilité, l’évolutivité et la maintenabilité plutôt que sur la sécurité.

Pendant des années, tout ce qui se produisait lorsqu’un développeur front-end faisait une erreur était qu’un bouton qui ne semblait pas correct, une mise en page cassée ou, dans le pire des cas, le Cross-Site Scripting (XSS), qui permet aux attaquants d’injecter des scripts malveillants dans des pages Web, était possible, a déclaré Phang. Avec le rendu React sur le serveur, le code frontal bénéficie d’un accès privilégié et les vulnérabilités servent de porte dérobée vers les bases de données, les clés et les données.

« React2Shell signifie la fin du rôle de développeur front-end en tant que rôle à faible risque », a soutenu Phang.

Shipley de Beauceron a accepté, soulignant que la nécessité d’un gros travail côté serveur modifiait le risque, mais la pile technologique n’a pas réagi en conséquence.

« Au début, nous ne savions pas si la situation était grave ou non, puis certains ont minimisé l’ampleur de l’exploitation, et maintenant nous sommes dans une frénésie alimentaire », a-t-il déclaré.

Il s’agit de savoir combien de temps il faudra pour inciter l’environnement technologique à faire face à cette menace ; cela pourrait en fin de compte être un effet secondaire des coupes dans les équipes et les budgets de sécurité et de l’épuisement professionnel des développeurs, a-t-il noté.

« Il s’agit d’une tendance inquiétante à l’horizon 2026, qui sera encore plus intense pendant le zéro jour grâce à l’IA », a prédit Shipley.