Sécurité Next.js en mai 2026 : le vrai risque vient du cache RSC

Sécurité Next.js : le constat en une phrase et les vraies priorités

Next.js a publié 13 avis de sécurité coordonnés le 6 mai 2026, puis les versions corrigées le 7 mai : 16.2.6 et 15.5.18. Toute la presse s’est focalisée sur CVE-2026-44578, la SSRF WebSocket, parce que le scénario est spectaculaire : un attaquant fait passer une connexion en WebSocket, le serveur se rend lui-même sur 169.254.169.254, puis le point de terminaison des métadonnées lui renvoie des identifiants IAM.

Mais elle ne concerne que les déploiements auto-hébergés. Sur une application gérée par Vercel avec Cloudflare en frontal, ce chemin est inaccessible. La vulnérabilité qui peut réellement atteindre mes lecteurs est celle, classée Moderate, qui empoisonne le cache RSC. Personne n’en parle, alors qu’une réponse RSC empoisonnée ne reste pas cantonnée à la requête de l’attaquant : elle arrive dans mon cache edge partagé, puis elle est servie à tous les visiteurs jusqu’à la purge du tag.

Si vous utilisez une version de Next.js >= 13.4.13, la mise à jour doit être faite cette semaine. Les seules questions sont : vers quelle version, dans quel ordre, et quels tests faut-il rejouer ensuite ? La matrice ci-dessous est celle que j’ai appliquée à omidsaffari.com — App Router sur Vercel, Cloudflare en frontal, purge par Cache-Tag et webhook de revalidation. C’est elle qui m’a conduit à délaisser la CVE qui fait les gros titres au profit d’une autre priorité.

Ce que cela signifie pour les fondateurs non techniques

Si votre produit repose sur Next.js, cette tâche est à traiter cette semaine, pas à reléguer dans le backlog. Le risque financier ne se mesure ni en latence ni en heures de développement : une page empoisonnée dans le cache ou une route d’administration accessible sans authentification devient un incident de confiance client. Une seule capture d’écran montrant du contenu injecté par un attaquant sur votre page marketing, un seul signalement d’un accès à /admin sans session, et vous passerez la semaine suivante à vous justifier au lieu de vendre.

Posez une seule question à vos ingénieurs : « Sommes-nous en 16.2.6 ou en 15.5.18, et le cache edge a-t-il été purgé après le déploiement ? » Si la réponse est moins précise — « on applique le correctif », « c’est en cours », « la SSRF ne nous concerne pas » — le travail n’est pas terminé. Les déploiements auto-hébergés (ECS, EC2, Kubernetes ou tout serveur que vous exploitez avec next start) appartiennent à la catégorie la plus exposée, car ils sont vulnérables à la SSRF en plus du reste. Demandez dans quelle catégorie vous vous trouvez. La réponse doit prendre dix secondes.

Les 13 avis, classés selon leur capacité à atteindre votre stack

Tous les articles du moment qui répètent « 13 CVE, corrigez tout maintenant » commettent la même erreur : ils traitent la liste comme si tous les risques se valaient. Ce n’est pas le cas. Chaque avis suppose une condition préalable — auto-hébergement, Turbopack, Cache Components, nonces CSP, i18n — et votre exposition réelle se limite aux vulnérabilités dont les conditions correspondent à votre déploiement. Voici les 13 avis, regroupés selon ce qu’il faut pour qu’ils soient exploitables.

Groupe des contournements de middleware et de proxy (5 avis, classés High pour la plupart). Le plus important est GHSA-267c-6grr-h53f : une URL de préchargement de segment de l’App Router peut contourner les contrôles d’authentification du middleware. Le groupe comprend aussi le correctif incomplet publié le 7 mai (GHSA-26hh-7cqf-hhc6) pour Turbopack, le contournement d’un chemin de locale par défaut i18n dans le Pages Router et le contournement par injection de paramètre dans une route dynamique. Condition préalable : utiliser le middleware Next.js pour l’authentification ou les réécritures. C’est le cas de presque tout le monde.

