Next.jsReactSécuritéCVEReact2ShellVulnerabilité

React2Shell : Guide Complet des CVE Critiques Next.js & React (Déc. 2025)

Analyse technique et guide de correction pour les failles critiques React2Shell (RCE), DoS et fuite de code source affectant l'App Router de Next.js.

27 décembre 2025
Kody
React2Shell : Guide Complet des CVE Critiques Next.js & React (Déc. 2025)

React2Shell : Autopsie des CVE Critiques Next.js

Le réveil brutal de l'écosystème React

Le 3 décembre 2025, une onde de choc traverse la communauté JavaScript. Lachlan Davidson, chercheur en sécurité, publie ce qui deviendra l'une des failles les plus dévastatrices de l'histoire des frameworks web modernes : React2Shell.

En quelques heures, la nouvelle se répand. Des millions d'applications Next.js — des startups aux entreprises du Fortune 500 — découvrent qu'elles exposent leurs serveurs à une exécution de code arbitraire. Sans authentification. Avec une fiabilité quasi parfaite.

Le score CVSS ? 10.0 sur 10. Le maximum.

Mais ce n'est que le début. Trois jours plus tard, deux nouvelles vulnérabilités émergent. Puis une quatrième, révélant que le premier correctif était incomplet.

Cet article retrace la chronologie de ces failles, décortique leurs mécanismes techniques, et vous guide pas à pas vers une remédiation complète.


Anatomie d'une catastrophe : l'exploit RCE

CVE-2025-55182 (React) / CVE-2025-66478 (Next.js)

Les faits

AttributValeur
SévéritéCritique (CVSS 10.0)
TypeExécution de code à distance
Divulgation3 décembre 2025
DécouvreurLachlan Davidson

Comment une requête HTTP prend le contrôle

Tout commence dans le protocole Flight, le mécanisme de sérialisation des React Server Components. Lorsqu'un serveur reçoit une requête, le package react-server désérialise les données entrantes pour reconstruire l'arbre de composants.

Le problème : cette désérialisation fait aveuglément confiance aux données reçues.

Un attaquant peut forger un payload RSC malveillant, l'envoyer via une simple requête POST, et exploiter la résolution de Chunk.prototype.then lors de la désérialisation d'un Blob. Le résultat ? Le contrôle total du flux d'exécution côté serveur.

Concrètement, cela signifie :

  • Exécution de code JavaScript arbitraire avec les privilèges du processus Node.js
  • Vol de credentials cloud (AWS, Azure, GCP)
  • Installation de cryptomineurs — XMRig a été observé dans la nature
  • Déploiement de backdoors et d'outils d'accès distant
  • Compromission complète de l'infrastructure

Les chiffres donnent le vertige : 39% des environnements cloud hébergent des instances vulnérables. Plus de 968 000 serveurs potentiellement exposés.

Périmètre d'impact

React :

  • Versions 19.0, 19.1.0, 19.1.1, 19.2.0
  • Packages : react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack

Next.js :

  • Toutes les versions 15.x
  • Toutes les versions 16.0.x
  • Version 14.3.0-canary.77 et ultérieures

Autres frameworks touchés :

Correction immédiate

Option 1 : L'outil automatique (recommandé)

npx fix-react2shell-next

Cet utilitaire officiel de Vercel détecte votre version, met à jour les dépendances concernées, et gère les monorepos.

Option 2 : Mise à jour manuelle

# Next.js 16.x
npm install next@16.0.7

# Next.js 15.5.x
npm install next@15.5.7

# Next.js 15.4.x
npm install next@15.4.8

# Next.js 15.3.x
npm install next@15.3.6

# Next.js 15.2.x
npm install next@15.2.6

# Next.js 15.1.x
npm install next@15.1.9

# Next.js 15.0.x
npm install next@15.0.5

