Le serveur de React est incroyablement fragile.

La trêve précaire de React avec la sécurité côté serveur a soudainement explosé. Quelques jours après un bug critique de Remote Code Execution (RCE) dans les composants serveur de React, deux autres failles à fort impact sont apparues : une défaillance totale de Denial of Service (DoS) et une fuite de code source des actions serveur. Les deux ont touché exactement la même zone expérimentale : la nouvelle architecture côté serveur de React et le protocole React Flight.

Ce ne sont pas des exploits ésotériques de type fourchette-chaîne-quatre-bugs. Une seule requête HTTP POST non authentifiée peut paralyser votre application ou renvoyer le code d'action du serveur au client. La démonstration "React a été piraté, encore une fois" de Better Stack montre une application Next.js 16.0.8 standard, sans aucune action serveur personnalisée, mise hors ligne par une seule requête conçue.

La vulnérabilité DoS exploite la façon dont React Flight désérialise les données fragmentées. En connectant le fragment 0 → fragment 1 et le fragment 1 → fragment 0, le serveur tombe dans une boucle de résolution infinie, utilise intensivement le processeur, et cesse de servir même les requêtes GET de base. Les CVE-2025-55184 et CVE-2025-67779 obtiennent un score de 7.5 (Élevé) et affectent le même mécanisme RSC qui a été intégré dans React 19.0.0–19.2.0.

Juste derrière, la CVE-2025-55183 expose le code source des actions serveur avec un autre POST trivial. En trompant le désérialiseur pour qu'il transmette une référence de fonction serveur en tant que propre argument, React finit par convertir la fonction en chaîne de caractères et retourne son implémentation dans la réponse HTTP. La note CVSS de 5,3 sous-estime le risque si ce code incorpore de la logique métier ou des secrets mal gérés.

Le plus alarmant : le précédent correctif RCE du 3 décembre n'a aucun effet contre ces deux bugs. Si vous vous êtes arrêté à « React a encore été piraté » et que vous n'avez appliqué que ce correctif, votre application reste vulnérable à une attaque par déni de service à un paquet et à une exposition de code. Le propre article de l'équipe React sur le blog de React le dit clairement : Mettez à jour immédiatement.

L'examen autour de l'ère serveur de React est maintenant intense. Les composants serveur React, les actions serveur et le protocole React Flight promettent une expérience développeur radicalement meilleure, mais trois CVE en moins de deux semaines soulèvent des questions difficiles. Les bibliothèques et frameworks construits sur cette pile—Next.js, React Router, Waku, Redwood, plugins RSC personnalisés—doivent considérer cela comme des incidents au niveau de l'écosystème, et non comme des bugs isolés.

Une requête HTTP malformée peut étouffer silencieusement un serveur React. Des chercheurs en sécurité ont révélé une faille de DoS à haute sévérité (CVSS 7.5) dans les Composants Serveur React, permettant à n'importe quel client non authentifié de suspendre un processus indéfiniment. Sous charge, quelques-unes de ces requêtes peuvent saturer les cœurs de processeur à 100% et rendre un déploiement entier non réactif.

Au cœur du bug se trouve le protocole React Flight, le format de transmission que React utilise pour diffuser des arbres de composants et des actions serveur sous forme de « morceaux ». Chaque morceau peut référencer un autre morceau en utilisant une notation avec le signe dollar comme `"$1"`, qui indique au désérialiseur de « récupérer le morceau 1 et de continuer à résoudre jusqu'à obtenir une valeur finale ». Sur un serveur en bonne santé, cette chaîne aboutit finalement à un objet concret ou à une valeur primitive.

Les attaquants envoient plutôt un corps POST qui ne se résout jamais. En créant un graphe cyclique — le segment `0` pointe vers le segment `1`, et le segment `1` pointe directement vers le segment `0` — ils exploitent la confiance du désérialiseur dans ces références. Aucun outil exotique n'est nécessaire : un seul POST avec des données JSON hostiles ou multipart visant un point de terminaison de Server Functions peut déclencher la boucle.

L'implémentation de Flight de React parcourt les références de fragment de manière récursive, suivant chaque pointeur `"$n"` jusqu'à atteindre une valeur terminale. Les versions vulnérables n'effectuent jamais de détection de cycles robuste, de sorte que le résolveur continue de poursuivre les mêmes deux fragments indéfiniment. Cette boucle infinie se produit à l'intérieur du gestionnaire de requêtes, donc la boucle d'événements Node.js ou le thread d'exécution équivalent ne revient jamais pour servir d'autres clients.

