Faille Next.js : 8 jours où Dependabot ne voyait rien

Le 14 octobre 2026, Next.js a publié les versions 16.4.1 et 15.5.28 pour corriger trois failles : deux exécutions de code à distance notées 9,5 sur 10 (CVSS v4) et un déni de service noté 8,2. Les trois avis GitHub correspondants ne sont entrés dans la base révisée — celle que lisent Dependabot et la plupart des scanners de dépendances — que le 22 octobre, entre 15h50 et 16h42 UTC. Pendant ces huit jours, une app en 16.4.0 portait une faille critique et rien ne s'allumait. Ce qu'il faut faire maintenant : regarder ta version, puis passer en 16.4.1 ou en 15.5.28.

Suis-je concerné ?

Trois avis, deux niveaux de gravité, des plages de versions qui ne se recouvrent pas exactement. Voilà ce que GitHub publie.

Ce que ça donne selon ta situation :

• Branche 16, en 16.4.0 ou en dessous : les trois te concernent. La RCE use cache exige une fonction use cache qui renvoie plusieurs tableaux typés, mais l'avis précise qu'il n'existe aucun contournement et qu'il faut mettre à jour même si ton code n'a rien de tel.
• Branches 13 à 15, en 15.5.27 ou en dessous : la RCE de l'API Image Optimization et le déni de service te concernent. La faille use cache n'existe pas avant la 16.
• Branches 10 à 12 : seule la RCE de l'API Image Optimization s'applique, elle démarre à la 10.0.0. Le déni de service, lui, démarre à la 13.0.0.
• Pages Router sans Server Action : le déni de service ne s'applique pas, l'avis le dit explicitement. Les deux RCE, si.

Deux commandes pour savoir où tu en es, à la racine du projet :

npm ls next
node -p "require('next/package.json').version"

npm ls next liste aussi les copies imbriquées. Si une dépendance embarque sa propre version de Next, elle apparaît dans l'arbre — et c'est souvent cette copie-là qui reste en 16.4.0 pendant que ton package.json affiche autre chose.

Corriger en 5 minutes

Une commande par étape, dans l'ordre.

1. Regarde d'abord l'état de ton dépôt : un saut de version sur Next casse parfois un détail de build, et tu veux pouvoir revenir en arrière.

git status

2. Installe la version corrigée de ta branche.

npm install next@16.4.1

Si tu es sur la 15 :

npm install next@15.5.28

3. Vérifie ce qui est réellement installé, pas ce que le package.json promet.

npm ls next

Attendu : une seule version, 16.4.1 ou 15.5.28. Si une copie ancienne subsiste dans l'arbre, lance npm dedupe, puis relance la commande.

4. Tu peux aussi demander directement à la base OSV ce qu'elle connaît de ta version :

curl -s -X POST https://api.osv.dev/v1/query -d '{"package":{"name":"next","ecosystem":"npm"},"version":"16.4.0"}'

Trois entrées pour 16.4.0, une réponse vide pour 16.4.1. C'est le même mécanisme que celui qui alimente Dependabot, et c'est ce qui explique les huit jours dont je parle plus bas.

5. Si tu es coincé sur une branche plus ancienne, il te reste un demi-filet pour la RCE de l'API Image Optimization. Cette faille vient du traitement des SVG par sharp, et l'avis donne un contournement : une version de sharp supérieure ou égale à 0.35.5 n'est pas touchée.

npm ls sharp
npm install sharp@^0.35.5

Ce contournement ne couvre que cette faille. Il ne protège ni de la RCE use cache, ni du déni de service.

6. Rebuild et redéploie. Un node_modules à jour sans build ne change rien en production.

npm run build

Après le déploiement, confirme la version servie : un log de démarrage, un endpoint de santé, ou une variable d'environnement que tu affiches. Le build local ne prouve rien sur ce qui tourne réellement.

Une précision qui compte : aucune version corrigée n'existe sur les branches 10 à 14. Les seules versions qui ferment ces failles sont 15.5.28 et 16.4.1. En 14.x, il n'y a pas de npm install next@14.x.y salvateur — seulement une migration, ou le contournement sharp en attendant.