SSRF, CVE-2026-44578. Dans le serveur auto-hébergé, le gestionnaire d’upgrade WebSocket peut atteindre des points de terminaison HTTP internes sur le port 80, notamment les métadonnées cloud. Versions touchées : 13.4.13+ jusqu’aux versions <15.5.16, ainsi que 16.0.0–<16.2.5, uniquement en auto-hébergement. Il est confirmé que les déploiements gérés par Vercel ne sont pas affectés.

Déni de service, deux avis. Le premier concerne le DoS RSC en amont ; le second, classé High sous la référence GHSA-q4gf-8mx6-v5v3, permet d’épuiser les connexions dans les applications ayant activé Cache Components. Condition préalable pour le second : avoir explicitement activé Cache Components — la plupart des applications ne l’ont pas fait.

Empoisonnement du cache RSC (Moderate). Dans le pipeline des charges utiles RSC, des collisions touchant le mécanisme de contournement du cache permettent à une requête forgée d’empoisonner une réponse mise en cache. Condition préalable : mettre les réponses RSC en cache quelque part en aval — CDN, proxy inverse, edge de Vercel ou Cloudflare. C’est la vulnérabilité qui compte sur ma stack.

XSS, deux avis. CVE-2026-44581 (Moderate) touche les applications App Router qui génèrent des nonces CSP ; une autre XSS concerne les scripts beforeInteractive qui consomment des entrées non fiables. Conditions préalables : déployer une CSP avec des nonces, ou transmettre des données utilisateur à une balise de script beforeInteractive.

Notez les conditions que remplit votre déploiement : vous obtiendrez votre véritable liste. Pour omidsaffari.com, le résultat est le suivant : groupe des contournements de middleware (oui), SSRF (non, hébergement Vercel), DoS RSC (oui, en amont), DoS Cache Components (non, fonctionnalité non activée), empoisonnement du cache RSC (oui, avec amplification), XSS par nonce CSP (oui), XSS beforeInteractive (non). Parmi huit avis High ou Moderate, seuls cinq me concernent ; celui dont le rayon d’impact est le plus large n’est pas le plus médiatisé.

Pourquoi la SSRF omniprésente dans les captures n’est probablement pas votre problème — contrairement au cache poisoning

CVE-2026-44578 suppose que le serveur Node exécutant next start gère l’upgrade WebSocket et suive la redirection. Chez moi, Vercel ne fait pas transiter les requêtes par ce serveur d’une manière qui rendrait le chemin SSRF accessible : la plateforme termine les WebSockets, tandis que le point de terminaison des métadonnées est protégé par IMDSv2 avec une limite de sauts à laquelle ce parcours ne survivrait pas. Ajouter Cloudflare devant ne change rien au constat. Sur une topologie Vercel + Cloudflare, le scénario spectaculaire de la capture d’écran ne fonctionne pas.

L’avis sur le cache poisoning RSC renverse totalement la hiérarchie. La vulnérabilité se trouve dans le chemin de traitement emprunté par tout le monde et aboutit à une charge utile RSC empoisonnée — autrement dit, l’arbre React sérialisé reçu par vos lecteurs. Sur mon site, cette charge utile ne reste pas dans la requête de l’attaquant. Elle arrive ici :

Cache-Control: public, s-maxage=300, stale-while-revalidate=86400
Cache-Tag: article:nextjs-may-2026-security-triage

s-maxage=300 signifie que Cloudflare conserve cette réponse pendant cinq minutes. stale-while-revalidate=86400 l’autorise à continuer de la servir pendant une journée après expiration, le temps de la revalider en arrière-plan. Le Cache-Tag me sert à la purge : lorsque je publie une nouvelle révision, le webhook de revalidation déclenche la purge du tag et l’objet disparaît.

