React2Shell exploite Next.js pour un pillage massif des pouvoirs qui compromet 766 hôtes en 24 heures

Une opération automatisée puissante profite d'une vulnérabilité dans les applications Next.js pour commencer un vol massif d'identifications qui, selon les chercheurs, a déjà compromis des centaines de serveurs dans le cloud. Le vecteur exploité est connu comme React2Shell (CVE-2025-55182) et, une fois que l'attaquant a accès, développe des scripts qui montrent et exfiltrent des secrets, des clés et des identifiants systématiquement.

Les détails techniques et le suivi de la campagne ont été documentés par les analystes de Cisco Talos, qui attribuent l'opération à un ensemble de menaces identifiées comme étant UAT-10608. Dans leurs recherches, les experts ont pu accéder à un corps exposé du composant de contrôle appelé NEXUS Listar, qui leur a permis d'observer des informations en direct que les intrus recueillaient et comment ils les présentaient : une interface qui regroupe et facilite la recherche, le filtrage et les statistiques des secrets supprimés. Le rapport Talos peut être consulté afin d'élargir les conclusions et de voir les captures dans les panneaux : Cisco Talos - À l'intérieur d'une opération de reconnaissance automatique à grande échelle.

Le modus operandi décrit par les chercheurs commence par des scans automatisés à la recherche de la vulnérabilité Next.js. Après avoir exploité React2Shell, l'attaquant dépose un script dans un répertoire temporaire qui exécute une routine multiphase pour extraire des secrets et des fichiers sensibles. Ce matériel est emballé en fragments et envoyé par HTTP au serveur de commande et de contrôle - le Listar NEXUS - par le port 8080, où il est indexé et disponible pour analyse par des opérateurs malveillants.

L'ampleur de l'incident est frappante : Talos a déclaré que l'infrastructure opérationnelle était en mesure de compromettre au moins 766 hôtes dans les 24 heures. Parmi les éléments que les attaquants collectés sont des variables d'environnement et des secrets d'application (clés API, identifiants de base de données, jetons GitHub / GitLab), clés SSH privées, identifiants de cloud (métadonnées et identifiants AMI d'AWS / GCP / Azure), jetons Kubernetes, informations conteneur et Docker, histoires de commande et données de processus en cours.

Le risque ne se limite pas à la perte en temps opportun de secrets. Avec ces éléments, un attaquant peut effectuer la prise de comptes en nuage, l'accès aux bases de données et aux systèmes de paiement, se déplacer latéralement en utilisant les clés SSH ou lancer des attaques de chaîne d'approvisionnement en utilisant un accès persistant. Il y a aussi un coût réglementaire parce que l'exfiltration peut inclure des données à caractère personnel soumises à des règles de confidentialité.

Face à ces campagnes, les recommandations des équipes d'intervention combinent action immédiate et action stratégique. De toute urgence, il est essentiel d'appliquer les correctifs qui ferment React2Shell et, à la lumière de la moindre suspicion d'exposition, de faire pivoter tous les pouvoirs concernés. Cisco Talos insiste sur la nécessité de vérifier les expositions de données possibles sur le serveur et de remplacer les clés SSH réutilisées. Pour la défense au niveau du cloud, il est recommandé de forcer l'utilisation d'IMDSv2 dans les instances AWS EC2 pour rendre difficile l'obtention de métadonnées d'instances à partir de processus engagés; la documentation officielle AWS explique comment configurer et forcer IMDSv2: AWS - Configuration du service de métadonnées d'instance.

Parmi les autres mesures préventives, on peut citer l'adoption d'un scan secret dans les dépôts et les pipelines (par exemple, des solutions pour balayage secret offrir des plateformes telles que GitHub), la rotation régulière et automatisée des références, l'application stricte du principe de privilège moindre dans les rôles et les permissions des conteneurs et des comptes cloud, et la mise en œuvre de protections d'applications telles que WAF ou RASP pour réduire la probabilité de défaillances d'exploitation dans les applications web. GitHub documente ses capacités de détection secrète dans le code et dans l'historique du dépôt: GitHub - Numérisation secrète, et le guide de gestion des secrets OWASP offre de bonnes pratiques de stockage et de rotation: OWASP - Gestion des secrets Cheat Sheet.

Dans le plan opérationnel, il convient également de renforcer la détection et la télémétrie : surveiller les connexions HTTP sortantes vers des ports inhabituels (comme 8080) à partir de serveurs d'applications, examiner les processus et les fichiers dans / tmp à la recherche de scripts malveillants, vérifier l'historique des commandes et les fichiers de configuration des conteneurs, et établir des alertes anormales pour l'utilisation de clés et de jetons. Limiter le trafic de sortie à des destinations connues et forcer le filtrage de décharge réduit la capacité d'un intrus d'exfiltrer les données à l'infrastructure C2.

Cette campagne met à nouveau sur la table deux idées simples mais critiques : premièrement, que les vulnérabilités de la couche d'application restent une passerelle extrêmement lucrative pour les attaquants; et deuxièmement, que la protection des secrets et des lettres de créances doit être à la fois préventive et réactive. Appliquer les correctifs rapidement, vérifier l'exposition des informations sensibles et avoir des processus automatiques pour faire tourner et détecter les secrets filtrés sont des étapes minimales qui peuvent maintenant faire la différence entre un incident confiné et un écart avec des conséquences de grande portée.

Pour lire l'analyse technique et les indicateurs partagés par les chercheurs, voir le rapport Cisco Talos : À l'intérieur d'une opération de reconnaissance automatique à grande échelle. Si vous avez besoin de conseils pratiques pour vérifier votre environnement ou prioriser les mesures d'atténuation, les guides AWS et OWASP ci-dessus sont de bons points de départ.