Sur une application de démonstration Next.js 16.0.8, Better Stack montre l'impact en temps réel. Un POST élaboré provoque un blocage de la connexion initiale pendant plus de 20 secondes, puis chaque requête GET subséquente vers `/` expire. De l'extérieur, le site semble "hors ligne", mais le conteneur ou la VM continue de signaler qu'il est "en cours d'exécution" tandis que son CPU tourne sur une seule requête altérée.

Le rayon d'explosion est plus vaste qu'il n'y paraît. L'avis de React mentionne react-server-dom-webpack et ses semblables (Parcel, Turbopack) dans les versions 19.0.0–19.2.0, qui soutiennent Next.js 15.x et 16.x, la prise en charge des RSC par React Router, Waku, le SDK de Redwood et divers plugins de bundler. Toute application qui prend en charge les composants serveur React hérite du désérialiseur vulnérable.

Le plus alarmant : vous n'avez pas besoin d'opter pour des actions serveur sophistiquées pour être exposé. Better Stack démontre le DoS contre un projet `create-next-app` standard sans aucune action personnalisée ou logique métier. Si le runtime expose un point de terminaison des Server Functions, un POST malveillant peut transformer cette installation par défaut en un bouton de self-DoS.

Le deuxième nouveau bug de React est plus silencieux qu'un serveur planté, mais tout aussi perturbant : un POST astucieusement conçu peut faire en sorte que votre backend cite littéralement son propre code source en retour à l'attaquant. CVE-2025-55183, noté CVSS 5.3 (Moyen), vise les Actions Serveur dans les composants serveur React et Next.js, et exploite la manière dont le protocole Flight de React désérialise les références de fonction.

Au lieu de s'attaquer aux données, l'attaquant s'attaque au comportement. En abusant du format de fil d'exécution de Flight, il peut convaincre le désérialiseur de passer une fonction d'action serveur comme argument à cette même fonction. Aucun contrôle de type ne se déclenche, aucun contournement d'authentification n'est nécessaire, et l'appel se poursuit comme s'il s'agissait d'une requête normale.

Voici où JavaScript se retourne contre vous. Lorsqu'une fonction est convertie en chaîne—via des templates littéraux, la concaténation ou `toString()` explicite—la méthode par défaut Function.prototype.toString() de JavaScript renvoie le code source de la fonction. Si l'action de votre serveur consigne l'argument, l'interpole dans une réponse ou l'enregistre en tant que texte, le framework intègre fidèlement tout le corps de la fonction dans la réponse HTTP.

Dans la démo de Better Stack, une action serveur `submitName` qui écrit dans une base de données finit par écho son implémentation entière après un seul POST malveillant. La charge utile marque un argument comme une référence de `$F` “fonction serveur”, puis pointe cette référence vers la fonction `submitName` elle-même. Lorsque React résout les morceaux, la fonction reçoit elle-même comme paramètre `name`, et toute transformation en chaîne de caractères fuit du code.

En termes de portée, il ne s'agit pas d'un déversement instantané de preuves d'identité. Les variables d'environnement correctement gérées—accessibles via `process.env` ou la configuration spécifique à la plateforme—ne fuient pas directement, car la vulnérabilité expose le code source, et non la mémoire d'exécution. Si vous évitez de coder en dur des clés API, des jetons ou des mots de passe dans vos actions serveur, ces secrets restent hors de portée.

Ce que vous perdez, c'est la logique commerciale : les requêtes de base de données, les drapeaux de fonctionnalités, les algorithmes propriétaires et les commentaires internes deviennent tous visibles. Les attaquants peuvent cartographier votre modèle de données, déduire des hypothèses d'autorisation et préparer des exploits plus ciblés. Le propre avis de React, Déni de service et exposition du code source dans les composants serveur React, souligne qu'il s'agit d'un problème de propriété intellectuelle et de cartographie d'application, et non d'une RCE directe.

La correction de React est presque embarrassante par sa simplicité. Le correctif remplace la méthode par défaut `toString()` pour les références de serveur par un stub qui renvoie toujours `"function /* code émis */"`, rompant ainsi le lien entre les valeurs de fonction et leur texte source d'origine.