# React 19.x
npm install react@19.0.1 react-dom@19.0.1  # Pour 19.0.x
npm install react@19.1.2 react-dom@19.1.2  # Pour 19.1.x
npm install react@19.2.1 react-dom@19.2.1  # Pour 19.2.x

Option 3 : Pour les versions 13.x et 14.x

npm install next@14.2.35

Si vous étiez exposé

Votre application tournait sans patch entre le 4 et le 6 décembre 2025 ? Considérez-la comme potentiellement compromise.

Rotation immédiate des secrets :

  • Clés API
  • Tokens d'accès
  • Credentials de bases de données
  • Certificats SSL/TLS
  • Secrets d'applications

Audit des logs :

  • Requêtes POST suspectes vers les endpoints RSC
  • Commandes Base64 encodées
  • Téléchargements de scripts (wget, curl)
  • Connexions reverse shell
  • Pics d'activité CPU inexpliqués

Quand le serveur tourne dans le vide : l'attaque DoS

CVE-2025-55184 / CVE-2025-67779

Les faits

AttributValeur
SévéritéHaute (CVSS 7.5)
TypeDéni de service
Divulgation11 décembre 2025
ParticularitéCVE-2025-67779 corrige un patch incomplet

Le mécanisme de la boucle infinie

Une semaine après React2Shell, une nouvelle menace émerge. Cette fois, l'attaquant ne cherche pas à prendre le contrôle — il veut simplement faire tomber le service.

Une requête HTTP soigneusement construite, envoyée à n'importe quel endpoint App Router, déclenche une boucle infinie dans la logique de désérialisation du protocole Flight. Le processus serveur se fige. Un cœur CPU grimpe à 100%. Plus aucune requête légitime ne passe.

Sur les plateformes serverless comme Netlify, les timeouts limitent les dégâts à 30-40 secondes par fonction. Mais rien n'empêche l'attaquant de répéter l'opération.

Le premier correctif (CVE-2025-55184) s'est révélé incomplet. CVE-2025-67779 est arrivé quelques jours plus tard pour colmater définitivement la brèche.

Conséquences

  • Indisponibilité totale du service
  • Épuisement des ressources CPU
  • Explosion des coûts cloud (particulièrement en serverless)
  • Perte de revenus
  • Dégradation de l'expérience utilisateur

Versions concernées

Next.js :

  • 13.3.1-canary.0 à 14.2.34
  • 15.0.6 à 15.0.6
  • 15.1.10 à 15.1.10
  • 15.2.7 à 15.2.7
  • 15.3.7 à 15.3.7
  • 15.4.9 à 15.4.9
  • 15.5.8 à 15.5.8
  • 16.0.9 à 16.0.9
  • Certaines versions canary

React :

  • 19.0.1, 19.1.3, 19.2.2 (versions avec le patch incomplet)

Patch définitif

Attention : si vous avez déjà corrigé CVE-2025-55184, vous devez patcher à nouveau.

# Next.js 14.x
npm install next@14.2.35

# Next.js 15.0.x
npm install next@15.0.7

# Next.js 15.1.x
npm install next@15.1.11

# Next.js 15.2.x
npm install next@15.2.8

# Next.js 15.3.x
npm install next@15.3.8

# Next.js 15.4.x
npm install next@15.4.10

# Next.js 15.5.x
npm install next@15.5.9

# Next.js 16.0.x
npm install next@16.0.10

# React 19.x (correctif complet)
npm install react@19.0.3 react-dom@19.0.3  # Pour 19.0.x
npm install react@19.1.4 react-dom@19.1.4  # Pour 19.1.x
npm install react@19.2.3 react-dom@19.2.3  # Pour 19.2.x

Vos secrets en vitrine : la fuite de code source

CVE-2025-55183

Les faits

AttributValeur
SévéritéMoyenne (CVSS 5.3)
TypeDivulgation d'informations
Divulgation11 décembre 2025

Le problème