Le prompt à coller dans ton agent

Corrige les trois failles Next.js publiées le 14 octobre 2026 (GHSA-2464-fhr4-w9xw, GHSA-673q-mjm6-r5xr, GHSA-p3m5-59mp-jv5r) dans ce projet.

1. Lis la version de la dépendance "next" dans package.json, puis :
   - 16.x → npm install next@16.4.1
   - 15.x → npm install next@15.5.28
   - 14.x ou plus ancien → aucune version corrigée n'existe sur cette branche. Installe next@15.5.28 (ou 16.4.1) et corrige les erreurs de build une par une, sans changer la logique métier. En attendant, applique le contournement du point 3.

2. Vérifie le résultat avant de continuer :
   - "npm ls next" doit renvoyer une seule version, >= 15.5.28 ou >= 16.4.1 ;
   - aucune copie de next en 16.4.0 ou moins ne doit rester dans l'arbre des dépendances.

3. Si le projet est coincé sur une version antérieure à 15.5.28, assure-toi que "npm ls sharp" renvoie >= 0.35.5. Ce contournement ne couvre que la faille de l'API Image Optimization (GHSA-2464-fhr4-w9xw), rien d'autre.

4. Lance "npm run build", puis liste les fichiers modifiés et tout changement de comportement observé. Ne modifie pas le code applicatif en dehors de ce qui est nécessaire pour que le build passe.

Les 8 jours où vos scanners sont restés muets

La chronologie, en UTC, se lit dans les sources primaires : les commits de correction, les notes de version de Next.js, et les trois avis.

• 8 octobre, 18:00 — Next.js annonce une sortie hors cycle pour le 14 octobre : trois failles dans des dépendances amont, deux critiques, une élevée. Deux correctifs avaient été repoussés depuis la release de septembre, à cause de dépendances en amont.
• 14 octobre, 15:27 — les commits de correction partent. L'un met à jour sharp sur les deux branches LTS, l'autre touche au protocole de transport des Server Components.
• 14 octobre, 17:47 — les versions 15.5.28 (17:47:49) et 16.4.1 (17:47:59) sont publiées. Leurs notes de version listent déjà les trois identifiants GHSA.
• 14 octobre, 18:00 — le billet de sécurité de Next.js détaille l'impact, les versions et les commandes d'installation.
• 22 octobre, 15:50:34 — premier avis (déni de service) dans la base GitHub révisée.
• 22 octobre, 15:52:53 — deuxième avis (RCE Image Optimization).
• 22 octobre, 16:42:31 — troisième avis (RCE use cache). La fenêtre de publication des trois avis dure 52 minutes.

Entre le commit de correction (14 octobre, 15:27) et le premier avis publié (22 octobre, 15:50), il s'est écoulé huit jours et 22 minutes. Entre la publication de la version corrigée (14 octobre, 17:47) et ce même avis : sept jours et 22 heures. Dans les deux cas, l'information technique existait — elle n'était simplement pas là où les outils regardent.

Ce n'est pas un détail de procédure, c'est le mécanisme qui décide si tu reçois une alerte. La documentation GitHub est explicite : Dependabot te notifie quand un avis revu par GitHub signale une vulnérabilité dans une dépendance de ton dépôt, et les avis non revus ne déclenchent aucun alert. Tant que ces trois entrées n'étaient pas dans la base, Dependabot n'avait rien à te signaler. L'API OSV, elle, ne les renvoyait pas non plus : leur date de publication y est le 22 octobre. Les outils qui s'appuient sur OSV — osv-scanner, Trivy, Grype et d'autres — étaient dans le même angle mort.

Résultat concret : pendant huit jours, une application en next 16.4.0 portait une exécution de code à distance notée 9,5 sur 10, et son tableau de bord de sécurité restait calme.

Pourquoi ce délai ? Publier un avis et l'ajouter à la base révisée ne sont pas la même étape. GitHub relit chaque avis avant de l'intégrer : description complète, écosystème, plages de versions. Sur une sortie hors cycle d'un framework aussi déployé que Next.js, cette relecture arrive après la publication, et l'écart se compte en jours.