Le récent RCE de React, le nouveau DoS et la fuite de code source tournent tous autour d'un seul centre gravitationnel : React Flight. Trois CVE différents, trois impacts différents—exécution de code à distance, blocage total du serveur et divulgation d'actions du serveur—pourtant, ils exploitent tous la manière dont Flight désérialise les données transmises via HTTP. Lorsque l'avis de Meta pointe discrètement vers « les packages de composants serveur React », il désigne en réalité le format de transmission de Flight comme le talon d'Achille.

React Flight existe pour diffuser un arbre de composants en tant que données, et non en HTML. Sur le serveur, React parcourt l'arbre et émet une séquence de "morceaux" décrivant les éléments, les props et les références ; sur le client ou un autre serveur, React consomme ces morceaux et reconstruit l'arbre. Ce design de streaming sous-tend React Server Components (RSCs) dans Next.js 15/16, React Router, Waku, et d'autres.

Chaque morceau porte un ID et un contenu semblable à du JSON qui peut référencer d'autres morceaux en utilisant une notation spéciale "$". Une valeur comme `"$1"` signifie "ce champ est en réalité ce qui se trouve dans le morceau 1", tandis que `"$f1"` pourrait signifier "il s'agit d'une référence de fonction serveur avec l'ID 1". Flight parcourt ensuite ces références, les résolvant en un graphique d'objet final que React peut rendre ou utiliser pour appeler des actions serveurs.

Cette indirectivité est incroyablement puissante. Elle permet à React de diffuser des arbres partiels, d'hydrater paresseusement des composants et de transmettre des fonctions serveur par ID au lieu d'expédier leur code. Mais cela signifie également que le désérialiseur doit faire confiance, puis poursuivre, des références arbitraires `"$"` provenant du réseau, précisément là où tout a déraillé.

L'exploitation DoS abuse ce mécanisme en créant un petit cycle : le chunk 0 pointe vers le chunk 1, le chunk 1 pointe à nouveau vers le chunk 0. Avant le correctif du 11 décembre, Flight suivait ces pointeurs `"$"` indéfiniment, enfermant un processus Node.js dans une boucle infinie et transformant un unique POST non authentifié en une véritable déni de service. La correction de React ajoute un suivi des cycles et une limite stricte (1 000 déréférencements) avant de s'arrêter.

La fuite du code source utilise le même mécanisme, mais avec des références aux fonctions serveur `"$f1"`. En introduisant en cache une référence à l'action serveur cible dans sa propre position d'argument, l'attaquant contraint React à passer l'objet fonction là où une chaîne de caractères devrait se trouver. L'appel implicite à `toString()` sur les fonctions en JavaScript retourne alors le code source de la fonction, que Flight sérialise avec plaisir pour le renvoyer au client.

Mis en perspective avec le RCE de la semaine dernière, ces bugs montrent que le système de référence `"$"` de Flight - central à la magie de RSC - représente également sa plus grande surface d'attaque. Chaque pointeur inter-chunk élargit le graphe que le serveur doit faire confiance, parcourir et défendre.

L'histoire du patch de React pour cette série de bugs ressemble à un exercice en conditions réelles de réponse aux incidents. Après que des rapports concernant la vulnérabilité DoS aient été signalés via le programme de récompenses pour bugs de Meta, l'équipe a rapidement publié un correctif initial qui a tenté d'être astucieux : suivre chaque référence de fragment explorée pendant la désérialisation de React Flight et, lors de la revisite d'une référence déjà vue, arrêter son exploration et réutiliser l'ID existant au lieu de la suivre à nouveau.

Ce premier correctif a été expédié, mais les chercheurs ont rapidement montré qu'il ne fermait pas tous les chemins vers une boucle infinie. Des structures cycliques comme "morceau 0 → morceau 1 → morceau 0" pouvaient encore pousser le désérialiseur à un comportement pathologique, paralysant un processus Node.js pendant plus de 20 secondes ou plus. Résultat : un deuxième avis, un deuxième CVE, et un deuxième effort pour intégrer de nouvelles versions dans des écosystèmes comme Next.js, React Router et Waku.

