Next.js 16.3.6 : la faille de sécurité critique à corriger

Le 22 septembre 2026, Vercel a publié Next.js 16.3.6 (branche LTS active) et 15.5.26 (branche LTS de maintenance) pour corriger une faille critique dans une dépendance amont, référencée sous l'identifiant GHSA-vcvr-r3jv-pc5j. Vercel avait prévenu quelques jours à l'avance de la sortie d'un correctif de sécurité, sans en détailler la nature avant la publication, pratique habituelle pour éviter qu'un exploit ne circule avant que les sites concernés aient pu se mettre à jour sur Next.js 16.3.6.

Ce correctif est distinct de celui publié le 25 août 2026 (16.3.3 / 15.5.24), qui traitait deux RCE non authentifiées différentes : une faille dans l'optimisation d'images AVIF (libheif/sharp) et une traversée de chemin sur serveurs Windows (CVE-2026-75604). Deux CVE distinctes, deux cycles de mise à jour à traiter séparément : ce n'est pas la même faille qui revient avec Next.js 16.3.6, c'est une nouvelle.

Pourquoi cette mise à jour est prioritaire

Une faille qualifiée de critique dans l'écosystème Next.js touche potentiellement toute application qui n'a pas encore basculé sur la dernière version corrigée de sa branche. Contrairement à une faille métier propre à une application, celle-ci vient d'une dépendance partagée par un très grand nombre de projets. Le risque n'est donc pas hypothétique, il est mécanique : tout projet qui tourne encore sur une version antérieure à Next.js 16.3.6 (branche 16) ou 15.5.26 (branche 15) est exposé de la même façon que n'importe quel autre projet Next.js non patché.

Comment vérifier si un projet est concerné

• Vérifier la version installée avec npx next --version ou dans le package.json.
• Branche 16.x : mettre à jour vers Next.js 16.3.6 ou plus récent.
• Branche 15.x (LTS maintenance) : mettre à jour vers 15.5.26 ou plus récent.
• Toute version antérieure à ces deux seuils doit être considérée comme non corrigée.

Comment appliquer le correctif

La mise à jour vers Next.js 16.3.6 se fait comme une montée de version standard :

• npm install next@16.3.6 (ou la version équivalente pour la branche 15).
• Relancer les tests automatisés existants avant tout déploiement, une mise à jour de sécurité hors cycle n'étant pas toujours accompagnée d'un changelog détaillé sur les effets de bord.
• Redéployer rapidement plutôt que d'attendre le prochain cycle de release planifié.

Le bon réflexe pour la suite

Deux mises à jour de sécurité critiques en moins d'un mois sur Next.js, ça justifie de vérifier l'ensemble de son parc de projets plutôt qu'un seul site isolé. Pour un développeur freelance ou une petite structure qui maintient plusieurs projets clients sur ce framework, le plus efficace reste de dresser une liste rapide des versions en production et de traiter en priorité celles encore sur une base antérieure à août 2026.

Ce que ça change pour un parc de projets clients

Concrètement, migrer vers Next.js 16.3.6 sur un projet isolé prend rarement plus d'une heure : mise à jour de la dépendance, relance de la suite de tests, déploiement. Le vrai coût est organisationnel quand plusieurs projets clients tournent sur des versions différentes du framework. C'est le moment de documenter, pour chaque projet, la version exacte en production et la date de la dernière mise à jour de sécurité appliquée, plutôt que de le découvrir au prochain correctif hors cycle. Un accompagnement en développement web qui inclut ce suivi de version évite justement ce type de rattrapage dans l'urgence.

Sur le plan calendaire, la fenêtre entre la publication d'une faille critique et l'apparition des premiers exploits en circulation se compte souvent en jours, pas en semaines. Un projet resté sur une version antérieure à Next.js 16.3.6 plusieurs semaines après sa sortie s'expose donc à un risque qui augmente avec le temps, pas qui reste constant.