Divulgation de vulnérabilités de DoS et d’exposition du code source dans React Server Components

• De nouvelles vulnérabilités de déni de service (DoS) et d’exposition du code source ont été découvertes et rendues publiques dans React Server Components
• Ces vulnérabilités ne permettent pas d’exécution de code à distance (RCE), mais elles peuvent entraîner un arrêt du serveur ou une fuite de code
• Les packages concernés sont react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack, en versions 19.0.0~19.2.2, et les versions corrigées sont 19.0.3, 19.1.4, 19.2.3
• La vulnérabilité DoS (CVE-2025-55184, CVE-2025-67779) peut provoquer une boucle infinie via une requête HTTP malveillante, et la vulnérabilité d’exposition du code source (CVE-2025-55183) peut renvoyer une partie du code d’une fonction serveur
• L’équipe React recommande une mise à niveau immédiate et explique que cette divulgation supplémentaire correspond à un processus normal du cycle de réponse sécurité

---

Aperçu des vulnérabilités nouvellement divulguées

• Les chercheurs en sécurité ont découvert deux vulnérabilités supplémentaires pendant la validation du correctif de la vulnérabilité critique publiée la semaine dernière
• Les nouvelles vulnérabilités ne permettent pas l’exécution de code à distance (RCE), et le patch React2Shell reste valable
• Les vulnérabilités nouvellement divulguées sont les suivantes
  • Déni de service (DoS) — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, gravité élevée)
  • Divulgation de code source — CVE-2025-55183 (CVSS 5.3, gravité moyenne)
• L’équipe React recommande une mise à niveau immédiate

Incomplétude du correctif précédent

• Les correctifs déployés la semaine dernière dans les versions 19.0.2, 19.1.3, 19.2.2 étaient incomplets, ce qui nécessite une mise à jour supplémentaire
• La correction complète est incluse dans les versions 19.0.3, 19.1.4, 19.2.3
• Il faut suivre les instructions de mise à jour du message précédent
• Des informations supplémentaires seront publiées une fois le déploiement du correctif terminé

Packages et versions affectés

• Les vulnérabilités sont présentes dans les mêmes packages et versions que CVE-2025-55182
• Versions affectées : 19.0.0~19.2.2
• Packages affectés :
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• Versions corrigées : 19.0.3, 19.1.4, 19.2.3
• Les applications qui n’utilisent pas de serveur ou ne prennent pas en charge React Server Components ne sont pas touchées

Schéma classique des divulgations de vulnérabilités ultérieures

• Après la divulgation d’une CVE critique, une analyse supplémentaire des chemins de code associés révèle souvent d’autres vulnérabilités
• Des exemples de CVE supplémentaires signalés après Log4Shell sont mentionnés
• Ce type de divulgation supplémentaire signifie que la réponse de sécurité fonctionne normalement

Frameworks et bundlers affectés

• Les frameworks et bundlers suivants incluent ou dépendent du package React vulnérable :
  • next
  • react-router
  • waku
  • @parcel/rsc
  • @vitejs/plugin-rsc
  • rwsdk
• Il faut suivre les instructions de mise à jour du message précédent

Mesures temporaires des hébergeurs

• Plusieurs fournisseurs d’hébergement et équipes associées ont mis en place des mesures de mitigation temporaires
• Néanmoins, il ne faut pas se reposer sur ces mesures et une mise à jour immédiate est nécessaire

Consignes liées à React Native

• Les utilisateurs de React Native seul n’ont pas besoin de mesures supplémentaires
• En environnement monorepo, seuls les packages suivants doivent être mis à jour :
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• Les packages react et react-dom n’ont pas besoin d’être mis à jour
• Les détails associés sont référencés dans l’issue React Native sur GitHub

Haute gravité : déni de service (DoS)

• CVE-2025-55184, CVE-2025-67779, CVSS 7.5
• Si une requête HTTP malveillante est envoyée vers le point de terminaison d’une fonction serveur React, une boucle infinie peut se produire lors de la désérialisation
• Le processus serveur peut être arrêté et monopoliser excessivement le CPU
• Même sans implémenter directement un point de terminaison de fonction serveur, une application prenant en charge React Server Components peut être vulnérable
• Le patch publié aujourd’hui corrige ce problème en empêchant les boucles infinies
• La correction initiale était incomplète, puis la vulnérabilité additionnelle CVE-2025-67779 est venue la combler

Gravité moyenne : exposition du code source

• CVE-2025-55183, CVSS 5.3
• Une requête HTTP malveillante peut renvoyer une partie du code source d’une fonction serveur
• Cela peut se produire quand des arguments de type chaîne sont explicitement ou implicitement exposés par la fonction serveur
• Dans le code d’exemple, des valeurs secrètes codées en dur telles que des clés de connexion de base de données peuvent être exposées
• Le patch corrige cela en empêchant la transformation en chaîne du code source de la fonction serveur
• L’exposition est limitée au code interne de la fonction serveur, et les secrets d’exécution (process.env.SECRET, etc.) ne sont pas impactés
• La validation doit être vérifiée sur la base du bundle de production

