Failles Next.js d'octobre 2026

Le 14 octobre 2026, Vercel a publié Next.js 15.5.28 et 16.4.1. Derrière ces numéros de maintenance, trois avis de sécurité, dont deux notés 9,5 sur 10 : chacun permet d'exécuter du code sur le serveur qui héberge votre application, sans compte et sans interaction d'un utilisateur. Dix jours plus tard, des dépôts publics revendiquent des preuves de concept, et la semaine a été chargée pour tout le monde : PHP le 21, Node.js le même jour. Next.js était passé avant, plus discrètement.

Next.js fait tourner une part croissante des sites et des applications métier : vitrines, back-offices, SaaS. Mes propres produits en dépendent. Cet article explique ce que corrigent ces versions, comment savoir si vous êtes exposé, et le détail qui a piégé plus d'une équipe : mettre à jour Next.js ne suffit pas toujours à mettre à jour la bibliothèque fautive.

Les trois failles, en une phrase chacune

GHSA-673q-mjm6-r5xr, fonctions use cache (critique, 9,5). Une fonction marquée use cache qui renvoie plusieurs tableaux typés peut conduire à une exécution de code à distance. Concerne Next.js 16.0.0 à 16.4.0, avec l'App Router et les Cache Components. Corrigé dans 16.4.1. Aucun contournement : Vercel demande de mettre à jour même si votre application n'a aucune fonction de ce genre.
CVE-2026-96889, optimisation d'images et SVG (critique, 9,5). Une corruption mémoire dans une bibliothèque de rendu SVG utilisée par la chaîne d'optimisation d'images (next/image) peut mener à une exécution de code, sur les systèmes Linux à base de glibc. Concerne Next.js 10.0.0 à 15.5.27 et 16.0.0 à 16.4.0, soit à peu près toutes les versions en production depuis six ans. Corrigé dans 15.5.28 et 16.4.1.
CVE-2026-94482, Server Actions (élevée, 8,2). Des requêtes forgées font consommer un temps processeur excessif et bloquent les autres requêtes du même processus. Concerne les applications App Router qui déclarent au moins une Server Action, sur les mêmes plages de versions. Le Pages Router n'est pas touché.

Le point à retenir pour un dirigeant : les deux failles critiques sont dans le framework, pas dans votre code. Un site vitrine qui n'a jamais utilisé use cache et qui n'affiche que des photos JPEG reste concerné, parce que la faille se déclenche sur ce que le serveur accepte de traiter, pas sur ce que vous avez prévu de lui envoyer.

Qui est concerné

Tout Next.js auto-hébergé : conteneur Docker, VPS, Kubernetes, PaaS. C'est vous qui décidez de la version, donc vous qui corrigez.
Next.js hébergé chez Vercel : l'avis de Vercel ne détaille pas ce qui est pris en charge côté plateforme. Mettez à jour quand même : la version déployée est celle de votre package.json, et le déploiement suivant la reconstruit.
Les versions anciennes : les lignes 13 et 14 ne reçoivent pas de correctif. Un projet resté en Next.js 14 doit passer en 15.5.28 au minimum, ce qui est une montée de version majeure, à planifier mais pas à repousser.

Côté exploitation, la situation au 27 octobre : aucun des identifiants n'est dans le catalogue des failles exploitées de la CISA, les éditeurs ne rapportent pas d'attaque, mais la fiche NVD de la faille d'images porte une mention « preuve de concept » et des dépôts publics la revendiquent depuis le 23 octobre. L'historique récent de Next.js incite à ne pas attendre : la faille de contournement du middleware de mars 2025 avait vu des tentatives d'exploitation dans les jours qui ont suivi la publication de son code d'attaque.

Vérifier sa version, et surtout celle de sharp

Première vérification, la version de Next.js réellement installée. Pas celle du package.json, qui peut contenir une plage, mais celle du fichier de verrou et de l'image construite :

# version résolue dans le projet
npm ls next          # ou : pnpm ls next

# version embarquée dans l'image qui tourne en production
docker exec <conteneur> node -e "console.log(require('next/package.json').version)"