Une requête malveillante peut forcer une Server Function à retourner le code source compilé d'autres Server Functions. La validation insuffisante des arguments lors de l'invocation des Server Actions ouvre une fenêtre sur votre logique métier.

Ce que vous risquez

  • Exposition de la logique métier propriétaire
  • Révélation de secrets hardcodés (si vous en aviez)
  • Reconnaissance facilitée pour d'autres attaques
  • Violation de propriété intellectuelle

L'impact reste limité si vous suivez les bonnes pratiques — notamment l'utilisation exclusive de variables d'environnement pour les secrets.

Applications vulnérables

Toutes les apps Next.js utilisant l'App Router avec des Server Actions :

  • Next.js 13.4+ (avec experimental.serverActions activé)
  • Next.js 14.x (avant 14.2.35)
  • Next.js 15.x et 16.x (avant les versions patchées)

Remédiation

Appliquez les mêmes versions que pour CVE-2025-55184/67779.

Nettoyage du code

Traquer les secrets exposés :

grep -r "api_key\|password\|secret\|token" src/

Migrer vers les variables d'environnement :

// Mauvaise pratique
async function serverAction() {
  const apiKey = "sk_live_1234567890";
  // ...
}

// Bonne pratique
async function serverAction() {
  const apiKey = process.env.API_KEY;
  // ...
}

Si des secrets étaient hardcodés dans du code potentiellement exposé : rotation immédiate.


Protocole de remédiation complet

Étape 1 — Évaluation

# État actuel des dépendances
npm list next react react-dom

# Ou via package.json
cat package.json | grep -E "next|react"

Étape 2 — Sauvegarde

cp package.json package.json.backup
cp package-lock.json package-lock.json.backup

Étape 3 — Application des correctifs

Méthode automatique :

npx fix-react2shell-next

# Pour les monorepos
cd packages/your-app
npx fix-react2shell-next

Méthode manuelle :

# Mise à jour des dépendances
npm install next@latest react@latest react-dom@latest

# Types TypeScript
npm install --save-dev @types/react@latest @types/react-dom@latest

# Nettoyage complet
rm -rf node_modules package-lock.json
npm install

# Vérification
npm list next react react-dom

Étape 4 — Validation

# Build de test
npm run build

# Tests automatisés
npm run test

# Test manuel en développement
npm run dev

Étape 5 — Déploiement

Vercel :

git add package.json package-lock.json
git commit -m "fix: patch CVE-2025-55182, CVE-2025-55184, CVE-2025-67779, CVE-2025-55183"
git push

Autres plateformes :

npm run build
# Déployer selon votre pipeline habituel

Étape 6 — Vérification post-déploiement

curl -I https://votre-app.com
# Surveiller les logs pour détecter des erreurs

Défense en profondeur : au-delà du patch

Protection WAF temporaire

Plusieurs fournisseurs ont déployé des règles de blocage :

Cloudflare — Protection automatique sur tous les plans, gratuit inclus.

Akamai App & API Protector — Règles 3000977 (CVE-2025-55183) et 3000978 (CVE-2025-55184).

Google Cloud Armor — Règle cve-canary disponible.

AWS WAF — Règles déployées.

Vercel / Netlify — Protection automatique. Le patch reste obligatoire.

Le WAF ne suffit pas

Les règles WAF constituent une défense temporaire. Elles peuvent être contournées par des variants d'exploit. Seul le patch du code source garantit une protection durable.

Mesures complémentaires

Rate limiting (exemple Nginx) :

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /_next/data/ {
    limit_req zone=api burst=20;
}

Monitoring :

# Requêtes POST suspectes
grep "POST.*/_next" /var/log/nginx/access.log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head

# Alertes CPU
top -b -n 1 | grep "node" | awk '{if($9>80) print "High CPU: "$9"%"}'

Segmentation réseau :

  • Isolation des serveurs Next.js dans des VPCs privés
  • API Gateways avec authentification
  • Restriction par IP si applicable