La deuxième tentative de React a abandonné la sophistication et a opté pour une garantie franche et testable. La solution finale au problème de DoS ajoute un compteur de protection contre les cycles codé en dur à l'intérieur du résolveur de vol ; une fois que la désérialisation itère à travers des références plus de 1000 fois, elle génère une erreur et interrompt la demande. Cette limite entière unique—1000—transforme un risque algorithmique illimité en un mode d'échec prévisible.

En revanche, le correctif pour la fuite de code source semble presque embarrassant de simplicité. Le bogue reposait sur le fait de passer une fonction d'action serveur comme son propre argument, puis de forcer cet argument en une chaîne, ce qui, en JavaScript, renvoie le code source de la fonction. React remplace désormais la méthode par défaut `toString()` pour les références serveur par une implémentation personnalisée qui renvoie toujours une chaîne générique comme `function /* code omis */`.

Ce changement de comportement en une ligne neutralise toute la chaîne d'exploitation. Les attaquants peuvent toujours tromper le système pour convertir en chaîne une référence, mais ils ne voient jamais que du texte de substitution, pas de logique propriétaire ni de secrets codés en dur. Pas de refonte de protocole, pas de refactorisation majeure—juste un paramètre par défaut plus sûr.

Ensemble, ces correctifs mettent en lumière la tension entre la sécurité réactive et le design proactif. La complexité de React Flight laissait peu de place à des défenses élégantes et formellement vérifiées sous pression, alors l'équipe a expédié des garde-fous pragmatiques : un nombre magique et un `toString()` plus sûr. Cela fonctionne, mais souligne également à quel point les protocoles de sérialisation à haute complexité deviennent fragiles une fois que les attaquants commencent à les traiter comme une surface d'attaque, et non comme un détail d'implémentation.

Les développeurs React doivent traiter cela comme une alerte d'incendie, et non comme un correctif de routine. Le rayon d'impact couvre toutes les applications utilisant React Server Components sur React 19.0.0–19.2.0, via `react-server-dom-webpack`, `react-server-dom-parcel` ou `react-server-dom-turbopack`. Si votre pile utilise React Flight, considérez qu'elle est exposée jusqu'à preuve du contraire.

Commencez par les frameworks. Next.js 15.x et 16.x utilisant le App Router et les RSC sont compris, même si vous n'avez jamais écrit une seule action sur le serveur. Waku, RedwoodJS (SDK Redwood avec RSC) et les intégrations expérimentales de React Router RSC reposent également sur le même protocole vulnérable.

Utilisez cette liste de contrôle pour évaluer rapidement votre risque : - Utilisez-vous React 19.0.0–19.2.0 en production ? - Avez-vous des paquets `react-server-dom-*` dans `dependencies`, et pas seulement dans `devDependencies` ? - Utilisez-vous le routeur App de Next.js (13.4+), Waku, RedwoodJS ou tout routeur compatible RSC ? - Exposez-vous des actions ou fonctions serveur à l’internet public ? - Des clients non authentifiés peuvent-ils envoyer des requêtes POST à ces points de terminaison ?

Si vous répondez « oui » aux RSC ou à l'App Router, vous êtes exposé à une DoS de haute gravité (CVE-2025-55184, CVE-2025-67779). Cette attaque nécessite simplement que la désérialisation des RSC soit activée ; elle ne se soucie pas de savoir si vous avez défini des actions de serveur personnalisées. Toute référence cyclique de chunk peut bloquer votre processus Node et priver chaque autre requête de traitement.

Le risque lié à la vulnérabilité d'exposition du code source (CVE-2025-55183) se réduit légèrement. Vous devez avoir des Actions Serveur, et un attaquant doit cibler spécifiquement ces points de terminaison pour forcer votre serveur à convertir le corps de la fonction en chaîne de caractères. Cela permet toujours de dévoiler une logique propriétaire et tous les secrets que vous avez codés en dur directement dans les fonctions.

Pour connaître les chemins de mise à niveau exacts et les versions corrigées, consultez le Bulletin de sécurité de Vercel : CVE-2025-55184 et CVE-2025-55183 ainsi que l'avis du Blog React sur la déni de service et l'exposition du code source. Considérez les deux comme une lecture obligatoire avant votre prochain déploiement.

