Alerte de sécurité : vulnérabilités RCE critiques dans React Server Components (CVE-2025-55182)

En bref

Le 3 décembre 2025, des divulgations coordonnées ont révélé que plusieurs versions de React 19 et Next.js présentent une faille critique dans le protocole « Flight » de React Server Components (RSC), permettant une exécution de code à distance (RCE) sans authentification. La vulnérabilité découle de la désérialisation non sécurisée de données contrôlées par un attaquant lors du traitement côté serveur des charges utiles RSC.
Une simple requête HTTP spécialement conçue suffit à l’exploiter. L’attaque fonctionne de manière fiable avec les configurations par défaut et touche non seulement React et Next.js, mais aussi tout framework ou bundler intégrant l’implémentation RSC.
Des correctifs sont disponibles et doivent être appliqués immédiatement. Les systèmes utilisant des versions non corrigées sont exposés à une compromission complète du serveur.

Mise à jour (5 déc. 2025) :

L’auteur du signalement initial de cette vulnérabilité, Lachlan Davidson, a publié ses PoC d’origine sur GitHub.

Présentation du composant concerné

React Server Components (RSC) et le protocole « Flight »

React 19 a introduit un mécanisme qui répartit le rendu de l’interface entre le client et le serveur. L’état des composants et les appels de fonctions côté serveur sont sérialisés dans un format de transport spécial, souvent appelé protocole « Flight ».

Les packages concernés comprennent :

• react-server-dom-webpack

• react-server-dom-parcel

• react-server-dom-turbopack

Ces packages désérialisent les charges utiles RSC entrantes pour acheminer les opérations côté serveur. La vulnérabilité vient du fait que la logique de désérialisation n’imposait pas suffisamment de contraintes structurelles ou de type, permettant à des charges utiles malveillantes de modifier le comportement de l’exécution.

Pourquoi la configuration par défaut était exposée

La plupart des frameworks qui adoptent RSC, notamment l’App Router de Next.js, activent cette logique par défaut. Ainsi, un projet Next.js standard créé avec create-next-app, puis compilé et déployé sans aucune modification du code… était exploitable avec les paramètres par défaut.

Chronologie des événements connus

Remarque : à la date de la divulgation, aucune exploitation dans la nature n’avait été confirmée publiquement. Toutefois, l’exploitation nécessite très peu de compétences.

Composants touchés

Versions de React concernées

• 19.0.0

• 19.1.0

• 19.1.1

• 19.2.0

Versions de Next.js concernées

• Toutes les versions stables 15.x

• Toutes les versions stables 16.x

• Versions expérimentales 14.3.0-canary.77 et ultérieures

Autres outils et frameworks probablement touchés car ils intègrent RSC :

• Plugin Vite RSC

• Plugin Parcel RSC

• Aperçu de React Router RSC

• RedwoodSDK

• Waku

• Tout package intégrant les modules vulnérables react-server-dom-*

Empreinte dans le cloud

Selon les estimations de recherche, environ 39 % des environnements cloud analysés exécutaient des charges de travail utilisant des versions vulnérables de React/Next.js RSC.

Déroulement de l’incident

Vulnérabilité sous-jacente : désérialisation non sécurisée

Au cœur du problème, le moteur RSC côté serveur accepte une charge utile « Flight » sérialisée décrivant :

• Les limites entre composants

• Les références aux fonctions côté serveur

• Les flux de données

Les implémentations vulnérables accordaient une confiance excessive à la structure des données entrantes. Lorsqu’elles recevaient des charges utiles malformées, mais syntaxiquement valides, le serveur :

1. Ne rejetait pas les formes d’objet ou les références inattendues

2. Traitait les identifiants fournis par l’attaquant

3. Exécutait des chemins JavaScript privilégiés qui n’étaient pas censés être accessibles depuis l’extérieur

Cela entraîne directement une exécution de code à distance avant l’authentification, d’où le score CVSS de 10,0 (critique).

Vecteur d’attaque

• À distance : aucun accès local ni identifiant requis

• Sans authentification : n’importe qui peut tenter l’exploitation

• Une seule requête : une requête HTTP spécialement conçue vers un point de terminaison RSC suffit

• Fiabilité élevée : les tests font état d’une fiabilité proche de 100 % avec les configurations par défaut

Pourquoi cette vulnérabilité est particulièrement dangereuse

• La plupart des applications Next.js utilisant App Router exposent publiquement des points de terminaison RSC.

• La RCE se produit avant toute logique de routage ou tout contrôle d’authentification.

