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

Suis-je concerné ?

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

Ce que ça donne selon ta situation :

• 16.4.0 ou en dessous, branche 16 : les trois te concernent. La RCE use cache demande 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 sans ce cas de figure dans ton code.
• 15.5.27 ou en dessous, branche 13 à 15 : 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.
• 12.x et en dessous : seule la RCE de l'API Image Optimization s'applique, elle démarre à la 10.0.0. Le déni de service 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 celle-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 ce qui traîne dans 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. 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.

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

npm run build

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

Une précision qui compte : aucune version corrigée n'existe dans les branches 10 à 14. Les seules versions qui ferment ces failles sont 15.5.28 et 16.4.1. Si tu es 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 dans 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ù tes scanners sont restés muets

Le 8 octobre, Next.js avait prévenu qu'un correctif hors cycle arrivait, avec deux rustines repoussées depuis la release de septembre à cause de dépendances en amont. Le 14 octobre, les versions sont sorties et GitHub a publié les trois avis ce jour-là : chaque page GHSA affiche « Published 2026-10-14 ».

Pendant huit jours, ces trois avis n'ont pas existé là où la plupart des outils regardent. Le champ github_reviewed_at des entrées OSV donne l'heure exacte d'entrée dans la base GitHub révisée :

À titre de comparaison, sur la faille du middleware de mars 2025 (CVE-2025-29927), les deux horodatages OSV sont identiques : l'avis est entré dans la base révisée le 21 mars 2025 à 15:20:12 UTC, au moment de sa publication. Aucun décalage. Ici, huit jours.

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 : tu es notifié quand un avis revu par GitHub signale une vulnérabilité dans une dépendance de ton dépôt. Un avis non revu ne déclenche pas d'alerte Dependabot. Entre le 14 et le 22 octobre, Dependabot n'avait donc rien à te signaler. L'API OSV ne renvoyait pas ces entrées non plus : les trois portent une date de publication au 22 octobre.

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 un tel écart d'un avis à l'autre ? Publier un avis et l'ajouter à la base révisée sont deux étapes distinctes, et la seconde n'a pas de délai garanti. GitHub relit chaque avis avant de l'intégrer : description complète, écosystème, plages de versions. En mars 2025, l'entrée revue existait dès la publication. En octobre 2026, elle est arrivée huit jours après. C'est précisément cette variabilité qui rend une surveillance mono-source fragile : tu ne sais pas à l'avance combien de temps durera le trou.

Ce qu'il faut en retenir : une source unique ne suffit pas. La base GitHub est excellente pour la couverture et lente sur les sorties d'urgence. Le blog sécurité du framework, lui, publie le jour même, avec les versions corrigées. Si ton process ne surveille 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 Rustine traite ce genre de dépendance vulnérable, la page des fonctionnalités détaille les contrôles et ce qu'ils renvoient.

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. Un outil qui ne cherche que des identifiants CVE ne verra jamais cette faille. C'est aussi la raison pour laquelle le titre de cet article ne colle pas un CVE sur les trois avis : un seul des deux RCE en a un.

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

Pas exactement. L'avis Next.js renvoie à ce CVE, mais NVD le décrit comme une faille de librsvg : un déréférencement après libération (use-after-free) lors du traitement d'un SVG contenant des entités XML dupliquées, publiée le 23 septembre 2026 et encore au statut « Awaiting Analysis » le 22 octobre. Next.js hérite du problème par sa chaîne de traitement d'images. 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 que l'avis publié et l'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 la plupart des 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
• GitHub Security Advisory — GHSA-2464-fhr4-w9xw
• GitHub Security Advisory — GHSA-673q-mjm6-r5xr
• GitHub Security Advisory — GHSA-p3m5-59mp-jv5r
• NVD — CVE-2026-94482
• NVD — CVE-2026-96889
• OSV — GHSA-2464-fhr4-w9xw, champ github_reviewed_at
• GitHub Docs — About the GitHub Advisory Database

Une app en 16.4.0 n'a pas besoin d'une alerte pour être corrigée. Le scanner de Rustine relève la version de tes dépendances et te dit lesquelles sont touchées, avec le correctif à coller dans ton agent.