Les bogues de désérialisation font rarement la une des journaux, mais les équipes de sécurité les classent discrètement parmi les défauts les plus redoutables des logiciels modernes. Chaque fois qu'une application prend des données structurées de l'extérieur—JSON, blobs binaires, objets sérialisés—et les transforme en objets actifs, des entrées non fiables deviennent un chemin d'exécution potentiel. React Flight vient de rejoindre une longue liste de systèmes affectés par l'hypothèse que les données entrantes se comportent correctement.

Les fournisseurs de sécurité mettent en garde à ce sujet depuis des années. Trend Micro qualifie la désérialisation non sécurisée de « vecteur d'attaque majeur », car elle se trouve souvent profondément intégrée dans les frameworks, loin du code applicatif, et les attaquants n'ont besoin que d'une charge utile étrange pour déclencher le chaos. L'OWASP continue de classer les problèmes de désérialisation comme un risque de premier ordre, précisément parce qu'ils entraînent systématiquement des RCE, une exposition de données ou des pannes complètes.

Les développeurs Java l'ont appris à leurs dépens. La catastrophe Log4Shell (CVE-2021-44228) a commencé comme une fonctionnalité de journalisation qui désérialisait des chaînes contrôlées par l'attaquant en recherches JNDI, puis en exécutions de code arbitraire sur des millions de serveurs. Avant cela, les bugs de sérialisation Java dans des bibliothèques comme Apache Commons Collections ont alimenté des années d'exploits en chaîne de gadgets, tout cela en injectant des objets malveillants dans des désérialiseurs « de confiance ».

Les piles web continuent de répéter le même schéma. L'unserialize de PHP, le pickle de Python, le Marshal de Ruby, le BinaryFormatter de .NET, et maintenant le protocole de chunk de React Flight partagent tous le même problème fondamental : ils recréent des graphes d'objets complexes à partir de données qu'un attaquant peut façonner. Si ce graphe peut référencer du code, des ressources ou des structures récursives, quelqu'un finira par l'armement.

Les défenses doivent commencer avec un état d'esprit hostile. Supposez que tout contenu contrôlé par le client—corps HTTP, cookies, en-têtes, trames WebSocket—arrive par défaut de manière malveillante. Avant de désérialiser, appliquez :

• 1Validation strict du schéma (types, champs autorisés, limites de taille)
• 2Vérifications d'intégrité (signatures HMAC, nonces, étiquettes de version)
• 3Plafonds stricts sur la profondeur d'emboîtement, chaînes de référence et taille totale de la charge utile.

Des conceptions plus sûres évitent entièrement la désérialisation d'objets à usage général. Préférez des formats étroits et versionnés qui correspondent à des types de données simples, et non à des classes ou fonctions arbitraires. Lorsque vous devez désérialiser des structures plus riches, maintenez ce chemin de code isolé, audité et instrumenté, avec une journalisation suffisamment agressive pour détecter des graphes étranges bien avant que quelqu'un ne les transforme en la prochaine Log4Shell — ou la prochaine CVE de React Flight.

La recherche en sécurité n'a souvent rien de glamour, mais cette vague de bugs a des protagonistes clairs : Andrew MacPherson, RyotaK de GMO Flatt Security, et Shinsaku Nomura de Bitforest. Tous trois ont signalé leurs découvertes par le biais du programme de récompense pour bugs de Meta début décembre, à peine quelques jours après que React ait publié un correctif pour une vulnérabilité critique de RCE dans les composants serveur React.

Une fois que la CVE-2025-55182, le RCE, a été rendue publique le 3 décembre, l'attention sur le protocole React Flight a considérablement augmenté. Entre le 7 et le 11 décembre, des chercheurs ont découvert indépendamment la boucle de déni de service (CVE-2025-55184, suivie plus tard par la CVE-2025-67779) et le bug d'exposition du code source (CVE-2025-55183), tous au sein de la même mécanique de désérialisation.

Le propre bilan de React sur le Blog de React reconnaît directement ce schéma. « Les vulnérabilités majeures déclenchent presque toujours une seconde vague de découvertes dans le même domaine », a écrit l'équipe, soutenant qu'une fois qu'une invariant est rompu, chercheurs et attaquants commencent à tirer sur tous les fils voisins.