Chronologie

• 3 décembre : Andrew MacPherson signale une fuite de code source à Vercel et au programme Meta Bug Bounty
• 4 décembre : RyotaK signale une vulnérabilité DoS
• 6 décembre : L’équipe React constate les deux problèmes et lance l’enquête
• 7 décembre : Rédaction du patch initial et élaboration du plan de validation
• 8 décembre : Notification aux hébergeurs et aux projets open source
• 10 décembre : Mise en place des mesures de mitigation et validation du patch achevée
• 11 décembre : Shinsaku Nomura signale un DoS supplémentaire, publication des CVE-2025-55183, 55184 et 67779

Signalements

• Andrew MacPherson (AndrewMohawk) — signalement de l’exposition de code source
• RyotaK (GMO Flatt Security Inc) et Shinsaku Nomura (Bitforest Co., Ltd.) — signalements de vulnérabilités de déni de service

[GN⁺]

Avis sur Hacker News

• Les React Server Components (RSC) m’ont toujours semblé inconfortables
  Parce qu’en regardant uniquement le code JavaScript, il est difficile de distinguer ce qui s’exécute côté client de ce qui s’exécute côté serveur
  En plus, leur mise en œuvre nécessite un mécanisme RPC de sérialisation profond, opaque pour les développeurs, ce qui augmente le risque de failles de sécurité

  • À l’époque du pages router de NextJS, la frontière entre code serveur et code client était claire, et c’était appréciable
    Mais avec le passage à l’app router, c’est devenu confus. Comme le code peut s’exécuter des deux côtés, des objets comme Headers ne sont pas toujours présents, et il devient difficile de savoir quoi s’exécute où
  • En rejoignant une nouvelle équipe qui utilisait Next, j’ai demandé : « Quelqu’un sait comment ça fonctionne ? », et personne n’a vraiment su l’expliquer clairement
    Quand React+Next fonctionne bien, cela ressemble à de la magie, mais lorsqu’on travaille en équipe, le problème est que la prévisibilité disparaît progressivement
  • C’est pour ça que je suis fan de Inertia.js. Inertia.js relie naturellement des backends MVC traditionnels comme Laravel, Rails ou Django avec des outils frontend comme React, Vue ou Svelte
    Les rôles y sont clairs, le travail est simple, et je pense que c’est le choix le plus sûr pour la plupart des projets
  • On a l’impression que les RSC et le SSR ont été adoptés à l’excès
    Pour une landing page ou une page marketing, le SSR est utile, mais pour une application comme un tableau de bord SaaS classique, le gain est presque nul par rapport à la complexité ajoutée
  • Je me demande à quel point d’autres frameworks (Angular, SvelteKit, Nuxt) sont exposés à ce genre de faille
    Est-ce que React attire simplement plus l’attention parce qu’il est populaire, ou bien est-il structurellement plus risqué ?

• J’ai regardé les RSC la semaine dernière, et la complexité était énorme, avec presque pas de documentation
  React dit qu’il s’agit encore d’une fonctionnalité expérimentale, mais NextJS l’a déjà largement déployée
  On dirait qu’il y aura encore d’autres problèmes de sécurité, et le système de build de Next était tellement complexe qu’il était difficile à déboguer
  Le coût est bien trop élevé pour les bénéfices obtenus

  • Depuis longtemps, certains reprochent à Next d’emballer des « fonctionnalités React pas encore prêtes pour la production » comme s’il s’agissait des dernières nouveautés
    C’est aussi pour ça que j’ai quitté Next. La charge cognitive était trop forte pour trop peu de gains
  • React a depuis longtemps un problème de documentation insuffisante
    Pas seulement pour les RSC : de manière générale, les guides clairs sont arrivés tard, et même des outils comme CRA n’ont pas vraiment été reconnus officiellement
    La documentation de useEffect ne s’est améliorée que récemment, mais bien trop tard
    Même en 2025, alors qu’on l’utilise toujours en production, il manque encore une documentation claire

• Le principe central des SPA, c’était « envoyer toute l’application côté client et n’échanger avec le serveur que des données »

  • Pourtant, dans l’écosystème C#, c’est Blazor Server qui a le vent en poupe
    Comme avec les anciens .aspx Web Forms, chaque clic et chaque saisie sont envoyés au serveur, puis le DOM modifié est renvoyé
    On a en quelque sorte fait marche arrière, ce qui est assez absurde
  • Au final, beaucoup de développeurs ont redécouvert les raisons d’être du server-side rendering et sont revenus à des frameworks full stack comme PHP, Rails ou Spring
  • Mais aujourd’hui, il devient courant de créer des sites statiques avec des bibliothèques comme React, ce qui est plus lent et plus complexe qu’une simple combinaison moteur de templates + JS
    C’est dommage d’avoir perdu le sens du « bon outil pour le bon usage »
  • Bien sûr, les RSC ne sont pas conçus pour des SPA pures. C’est une approche qui poursuit d’autres objectifs