Suivons le parcours d’une réponse empoisonnée. L’attaquant appelle une route qui exploite la collision du mécanisme de contournement du cache. Cloudflare détecte une réponse pouvant être mise en cache, l’enregistre sous la clé de cache de cette URL et lui affecte le tag article:<slug>. Tous les visiteurs suivants de ce slug reçoivent alors depuis l’edge la charge utile RSC empoisonnée — sans retour à l’origine, sans passage par le middleware, sans intervention possible d’une règle WAF ajoutée dix minutes plus tard. L’objet compromis est déjà en aval. Il y reste jusqu’à l’expiration de la fenêtre s-maxage ou jusqu’à ce que mon pipeline de publication lance une purge. Les règles WAF à l’origine ne peuvent rien contre une réponse déjà présente dans 300 PoP.

Voilà pourquoi l’actif menacé est la surface de contenu publiée — le résultat du moteur de contenu — et non une API interne. Sur la liste des 13 avis, la SSRF est classée High et celui-ci Moderate. Pour un site RSC placé derrière un cache, leur ordre d’impact réel est inversé.

La mise à jour exacte, sans tomber dans le piège du correctif Turbopack

Première étape : identifiez la version réellement installée. package.json ne reflète pas forcément la version résolue lorsqu’une plage avec accent circonflexe est utilisée ; vérifiez le lockfile.

bun pm ls | grep next
# or
npm ls next

Épinglez ensuite la version 16.2.6 (branche Next.js 16) ou 15.5.18 (branche Next.js 15). Pas 16.2.5. Pas 15.5.16.

bun add next@16.2.6
# or
npm install next@16.2.6 --save-exact

Cet épinglage précis évite le piège que presque personne ne mentionne. Les 13 avis initiaux ont été corrigés dans les versions 16.2.5 / 15.5.16 le 6 mai. Le 7 mai, Vercel a publié GHSA-26hh-7cqf-hhc6 — un suivi lié à un correctif incomplet du contournement du middleware par préchargement de segment, qui restait exploitable lorsque Turbopack servait la requête. Les utilisateurs sans Turbopack étaient protégés avec 16.2.5 / 15.5.16. Ceux qui utilisaient Turbopack ne l’étaient pas. Le correctif complet se trouve dans 16.2.6 / 15.5.18.

Si votre application est encore sur la branche 13.x ou 14.x, aucun correctif n’arrivera. Vercel ne prévoit pas de rétroportage. Il faut migrer vers 15.x ou 16.x et considérer ce chantier comme une migration, pas comme un simple bun update. Prévoyez au minimum une semaine pour une application non triviale : la surface de rupture est réelle, notamment autour des matchers du middleware et des valeurs de cache par défaut de l’App Router.

Une fois le déploiement terminé, purgez le cache edge. C’est l’étape absente de tous les autres articles que j’ai lus cette semaine. Sans purge, toute charge utile RSC mise en cache par Cloudflare avant l’installation du correctif reste en place. Elle peut avoir été empoisonnée si l’exploitation a eu lieu pendant cette fenêtre et continuera d’être servie depuis l’edge jusqu’à l’expiration de s-maxage. Sur ma stack :

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Vérifiez ensuite le résultat. Choisissez une route protégée par l’authentification du middleware, construisez l’URL de préchargement de segment décrite dans l’avis, puis rejouez-la en production. Vous devez obtenir un 401, un 302 ou toute autre réponse renvoyée par votre middleware aux requêtes non authentifiées. Si vous recevez un 200 avec du contenu, le correctif du middleware n’est pas actif : vous avez un problème de déploiement, pas un problème Next.js.

Ce qui a cassé avec 16.2.6 — sans langue de bois

Soyons clairs : il ne s’agit pas de simples correctifs de sécurité. Plusieurs changent volontairement le routage et le comportement des clés de cache, puisque les vulnérabilités se trouvaient précisément dans le routage et les clés de cache. Il faut donc s’attendre à des différences.