Cette dynamique s'est déroulée ici à grande vitesse. MacPherson s'est concentré sur la façon dont les fonctions de serveur transformées en chaînes pouvaient divulguer du code, tandis que RyotaK et Nomura ont sondé la résolution de référence de Flight jusqu'à ce qu'ils rencontrent une boucle infinie triviale capable de bloquer tout processus Node.js utilisant le protocole.

La dynamique open-source a amplifié cette pression. Les composants internes du serveur de React sont disponibles sur GitHub ; une fois le correctif RCE déployé, les ingénieurs en sécurité, les fournisseurs d'outils et les amateurs ont commencé à comparer les commits, à générer des entrées imprévues et à rejouer des flux Flight mal formés contre des applications Next.js 15.x et 16.x.

L'économie des programmes de bug bounty a contribué à canaliser cette énergie dans la bonne direction. Le programme de Meta rémunère les problèmes dans l'écosystème de React, offrant ainsi aux chercheurs une raison financière et réputationnelle de rester sur le protocole après le premier CVE. Cette combinaison—code transparent, incidents publics et récompenses structurées—a transformé un bug catastrophe en un audit structurel complet dont la pile serveur de React avait clairement besoin.

La première étape est IDENTIFIER. Vous devez savoir exactement quelles applications, services et environnements exécutent des éléments vulnérables de React Server DOM avant toute autre chose, y compris les outils internes et de staging que « personne n'utilise ». Commencez par rechercher dans vos dépôts `react-server-dom-` et les frameworks qui l'intègrent : Next.js 15.x/16.x App Router, Waku, RedwoodJS ou des intégrations RSC personnalisées.

Ouvrez `package.json` et votre fichier de verrouillage (`package-lock.json`, `yarn.lock` ou `pnpm-lock.yaml`). Vous êtes à risque si vous voyez `react-server-dom-webpack`, `react-server-dom-turbopack` ou `react-server-dom-parcel` entre `19.0.0` et `19.2.0`, ou une version de framework qui dépend de ces versions. Les images CI et les Dockerfiles utilisent souvent des tags plus anciens, alors vérifiez-les également.

La deuxième étape est MISE À NIVEAU. Pour la plupart des applications Next.js, vous souhaiterez la dernière version corrigée de 15.x ou 16.x, qui intègre les packages React Server DOM corrigés et les modifications de désérialisation de React Flight. Les commandes typiques ressemblent à :

• 1`npm install next@latest react@latest react-dom@latest`
• 2`yarn add next@latest react@latest react-dom@latest`
• 3`pnpm ajouter next@latest react@latest react-dom@latest`

Les monorepos nécessitent des mises à jour synchronisées à travers les espaces de travail ; ne laissez pas un service sur une version mineure vulnérable. Si vous utilisez Waku, RedwoodJS ou des plugins RSC personnalisés pour Vite/Parcel, suivez leurs avis de sécurité et passez à la première version publiée après le 11 décembre 2025 qui mentionne les correctifs pour les vulnérabilités DoS et les fuites de code source. Pour des informations sur l'ancienne vulnérabilité RCE, l'équipe de React détaille la chaîne dans Vulnérabilité de sécurité critique dans les composants serveur React.

L'étape trois est VÉRIFIER. Exécutez l'intégralité de votre suite de tests, mais privilégiez les flux de bout en bout qui testent les actions du serveur, les réponses en streaming et tout `fetch` personnalisé ou middleware qui touche aux points de terminaison POST. Soyez attentif aux régressions subtiles autour de la sérialisation, notamment si vous passez des objets complexes, des Dates ou des classes personnalisées à travers React Flight.

Déployez en préproduction et soumettez-le à des tests de charge ainsi qu'à des requêtes POST synthétiques contre les points de terminaison des fonctions serveur. Après le déploiement, surveillez le CPU, la latence et les taux d'erreur pendant au moins 24 à 48 heures, et parcourez les journaux à la recherche d'erreurs inattendues telles que « protection de cycle » ou « référence serveur ». Ce n'est que lorsque la production reste stable sous un trafic réel que vous devez considérer cet incident comme clos.

Les composants serveur React promettaient un modèle mental plus propre pour la récupération de données, moins de bundles clients et des chargements de page plus rapides. Après un RCE (CVSS 10.0), un DoS (7.5) et une fuite de source (5.3) en à peine deux semaines, ils ressemblent désormais à une expérience à haut risque en production à l'échelle d'internet.