• Dans les déploiements cloud ou sans serveur, les points de terminaison RSC se trouvent souvent à la racine des surfaces d’API.

Recommandations en matière de détection et d’analyse

Pour les scanners de code et de dépendances

Recherchez :

• "react-server-dom-webpack" versions 19.0.0, 19.1.0, 19.1.1 et 19.2.0

• "react-server-dom-parcel" versions 19.0.0, 19.1.0, 19.1.1 et 19.2.0

• "react-server-dom-turbopack" versions 19.0.0, 19.1.0, 19.1.1 et 19.2.0

• Les versions de Next.js répertoriées dans la section des versions concernées

Pour la surveillance à l’exécution et au niveau réseau

Signalez :

• Les requêtes vers les routes RSC contenant des trames Flight RSC malformées ou inattendues

• Les jetons à forte entropie ou anormaux dans les charges utiles RSC sérialisées

• Les hausses soudaines des erreurs d’appel de fonctions côté serveur

Pour les outils de posture cloud

Recherchez les charges de travail qui déploient :

• Des conteneurs créés avant le 3 décembre 2025

• Des images React 19 ou Next.js 15/16 qui n’ont pas encore été corrigées

• Des charges de travail accessibles depuis Internet utilisant App Router ou des actions côté serveur

Les applications hébergées sur Vercel bénéficient du filtrage des requêtes au niveau de la plateforme, mais doivent tout de même être mises à niveau.

Conseils pour atténuer les risques

1. Mettez à niveau immédiatement

React

• 19.0.0 → 19.0.1

• 19.1.x → 19.1.2

• 19.2.0 → 19.2.1

Next.js

Versions corrigées :

npm install next@15.0.5
npm install next@15.1.9
npm install next@15.2.6
npm install next@15.3.6
npm install next@15.4.8
npm install next@15.5.7
npm install next@16.0.7

• Utilisateurs de Canary → si vous utilisez la version 14.3.0-canary.77 ou une version ultérieure, revenez à une version stable :

npm install next@14

2. Recompilez les applications après la mise à niveau

Assurez-vous que les pipelines CI/CD recompilent les images Docker ou les bundles sans serveur avec le graphe de dépendances corrigé.

3. Vérifiez les frameworks tiers

Si vous utilisez Redwood, Waku, des aperçus expérimentaux de RSC ou des bundlers, vérifiez que :

• Une implémentation RSC mise à jour a été publiée

• Aucun fichier de verrouillage obsolète ne maintient des versions vulnérables

4. Activez des mesures de défense en profondeur

• Le sandboxing à l’exécution pour JavaScript côté serveur

• Un routage strict pour les points de terminaison RSC

• Des règles de pare-feu applicatif web (WAF) pour détecter les charges utiles RSC malformées

Prochaines étapes pour la communauté

Pour les responsables des écosystèmes dépendants

• Auditez toutes les extensions RSC personnalisées

• Publiez des avis mis à jour et des versions corrigées

• Envisagez de renforcer les schémas de désérialisation à l’aide d’une validation explicite

Pour les organisations

• Recensez toutes les charges de travail utilisant React Server Components

• Donnez la priorité aux applications exposées à Internet

• Surveillez toute activité suspecte avant le déploiement du correctif

• Effectuez des analyses forensiques après l’application du correctif afin de vérifier qu’aucune exploitation n’a eu lieu

Conclusion

Cet incident met en lumière un défi systémique des écosystèmes JavaScript modernes : des mécanismes de sérialisation très dynamiques peuvent devenir de puissants vecteurs de RCE lorsqu’ils ne sont pas suffisamment validés. Comme React Server Components s’impose rapidement dans de nombreux frameworks, la portée de cette vulnérabilité est exceptionnellement vaste.

Le correctif est simple à appliquer, mais tout retard accroît considérablement les risques. Les organisations doivent effectuer la mise à niveau dès maintenant, vérifier leurs frameworks dépendants et continuer à suivre les mises à jour au fil des enquêtes menées dans l’écosystème.

N’attendez pas pour appliquer le correctif. Consultez dès maintenant les avis de sécurité Snyk pour confirmer les versions concernées et obtenir les instructions complètes de correction :

• https://security.snyk.io/vuln/SNYK-JS-REACTSERVERDOMWEBPACK-14173285

• https://security.snyk.io/vuln/SNYK-JS-REACTSERVERDOMTURBOPACK-14173287

• https://security.snyk.io/vuln/SNYK-JS-REACTSERVERDOMPARCEL-14173286

• https://security.snyk.io/vuln/SNYK-JS-NEXT-14173355