Il y a des CVE qui font peur parce qu’elles « volent des données ». Et il y a celles qui font mal pour une raison beaucoup plus bête : elles te font tomber. Celle-ci touche Next.js via les Server Components et peut déclencher un DoS en envoyant des requêtes HTTP spécialement forgées vers des endpoints d’App Router Server Function. Rien de sexy, pas de ransomware, pas d’exfiltration. Juste ta prod qui part en CPU et qui se transforme en radiateur.
L’objectif ici, c’est le concret orienté prod : qui est concerné, comment vérifier vite, comment patcher (versions fixes), et surtout quoi mettre en place tout de suite si tu ne peux pas bump Next.js dans l’heure.
CVE-2026-23869 (DoS Server Components) : ce qui se passe vraiment
La faille (CVE-2026-23869) est décrite comme un Denial of Service avec Server Components. Le scénario est simple : un attaquant envoie une ou plusieurs requêtes HTTP construites pour forcer Next.js à faire une désérialisation coûteuse, ce qui provoque une consommation CPU excessive.
Traduction terrain : tu peux te retrouver avec des pics CPU, des latences qui explosent, des timeouts, puis un effet domino classique. Sur du Node, quand l’event loop souffre, tout souffre. Et si tu es sur un modèle « autoscale », tu peux en plus te faire ouvrir en deux côté facture.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Versions Next.js touchées (et versions corrigées)
D’après l’avis de sécurité Vercel, sont concernées :
Next.js >= 13.0.0 et < 15.5.15, ainsi que Next.js >= 16.0 et < 16.2.3.
Les versions qui corrigent sont :
15.5.15 et 16.2.3.
Je le dis comme je le pense : si tu es dans les ranges touchées et que ton app expose les endpoints concernés, le patch est la réponse normale. Les mitigations, c’est pour acheter du temps, pas pour « faire sans ».
Pourquoi c’est vicieux : tu peux être vulnérable sans endpoint “public” évident
Le piège, c’est que ce n’est pas une route « /admin » oubliée. Ça vise des endpoints liés à l’App Router et aux mécanismes Server Components / Server Functions. Donc une app parfaitement « normale », avec des pages publiques, peut quand même exposer une surface d’attaque intéressante.
Autre point important : sur un DoS, l’attaquant n’a pas besoin d’un compte. Il n’a même pas besoin de trouver une logique métier. Il a juste besoin d’un point d’entrée qui déclenche le chemin de code coûteux. Et ça, c’est exactement le genre de truc qui passe sous le radar tant que personne ne t’attaque.
Comment vérifier rapidement si ton projet est concerné
La première vérif est bête : ta version Next.js. En monorepo ou en multi-apps, c’est souvent là que ça se complique, parce que tout le monde n’est pas au même niveau.
# version installée dans le projet courant
npm ls next
# ou
pnpm why next
# ou
yarn why nextEnsuite, côté exposition, je regarde en priorité si le projet utilise l’App Router et des patterns typiques de Server Functions / Server Actions. Tu ne trouveras pas forcément une route dédiée « action endpoint » dans ton code, parce que l’infrastructure est en partie gérée par le framework. Mais tu peux quand même te donner un signal en cherchant l’usage de server actions.
# repère classique : directives de Server Actions dans l'App Router
rg -n "\"use server\"" app src || trueSi tu en as, tu as très probablement une surface d’attaque pertinente, et tu dois partir du principe que tu es concerné tant que tu n’as pas patché. Si tu n’en as pas, ça ne te donne pas un « safe » garanti, mais ça t’aide à prioriser.
Dernier truc très concret : regarde tes logs. Les requêtes qui ciblent ces mécanismes ont souvent des headers ou des content-types spécifiques (liés à RSC / actions). Tu n’as pas besoin de comprendre tout le protocole pour détecter un pattern : des POST anormaux, des bodies étranges, et surtout une corrélation nette entre requêtes et CPU.
Le plan de patch : upgrade Next.js sans drama (le plus possible)
Le patch, c’est « upgrade vers une version fixée ». Dans ce cas, vise 15.5.15 (si tu es sur la branche 15) ou 16.2.3 (si tu es déjà sur 16). Dans la vraie vie, tu ne « patches » pas Next.js comme un petit lib : ça peut déplacer des comportements, des warnings, parfois des builds.
Mon approche en prod, quand je veux que ça passe vite, c’est de réduire le scope de l’upgrade. Tu bumpes Next.js, tu rebuild, tu fais un sanity check sur les routes critiques (homepage, login, paiement, recherche, tout ce qui fait ton trafic), puis tu déploies. Tu gardes une fenêtre pour rollback, et tu évites de coupler ça à une refacto ou à une mise à jour React « tant qu’à faire ». Le « tant qu’à faire » est l’ennemi des patchs sécurité rapides.
Si tu as une infra avec plusieurs services, ne te fais pas piéger par un déploiement partiel. Il suffit qu’une app publique reste sur une version vulnérable pour rester attaquable. Et sur un DoS, l’attaquant ne va pas « gentiment » taper l’app déjà patchée.
Mitigations immédiates si tu ne peux pas upgrader tout de suite
On va être clair : une mitigation n’est pas une correction. L’objectif ici, c’est de réduire la capacité d’un attaquant à te cramer le CPU, en mettant des barrières là où ça coûte le moins cher pour toi. Le meilleur endroit pour stopper un DoS, c’est avant d’arriver à ton process Node.
Rate limiting ciblé : pas “un rate limit global” qui casse ton produit
Le rate limiting « global » façon 100 req/min par IP, c’est tentant… et souvent une mauvaise idée. Tu vas pénaliser tes utilisateurs NATés, tes bureaux, tes mobiles, et tu vas créer des faux positifs. À la place, je cible les endpoints / patterns qui ressemblent à des appels Server Components / Server Functions, typiquement des POST qui déclenchent ces mécanismes.
Concrètement, tu peux mettre le rate limit au niveau CDN/WAF/reverse proxy, avec une règle basée sur le chemin, la méthode, et si possible certains headers. L’idée n’est pas d’être parfait, c’est d’être suffisamment contraignant pour un attaquant sans dégrader ton trafic normal.
Limiter la taille de body et refuser les requêtes “hors norme”
Quand une faille DoS est liée à de la désérialisation, la taille du body et la forme du payload sont souvent des leviers. Tu peux poser une limite stricte sur le Content-Length et refuser ce qui dépasse, au moins sur les routes qui n’ont aucune raison d’accepter des gros bodies.
Attention au piège classique : si tu as des formulaires légitimes (upload, payload JSON volumineux), ne mets pas une limite aveugle partout. Mais sur des appels d’actions serveur, dans beaucoup d’apps, un body de plusieurs centaines de Ko n’a juste pas de sens. C’est typiquement le genre de seuil simple qui coupe déjà une partie du risque.
Timeouts et protections CPU : tu veux tomber “vite” plutôt que “lentement”
Sur un DoS CPU, le pire scénario, c’est de laisser les requêtes s’empiler et de faire mourir tout le monde ensemble. Ce que tu veux, c’est rejeter tôt quand ça commence à sentir mauvais. Ça passe par des timeouts au niveau proxy, des limites de concurrence, et parfois des politiques de circuit breaker en amont.
Ce n’est pas glamour, mais c’est ce qui évite l’incident où ton API reste « techniquement up » pendant 10 minutes, tout en étant inutilisable. Et derrière tu passes une heure à expliquer que « oui, c’était up sur le monitoring ».
WAF : utile si tu sais ce que tu bloques (sinon tu joues à la roulette)
Un WAF peut aider si tu arrives à identifier un pattern de requêtes clairement anormal. Le bon usage ici, c’est d’ajouter une règle basée sur ce que tu observes dans tes logs au moment des attaques (headers, méthodes, chemins, tailles, fréquences). Le mauvais usage, c’est de coller une règle générique « anti-bot » et de croire que c’est réglé.
Le WAF n’est pas magique, mais il a un avantage énorme : bloquer en edge coûte beaucoup moins cher que de laisser Node cramer du CPU. Donc oui, en mitigation, je le considère souvent comme un levier rentable.
Surveillance : comment détecter que tu es en train de te faire DoS (et pas juste “ça rame”)
Le DoS CPU a des signatures assez reconnaissables : CPU qui monte en flèche, temps de réponse qui dérive, taux de 5xx qui augmente, et souvent une concentration anormale sur quelques routes. Ce que je veux voir en premier, ce n’est pas un dashboard « tout-en-un ». C’est la corrélation entre latence, CPU et top endpoints.
Si tu as un APM (Datadog, New Relic, Sentry Performance…), mets le focus sur les transactions qui explosent en durée CPU et sur le volume de requêtes. Si tu n’en as pas, tes logs et quelques métriques infra suffisent pour prendre une décision : est-ce qu’on bloque, est-ce qu’on scale, est-ce qu’on coupe une feature, est-ce qu’on déploie le patch maintenant.
Et si tu veux un truc bête mais efficace : alerte sur une hausse brutale de CPU couplée à une hausse brutale de requêtes POST sur les pages App Router. Le but n’est pas de faire une détection « sécurité académique », c’est d’être réveillé avant que ton support ne prenne 50 tickets.
Mon arbitrage en prod : ce que je ferais aujourd’hui si j’étais on-call
Si mon app est dans les versions vulnérables, je pars du principe que le patch est prioritaire. Même si je n’ai « vu aucune attaque ». Avec ce type de CVE, ce n’est pas quand tu vois l’attaque que tu dois commencer à réfléchir. Le temps de réflexion, tu le payes en indispo.
Donc mon ordre d’action est simple : je prépare l’upgrade vers 15.5.15 ou 16.2.3, je déploie dès que possible, et je mets en attendant une mitigation basique mais solide en edge. En général, un rate limit ciblé + une limite de body sur les routes pertinentes te donnent déjà une vraie marge de sécurité. Ensuite seulement, j’affine avec des règles WAF plus « intelligentes » basées sur l’observation.
Et je documente l’incident potentiel. Pas un roman. Juste de quoi répondre vite à trois questions quand ça chauffe : « quelle version on a », « est-ce qu’on a patché partout », « quelles règles on a posées en edge ».
Conclusion : une CVE DoS, ça se traite comme un sujet de perf (mais hostile)
Ce genre de CVE est frustrant parce qu’il n’y a pas de « leak » à brandir, pas d’IOCs sexy, pas de post-mortem à base de secrets volés. Mais l’impact est ultra concret : ton produit devient lent ou indisponible. Et c’est souvent plus cher qu’une fuite minuscule que personne n’exploite.
Patch dès que possible vers 15.5.15 ou 16.2.3. Et si tu as un délai, assume-le et compense intelligemment avec de l’edge, du rate limiting et de la surveillance. Ça ne rend pas la faille « OK », mais ça t’évite de découvrir le problème au pire moment, sur ton pic de trafic.