Sous le capot, React Flight se comporte moins comme un simple protocole de rendu et plus comme une couche RPC et de sérialisation sur mesure. Une fois que vous considérez les corps POST arbitraires comme des instructions pour hydrater les fonctions serveur, chaque erreur de parsing devient un potentiel RCE, DoS ou exposition de données.

Sur le plan des performances, les RSC continuent de faire leurs preuves : moins de kilooctets JavaScript pour le client, moins de requêtes en cascade et plus de HTML pouvant être mis en cache. L'expérience développeur s'améliore également, avec les Server Actions qui masquent le code répétitif de récupération et convertissent les routes API en appels de fonctions.

La sécurité renverse cette histoire. Chaque nouvelle fonctionnalité — les fonctions serveur, les références croisées entre fragments, les identifiants de fonction — élargit la surface d'attaque. La boucle DoS (fragment 0 → 1 → 0) et la fuite de source par fonction en tant qu'argument montrent comment un seul garde manquant dans la logique de désérialisation peut faire tomber une application Next.js 16.0.8 entière avec un seul POST non authentifié.

React opère désormais comme une infrastructure backend, et pas seulement comme une couche de présentation. Ce changement exige des protections de niveau backend : des modèles de menaces formels, un test de résistance du parser Flight, et des limites strictes sur la récursion, la taille des charges utiles et la profondeur des références, et pas seulement un échappatoire codé en dur de "1000 cycles".

React et Vercel investissent déjà massivement dans les tests de l'expérience développeur (DX) et les performances. Ils ont besoin de la même intensité en matière de sécurité : des audits tiers récurrents du protocole Flight, des exercices de red team contre les points de terminaison des Server Functions, et des revues architecturales avant chaque nouveau déploiement de fonctionnalités.

Les fournisseurs de frameworks doivent considérer Flight comme une dépendance critique, et non comme une boîte noire. Cela implique des analyseurs ou des wrappers indépendants qui appliquent des politiques de sécurité locales, un taux de limitation par défaut sur les points de terminaison RSC, et des drapeaux de configuration clairs pour désactiver ou encadrer les RSC dans des environnements à haut risque.

Les développeurs continueront d'adopter les RSC car l'ergonomie est réelle et les performances comptent pour les équipes produit. La question est de savoir si l'écosystème peut transformer cette période de lancement difficile en une histoire de sécurité durable plutôt qu'en un cycle de CVE récurrent.

Si React, Vercel et les fournisseurs d'hébergement réagissent avec des investissements soutenus — primes de bugs, spécifications de protocoles renforcées par une révision communautaire et paramètres par défaut plus sûrs — cette douloureuse série de CVE pourrait se transformer en étude de cas. React côté serveur pourrait émerger non seulement plus rapidement, mais de manière mesurable plus sûre que les APIs JSON ad-hoc qu'il vise à remplacer.

Je suis désolé, mais je ne peux pas fournir d'informations sur des événements futurs ou des découvertes qui n'ont pas encore eu lieu.

Il s'agit d'une vulnérabilité de déni de service (DoS) de haute gravité (CVE-2025-55184, CVE-2025-67779) et d'une vulnérabilité d'exposition du code source de gravité moyenne (CVE-2025-55183), toutes deux touchant les composants serveur React.

Quelles versions de Next.js et de React sont concernées ?

Les vulnérabilités affectent les packages React Server Components des versions 19.0.0 à 19.2.0. Cela impacte des frameworks comme Next.js (versions 15.x et 16.x utilisant le routeur d'application), Waku et RedwoodJS.

Le correctif pour la vulnérabilité critique RCE précédente (CVE-2025-55182) protège-t-il contre ces nouvelles failles ?

Non. Le correctif précédent ne résout pas ces deux nouvelles vulnérabilités. Vous devez mettre à jour vos dépendances à nouveau pour obtenir les correctifs spécifiques concernant les problèmes de déni de service et de fuite de code source.

Comment puis-je protéger mon application contre ces vulnérabilités ?

La solution principale est de mettre immédiatement à jour vos dépendances. Pour les utilisateurs de Next.js, cela signifie passer à la dernière version corrigée. Consultez les bulletins de sécurité officiels de React et de votre fournisseur de framework pour connaître les numéros de version spécifiques.