Durcissement des matchers du middleware pour les URL .rsc et de préchargement de segment. Le correctif du contournement par préchargement de segment a modifié la façon dont ces règles correspondent aux URL. Si l’un de vos patterns dépendait de l’ancienne forme — notamment un negative lookahead qui excluait les chemins _next en partant du principe que .rsc s’y trouvait toujours — vérifiez-le à nouveau. J’ai dû élargir un matcher pour intercepter explicitement le suffixe de préchargement de segment sur une route protégée. La correction a pris cinq minutes, mais sans test par rejeu, la régression serait passée inaperçue.

Gestion des nonces CSP. Le correctif XSS (CVE-2026-44581) modifie la propagation des nonces pendant le rendu par l’App Router. Si vous les générez dans le middleware et les référencez dans un composant Script, laissez votre CSP en mode report-only pendant une journée après le déploiement. Je n’ai constaté aucune violation, mais le changement est bien réel et une équipe m’a indiqué avoir dû adapter son workflow de génération des nonces.

Changement de comportement de Cache Components. Si vous utilisez Cache Components et êtes donc concerné par le correctif du DoS par épuisement des connexions, sachez que celui-ci modifie la mutualisation des cache misses sous charge. Testez de nouveau vos chemins les plus sollicités. Je n’utilise pas Cache Components, je n’ai donc pas eu à le faire.

La checklist de validation que j’ai suivie avant de considérer la mise à jour comme terminée :

[ ] next version pinned to 16.2.6 in lockfile
[ ] middleware auth replay on /admin via segment-prefetch URL → 401
[ ] middleware auth replay via .rsc URL → 401
[ ] RSC cache key sanity: same URL, two clients, identical payload
[ ] forced edge purge after deploy
[ ] CSP report-only on for 24h with no new violations
[ ] one full revalidate cycle on a high-traffic page

Prévoyez un passage en staging. Cette montée de version n’est pas sans risque, car les correctifs de sécurité changent volontairement le routage et le comportement des clés de cache. Entre un déploiement le mardi après-midi et un incident le mardi soir, toute la différence tient aux tests par rejeu des chemins d’authentification avant la bascule en production.

Appliquez le correctif plutôt que de compter sur le WAF : la leçon de fond

Vercel n’a publié aucune règle WAF pour cette version. Le changelog indique que l’application du correctif est la seule mesure complète, à juste titre : aucune de ces vulnérabilités ne peut être filtrée proprement à l’edge, car les formes des requêtes malveillantes recouvrent trop largement celles des requêtes légitimes. Le 6 mai, Cloudflare a publié des règles WAF et des mesures d’atténuation dans ses adaptateurs de framework, mais uniquement comme défense en profondeur, pas pour remplacer la mise à jour. La formulation est sans ambiguïté : le changelog de Cloudflare précise que les règles WAF réduisent l’exposition pendant la fenêtre de déploiement, et non après.

C’est la leçon structurelle de cette semaine. Une stack capable de mettre à jour un framework, de redéployer et de purger son cache edge en un seul après-midi transforme la divulgation coordonnée de 13 CVE en simple tâche du mardi. À l’inverse, une stack qui ne le peut pas — parce que la montée de version exige une migration, parce qu’elle ne possède aucun mécanisme de purge, parce que son pipeline de déploiement impose des validations manuelles — reste exposée aussi longtemps que dure le déploiement. Des jours. Parfois des semaines.

On retrouve exactement le principe du raisonnement sur le rayon d’impact des agents : la capacité structurelle à récupérer vite surpasse le filtrage réactif. On ne bloque pas chaque requête malveillante, pas plus qu’on n’empêche chaque mauvais appel d’un agent. On conçoit un système dans lequel, lorsqu’un incident survient, le délai de réponse se compte en minutes et la topologie contient le rayon d’impact — sans s’en remettre à l’espoir.

Faites la mise à jour ce soir. Épinglez 16.2.6 ou 15.5.18. Purgez ensuite le cache. La CVE des captures d’écran n’est pas la bonne source d’inquiétude ; la vulnérabilité Moderate qui touche chaque page en cache est celle qui compte.