React2Shell : la faille Next.js et React notée 10 sur 10, que faire

Le 3 décembre 2025, les équipes de React et de Next.js ont publié en urgence le correctif d'une faille notée 10 sur 10, la note maximale. Surnommée React2Shell, elle permet à un attaquant anonyme d'exécuter ses propres commandes sur le serveur qui fait tourner un site Next.js, par une simple requête web et sans aucun identifiant. Deux jours plus tard, l'agence américaine de cybersécurité (CISA) l'ajoutait à sa liste des failles activement exploitées. Si votre site vitrine, votre espace client ou votre application métier a été développé en Next.js, cet article est pour vous.

Vérifiez votre site en 30 secondes. Notre test de sécurité de site gratuit lit la version de Next.js que votre site publie dans ses fichiers publics et la compare aux versions corrigées, sans rien attaquer.

#1. Ce qui se passe, en cinq points

• Une faille dans React lui-même : CVE-2025-55182 touche les React Server Components, la technologie qui permet d'exécuter une partie de l'application côté serveur. Les paquets concernés sont react-server-dom-webpack, react-server-dom-parcel et react-server-dom-turbopack, en versions 19.0.0, 19.1.0, 19.1.1 et 19.2.0.
• Next.js est le premier touché : il embarque ces composants. Sont concernées les versions 15.x et 16.x, ainsi que les préversions à partir de 14.3.0-canary.77, quand le site utilise l'App Router (le mode de routage proposé par défaut aux nouveaux projets depuis Next.js 13.4).
• Pas touchés : Next.js 13.x et 14.x stables, les sites en Pages Router et ceux qui tournent sur Edge Runtime, selon l'avis de Next.js.
• Un seul identifiant : une seconde référence, CVE-2025-66478, avait été ouverte pour Next.js. Elle a été rejetée par la base américaine des vulnérabilités (NVD) comme doublon : tout se suit sous CVE-2025-55182.
• Exploitée : inscrite au catalogue des failles activement exploitées de la CISA le 5 décembre 2025. En France, le CERT-FR a publié l'alerte CERTFR-2025-ALE-014, qui signale des exploitations et demande de considérer comme compromis tout serveur resté vulnérable et exposé sur Internet après le 5 décembre 2025.

#2. Les versions corrigées

Pour fermer l'exécution de code, chaque branche de Next.js a sa version minimale :

Les préversions 14.3.0-canary.77 et suivantes n'ont pas de correctif : il faut revenir à une version 14.x stable.

Côté React, les versions corrigées sont 19.0.1, 19.1.2 et 19.2.1. Si votre application utilise les React Server Components sans Next.js (avec un autre cadre applicatif), c'est la version de ces paquets qu'il faut contrôler.

Attention aux failles de suivi. En décembre 2025 et janvier 2026, quatre autres failles ont été publiées sur les mêmes composants : CVE-2025-55183 (fuite du code source), CVE-2025-55184, CVE-2025-67779 et CVE-2026-23864 (déni de service). Aucune ne permet d'exécuter du code, mais elles peuvent rendre votre site indisponible. Pour en être protégé, visez au moins 15.0.8, 15.1.12, 15.2.9, 15.3.9, 15.4.11, 15.5.10, 16.0.11 ou 16.1.5 selon votre branche, versions recommandées par l'équipe React.

#3. Comment savoir si je suis concerné

Vous ne savez pas si votre site est en Next.js ? Demandez-le à l'agence ou au développeur qui l'a réalisé. Notre scanner de vulnérabilité le reconnaît aussi tout seul.

Depuis l'extérieur. Next.js inscrit son numéro de version dans les fichiers JavaScript que tout navigateur télécharge. Le scanner lit ce numéro et repère si la page utilise l'App Router. S'il ne trouve pas la version, il répond « indéterminé » : cela ne veut pas dire que le site est à jour.

Dans le code du projet. La version se lit dans le fichier package.json, à la ligne next, et surtout dans le fichier de verrouillage (package-lock.json, pnpm-lock.yaml ou yarn.lock), qui donne la version réellement installée. La commande suivante l'affiche :

npm ls next react-server-dom-webpack

Hébergement. Le correctif ne s'applique pas tout seul : il faut mettre à jour la dépendance, reconstruire le site et le redéployer, que vous soyez sur une plateforme d'hébergement spécialisée, un serveur ou un conteneur.

#4. Que faire maintenant

1. Mettez à jour Next.js vers la version corrigée de votre branche (tableau ci-dessus), idéalement vers la version qui couvre aussi les failles de suivi.
2. Reconstruisez et redéployez l'application. Redémarrer l'ancienne version ne change rien.
3. Vérifiez que la version servie a changé, par exemple avec le scanner.
4. Changez les secrets de l'application (clés d'API, accès à la base de données, jetons des services tiers) si le site a été exposé après le 5 décembre 2025 : une exécution de code donne accès aux variables d'environnement du serveur.

#Chercher des signes de compromission

Comme le rappelle le CERT-FR, un serveur exposé pendant la période d'exploitation doit être traité comme compromis tant que l'inverse n'est pas démontré. Les signes à rechercher :

• des processus inconnus lancés par le processus Node.js, en particulier un shell ou un outil de téléchargement ;
• une charge processeur anormale, typique d'un mineur de cryptomonnaie ;
• des connexions sortantes vers des adresses que vous ne reconnaissez pas ;
• des fichiers récents dans le dossier de l'application ou dans /tmp ;
• des usages inhabituels de vos clés d'API ou de vos comptes de services cloud.

Un seul de ces signes justifie un diagnostic. L'absence de signe visible ne prouve rien.

#5. Questions fréquentes

#Mon site vitrine en Next.js est-il vraiment une cible ?

Oui. L'exploitation est automatisée : des robots balaient Internet à la recherche de sites Next.js vulnérables, sans regarder la taille de l'entreprise. Un site vitrine compromis sert ensuite à héberger du contenu frauduleux, à miner de la cryptomonnaie ou à attaquer d'autres systèmes.

#Mon site est un export statique de Next.js, suis-je concerné ?

Un site entièrement exporté en fichiers statiques n'exécute pas de code React côté serveur au moment de la visite. Il n'est donc pas exposé à cette faille. Vérifiez-le auprès de votre développeur : beaucoup de sites mélangent pages statiques et pages rendues par le serveur.

#Un pare-feu applicatif suffit-il ?

Il peut bloquer une partie des attaques connues, mais pas toutes les variantes. La mise à jour reste la seule protection complète.

#Faut-il tester la faille sur mon propre site ?

Non. Les codes d'exploitation qui circulent ne sont pas vérifiés et peuvent contenir eux-mêmes des logiciels malveillants. Contrôler la version suffit.

#6. Comment M-KIS peut vous aider

Si votre serveur a pu être compromis, notre intervention sur serveur infecté, dans le cadre de notre réponse à incident, prend en charge l'analyse, le nettoyage et la remise en service. Pour un site web piraté, notre offre de secours de site piraté propose un diagnostic gratuit.

Pour ne plus gérer ce type d'alerte dans l'urgence, notre développement sur mesure et notre infogérance incluent le suivi des mises à jour de sécurité des applications que nous maintenons. Pour toute question, écrivez-nous : nous répondons rapidement par mail.

Sources : avis de sécurité de React (react.dev) du 3 décembre 2025 et du 11 décembre 2025, avis de sécurité de Next.js (nextjs.org) du 3 décembre 2025, avis GitHub GHSA-9qr9-h5gf-34mp, base NVD, catalogue KEV de la CISA (ajout du 5 décembre 2025), alerte CERT-FR CERTFR-2025-ALE-014.