Détection d'exploitation :

# Patterns suspects
grep -E "multipart.*boundary|Content-Type.*text/plain" access.log

# Commandes Base64
grep -E "curl|wget|bash|sh" access.log | grep -i base64

Checklist de sécurité

Dans les 24 heures

  • Vérifier les versions Next.js et React
  • Appliquer les patches
  • Rebuild et redéployer
  • Tester les Server Components
  • Activer les règles WAF

Dans les 72 heures

  • Auditer les logs (période 4-6 décembre)
  • Rotation des secrets si exposition
  • Tests de tous les endpoints critiques
  • Vérification des autres dépendances
  • Documentation des changements

À long terme

  • Veille CVE pour React/Next.js
  • Processus de patching rapide (< 48h pour les critiques)
  • Tests de sécurité automatisés en CI/CD
  • Formation équipe sur la sécurité RSC
  • Élimination des secrets hardcodés
  • Alertes de sécurité automatisées

Outils et ressources

Scanners

Cyber ARScanner gratuit pour les trois CVE principales.

Aikido Security — Tracking automatique, intégration GitHub/GitLab, tier gratuit disponible.

Script multi-repos :

curl -O https://raw.githubusercontent.com/williavs/nextjs-security-update/main/nextjs-security-update.sh
chmod +x nextjs-security-update.sh
./nextjs-security-update.sh

Documentation officielle

Analyses techniques


Questions fréquentes

Mon app utilise Pages Router. Suis-je concerné ?

Non. Seules les applications App Router avec React Server Components sont vulnérables. Une mise à jour reste recommandée par précaution.

Puis-je désactiver les Server Components ?

Non. Aucune option de configuration ne permet de désactiver le code vulnérable sans casser l'App Router. Le patch est la seule solution.

Le WAF suffit-il ?

Non. C'est une mesure temporaire. Le patch du code source est indispensable.

J'ai déjà patché la semaine dernière. Dois-je recommencer ?

Oui. Les CVE-2025-55184/67779 et CVE-2025-55183 nécessitent des patches supplémentaires.

Comment savoir si j'ai été compromis ?

Auditez vos logs entre le 4 et 6 décembre. Cherchez : requêtes POST suspectes vers endpoints RSC, téléchargements de scripts, activité CPU anormale, connexions réseau inhabituelles.

Dois-je faire une rotation de tous mes secrets ?

Uniquement si votre app était exposée non patchée entre le 4 et 6 décembre, ou si vous aviez des secrets hardcodés (CVE-2025-55183).

Next.js 13 est-il patché ?

Next.js 13.0-13.2 n'est pas affecté. À partir de 13.3, vous devez migrer vers 14.2.35 — la v13 n'est plus supportée.


Ce qu'il faut retenir

Ces vulnérabilités — CVE-2025-55182/66478, CVE-2025-55184/67779, CVE-2025-55183 — comptent parmi les plus critiques jamais découvertes dans l'écosystème React/Next.js.

L'exploitation active a été observée. Les impacts potentiels sont catastrophiques : exécution de code arbitraire, déni de service, exposition de code source.

L'action immédiate est non négociable.

Priorités

  1. Patcher avec npx fix-react2shell-next
  2. Redéployer sous 24 heures
  3. Auditer les logs
  4. Rotation des secrets si nécessaire
  5. Surveillance continue

Enseignements

Ces failles rappellent des vérités fondamentales :

  • La veille de sécurité n'est pas optionnelle
  • Les processus de patching doivent être rapides
  • Les secrets n'ont rien à faire dans le code
  • La défense en profondeur reste pertinente
  • Les dépendances doivent être auditées régulièrement

La réactivité des équipes React, Next.js et de la communauté a limité les dégâts. Mais la prochaine vulnérabilité critique arrivera. Serez-vous prêt ?

La sécurité est un processus continu, pas une destination.

Vous avez aimé cet article ?