Ce qu'il faut en retenir pour ton process : une source unique ne suffit pas. La base GitHub est excellente pour la couverture et lente sur les sorties d'urgence. Les notes de version du framework, elles, publient le jour même, avec les versions corrigées. Si ta surveillance ne regarde que les avis revus, tu as un angle mort de huit jours sur chaque release hors cycle. Ici, tu n'as pas eu besoin d'attendre l'alerte : le correctif existait depuis le 14 octobre.

Si tu veux voir comment ce type de dépendance vulnérable est traité côté outillage, la page des fonctionnalités détaille les contrôles et ce qu'ils renvoient. Et si tu es déjà passé par la faille du middleware Next.js de mars 2025, CVE-2025-29927 suit la même logique : le correctif arrive avant que l'écosystème n'ait les bons identifiants en base.

Questions fréquentes

Suis-je concerné si je suis en Next.js 15 ?

Deux des trois avis, oui. La RCE de l'API Image Optimization touche la 15.5.27 et en dessous, le déni de service touche la 13.0.0 à 15.5.27. La RCE use cache ne concerne que la 16.0.0 à 16.4.0. La version 15.5.28 corrige les deux qui te concernent.

Faut-il un numéro CVE pour être vulnérable ?

Non. GHSA-673q-mjm6-r5xr n'a aucun CVE associé dans la base GitHub, et c'est pourtant une exécution de code à distance critique notée 9,5. Un outil qui ne cherche que des identifiants CVE ne verra jamais cette faille. C'est aussi pourquoi le titre de cet article ne colle pas un CVE sur les trois avis : aucun des deux RCE ne porte d'identifiant CVE dans l'avis GitHub, seul le déni de service en a un (CVE-2026-94482).

CVE-2026-96889, c'est une faille Next.js ?

Pas exactement. Le billet de sécurité de Next.js associe ce CVE à l'avis GHSA-2464-fhr4-w9xw, mais le CVE lui-même décrit une faille de librsvg : un déréférencement après libération (use-after-free) quand un document SVG contient des inclusions XML imbriquées avec des entités dupliquées. Il a été publié le 23 septembre 2026 par Red Hat, avec un score CVSS 3.1 de 7,8. Next.js hérite du problème par sa chaîne de traitement d'images, qui passe par sharp. Ne cherche pas ce CVE sur l'avis use cache : il n'y figure pas.

Mettre à jour sharp suffit-il ?

Pour la seule RCE de l'API Image Optimization, oui, à condition que la version réellement résolue soit 0.35.5 ou plus. Ça ne couvre ni la RCE use cache, ni le déni de service. Pour ces deux-là, l'avis indique qu'il n'existe aucun contournement : la mise à jour de Next.js est la seule correction.

Pourquoi aucun scanner ne m'a alerté pendant huit jours ?

Parce qu'un avis publié et un avis revu ne sont pas la même entrée. Tant que GitHub n'a pas relu l'avis, il n'entre pas dans la base sur laquelle s'appuient Dependabot et les outils qui lisent OSV. Les trois horodatages du 22 octobre, entre 15:50 et 16:42 UTC, marquent la fin de cet angle mort, pas le début de la faille.

Sources

• Next.js Security Update for Upstream Vulnerabilities — 14 octobre 2026
• Upcoming Next.js Security Update for Upstream Vulnerabilities — 8 octobre 2026
• Release v16.4.1 — vercel/next.js
• Release v15.5.28 — vercel/next.js
• GitHub Security Advisory — GHSA-2464-fhr4-w9xw
• GitHub Security Advisory — GHSA-673q-mjm6-r5xr
• GitHub Security Advisory — GHSA-p3m5-59mp-jv5r
• CVE-2026-96889 — librsvg, use-after-free via Xincludes imbriqués
• CVE-2026-94482 — Next.js, déni de service dans l'App Router
• OSV — GHSA-2464-fhr4-w9xw, champ github_reviewed_at
• GitHub Docs — About the GitHub Advisory Database

Une app à jour sur ses dépendances peut fuir ailleurs. Le scan rapide regarde ton site comme le ferait un inconnu et te rend la preuve, requête à l'appui.