Seconde vérification, celle qui est passée sous les radars. La faille d'images vit dans une bibliothèque appelée par sharp, le module de traitement d'images que Next.js utilise. Le contournement officiel de Vercel consiste à s'assurer que sharp est en version 0.35.5 ou plus récente. Or la version 15.5.28 de Next.js accepte encore la ligne 0.34 de sharp : un projet qui met à jour Next.js sans toucher à sharp peut se retrouver avec un framework corrigé et une bibliothèque vulnérable. Vérifiez donc les deux :

npm ls sharp
docker exec <conteneur> node -e "console.log(require('sharp/package.json').version)"

Si sharp est absent de la liste, Next.js utilise son repli interne pour l'optimisation d'images, et c'est le correctif de Next.js qui compte. S'il est présent en 0.34 ou avant, forcez la mise à jour.

Corriger : dans cet ordre

Mettre à jour Next.js vers 15.5.28 ou 16.4.1 au minimum (16.4.2, du 23 octobre, apporte des corrections de bogues en plus). Sur la ligne 16, prenez la dernière 16.4.x. Sur la ligne 15, 15.5.28.
Mettre à jour sharp vers 0.35.5 ou plus. Si sharp est une dépendance directe, changez-la ; si elle est transitive, utilisez les overrides de npm ou pnpm pour l'imposer.
Reconstruire l'image Docker sans cache et redéployer. Une image construite avant la mise à jour embarque l'ancienne version, quelle que soit celle du dépôt.
Vérifier dans le conteneur en service, avec les deux commandes ci-dessus. C'est la seule preuve qui vaut.
Tester les parcours qui comptent : pages avec images, formulaires qui passent par une Server Action, connexion, paiement.

# Exemple avec pnpm, ligne 15
pnpm add [email protected] sharp@^0.35.5
pnpm ls next sharp
docker compose build --no-cache web && docker compose up -d web

Si vous ne pouvez pas mettre à jour aujourd'hui, deux mesures réduisent l'exposition sans la supprimer. Désactiver l'optimisation d'images (images.unoptimized: true dans next.config) coupe le chemin de la faille d'images, au prix d'images servies telles quelles. Et refuser au niveau du reverse proxy les requêtes vers /_next/image dont le paramètre url pointe vers un domaine qui n'est pas le vôtre limite ce que l'optimiseur acceptera de traiter. Rien de tout cela ne protège de la faille use cache, qui n'a pas de contournement.

Ce que cet épisode dit de votre maintenance

Trois leçons, les mêmes qu'avec PHP et Node.js la semaine suivante, mais avec une nuance propre à l'écosystème JavaScript :

Une dépendance n'est pas une version. Le framework que vous nommez tire des dizaines de bibliothèques que vous ne nommez pas. Le fichier de verrou et npm ls disent la vérité, le package.json ne dit qu'une intention.
L'image qui tourne est la seule qui compte. Corriger le dépôt sans reconstruire ni redéployer ne change rien pour l'attaquant.
Rester sur une ligne maintenue. Next.js 14 n'a pas reçu ces correctifs. Une montée de version majeure planifiée coûte quelques jours ; la même montée en urgence, un week-end et des régressions.

Ce que j'en retiens

Deux failles critiques dans Next.js lui-même : toute application en 10.x à 15.5.27 ou 16.0 à 16.4.0 est concernée, y compris un simple site vitrine.
La correction est 15.5.28 ou 16.4.1 au minimum, plus sharp 0.35.5 ou plus récent, suivie d'une reconstruction d'image et d'une vérification dans le conteneur.
Pas de contournement pour la faille use cache ; des mesures partielles seulement pour celle des images.
Des preuves de concept circulent depuis le 23 octobre : la fenêtre pour corriger tranquillement se referme.

Votre site ou votre application tourne sous Next.js et vous ne savez pas sur quelle version, ni qui s'occupe des mises à jour ? Je peux faire le point, appliquer les correctifs et mettre en place la maintenance qui évite la prochaine urgence. Décrivez-moi votre installation, je vous réponds rapidement.

Sources : avis de sécurité de Vercel du 14 octobre 2026 (GHSA-673q-mjm6-r5xr, CVE-2026-96889, CVE-2026-94482), fiche NVD de CVE-2026-96889, synthèses de Brandefense et de Codewares. Article à jour au 24 octobre 2026.

← Tous les articles