• Dans cette annonce de sécurité, la phrase qui a le plus retenu mon attention était : « lorsqu’un CVE critique est découvert, des vulnérabilités de suivi apparaissent souvent »
  Avant même d’expliquer l’étendue du problème, son impact ou les moyens d’atténuation, cela donnait l’impression de vouloir justifier le CVE, ce qui était inquiétant

  • Mais pour certains, ce n’était pas une justification : simplement une explication sur le point que les gens allaient naturellement vouloir comprendre en premier
  • Ils disent avoir modifié la formulation à la suite des retours → lien vers la PR corrigée
  • Quelqu’un a décrit cela comme de la gestion de la perception (perception management)
    Article Wikipédia associé
  • Certains estiment aussi qu’il existe dans cette affaire des intérêts de carrière imbriqués
  • D’autres disent : « On dirait un texte écrit par l’équipe marketing de Vercel »

• Il y a 15 ans, Opa tentait déjà quelque chose de similaire
  Le projet séparait automatiquement le code client et serveur, et introduisait une syntaxe proche de JSX
  Mais en renforçant l’analyse de sécurité, le compilateur est devenu énorme, et on a fini par comprendre que la séparation claire était plus importante que le concept d’application unifiée
  Peut-être qu’un jour les LLM généreront ce genre de code automatiquement, mais pour l’instant, une structure simple me paraît préférable

  • En réalité, la faille des RSC vient moins du découpage du code que de la nature dynamique du processus de sérialisation/désérialisation
    Des correctifs sont en cours pour empêcher des problèmes comme la pollution de prototype en JS, toString sur les fonctions ou la surcharge de Promise
    Les RSC distinguent les environnements via une vérification statique comme import "server-only" ou import "client-only", donc l’approche est structurellement sûre
  • Il existe un projet à l’idée similaire, Electric Clojure → lien
  • À noter que Ocsigen Eliom avait tenté ce concept avant Opa

• React était mieux à l’origine, quand il restait petit et simple dans son rôle de View du MVC
  Aujourd’hui, il embarque trop de fonctionnalités et donne une impression de surpoids

  • Mais les RSC sont une bibliothèque séparée, ils ne font pas partie de l’installation de base de React
  • Pour revenir à une ancienne version, il suffit de faire git checkout v15.0.0

• Les RSC n’auraient jamais dû exister au départ
  Pour la plupart des applications, rendre du HTML côté serveur suffit largement, et les cas où un SPA est nécessaire sont très rares
  Les RSC n’ont fait qu’ajouter de la complexité et des failles de sécurité

  • D’accord. Mais l’écosystème poussé par les bootcamps et les financements VC continue à aller dans cette direction
    Des projets comme Bun et Vercel vendent l’illusion d’une utopie JavaScript où tout fonctionne parfaitement, donc cette tendance ne risque pas de disparaître facilement

• J’avais déjà débattu des RSC avec Dan Abramov sur X
  Lui parlait d’une fonctionnalité innovante, mais moi j’avais dit que c’était un pistolet braqué sur son propre pied. Et au final, la réalité semble m’avoir donné raison

  • Personnellement, j’ai déjà construit une application avec les RSC, et j’apprécie toujours cette approche
    En revanche, le risque de bugs au niveau du protocole a été sous-estimé. Cette vulnérabilité se concentre sur le protocole de sérialisation
    La communauté sécurité ne commence à regarder cela en profondeur que maintenant, et il aurait sans doute fallu que l’équipe réagisse plus tôt
  • Les systèmes qui réussissent finissent souvent par devenir des monstres à force de sur-extension
    React aussi est passé d’une simple bibliothèque de rendu à un runtime, avec une explosion de la complexité
  • Personnellement, je ne trouve pas l’approche de Dan particulièrement brillante
    À l’inverse, Vue et Vite me paraissent bien plus élégants dans leur conception → site personnel d’Evan You
  • Bien sûr, la plupart des idées finissent par échouer, donc il faut aussi se méfier d’une posture purement critique
    Parfois, des tentatives audacieuses finissent par être de vrais coups de génie
  • Quelqu’un a aussi laissé un commentaire d’encouragement : « Peut-être que c’est vous qui êtes meilleur »

• Si les RSC sont une tentative du frontend de dévorer le backend, alors HTMX représente l’inverse
  HTMX maintient la frontière client–serveur, ce qui protège le backend, mais expose le frontend à un risque de XSS

  • Mais HTMX a déjà résolu le problème de XSS grâce à l’auto-escaping des moteurs de templates
    Article associé

• L’équipe Next a annoncé une nouvelle mise à jour de sécurité → NextJS Security Update 2025-12-11
  Les versions 14.x, 15.x et 16.x sont concernées