Next.js 16.4.1 et 15.5.28 : corriger les failles RCE

Ce qui a été publié le 14 octobre

Ce qu'il faut retenir

• GHSA-673q-mjm6-r5xr (critique) — exécution de code à distance sans authentification dans une application App Router avec Cache Components, lorsqu'une fonction use cache retourne plusieurs tableaux typés. Aucun contournement connu. L'avis donne la plage 16.0.0 à 16.4.0 et un score CVSS de 9.5.
• CVE-2026-96889 / GHSA-2464-fhr4-w9xw (critique) — exécution de code à distance par une bibliothèque amont de l'API d'optimisation d'images, lorsque des fichiers SVG sont utilisés, sur un Linux à base de glibc. Score de 9.5. Parade officielle : sharp 0.35.5 ou supérieur.
• GHSA-p3m5-59mp-jv5r (haute) — déni de service dans une application App Router qui compte au moins une Server Action : des requêtes forgées saturent le processeur et bloquent les requêtes suivantes du même processus. Score de 8.2. Le Pages Router, ou l'absence de Server Action, n'est pas concerné.
• Versions corrigées — 16.4.1 pour la ligne 16 et 15.5.28 pour la ligne 15, avec les commandes officielles npm install [email protected] et npm install [email protected].
• Pas de CVE pour deux avis sur trois — seul le RCE d'image porte un identifiant CVE. Les deux autres se suivent par leur identifiant GHSA : un outil qui ne cherche que des CVE les manquera.
• Même sans usage direct — pour le RCE use cache, Vercel demande de mettre à jour même si l'application ne contient pas de fonction similaire.

Sans use cache ni SVG, pourquoi ça ne suffit pas

Quelle version installer selon votre ligne

Faites défiler le tableau

Savoir ce qui tourne réellement

Inventorier en cinq contrôles

1. 01

   Lire les versions de Next.js et de sharp

   Depuis la racine du projet : npm ls next sharp, ou pnpm why sharp avec pnpm. Pour la version exacte de Next.js : node -p "require('next/package.json').version". Un sharp inférieur à 0.35.5 sous next est à corriger.

2. 02

   Repérer Cache Components et use cache

   grep -rn "cacheComponents" next.config.* puis grep -rln "use cache" app src. Si cacheComponents n'apparaît pas, votre application n'emprunte pas le chemin décrit par l'avis. Mettez à jour quand même : Vercel le demande dans tous les cas.

3. 03

   Repérer l'usage des SVG

   grep -rn "dangerouslyAllowSVG\|remotePatterns" next.config.* et find public -name "*.svg". Par défaut, la documentation indique que Next.js n'optimise pas les SVG, et que dangerouslyAllowSVG les autorise. L'absence de ce réglage est un bon signe, pas une preuve : l'avis ne détaille pas le chemin exact.

4. 04

   Repérer les Server Actions

   grep -rln "use server" app src. Un seul fichier suffit à rendre une application App Router concernée par le déni de service.

5. 05

   Reconnaître la bibliothèque C du système

   ldd --version affiche GNU libc sur Debian, Ubuntu, AlmaLinux ou Rocky, et musl libc sur Alpine. L'avis ne parle que de glibc et ne dit rien de musl : n'en déduisez pas que Alpine est épargné. Dans un conteneur : docker exec <conteneur> ldd --version.

Mettre à jour, puis contrôler le lockfile

Redéployer selon votre cible

1. 06

   Valider le build

   npm ci, puis npm run build, puis npm ls next sharp. Si le build échoue sur Node, vérifiez la version exigée par la ligne choisie.

2. 07

   PM2

   Construisez dans le répertoire que PM2 exécute, puis pm2 reload <nom>. Contrôlez ensuite avec pm2 describe <nom> que le répertoire d'exécution est bien celui que vous venez de reconstruire : avec un schéma de releases, un lien symbolique oublié relance l'ancien code.

3. 08

   Docker

   Reconstruisez sans cache : docker build --no-cache -t monapp:corrige ., ou invalidez au moins la couche npm ci. Relancez avec docker compose up -d --force-recreate. Comparez ensuite l'image du conteneur en cours (docker inspect -f '{{.Image}}' <conteneur>) à celle que vous venez de construire.

4. 09

   Coolify

   Déclenchez un redéploiement qui ignore le cache de build, puis lisez le journal : l'étape d'installation des dépendances doit s'exécuter, pas être marquée comme réutilisée. Un simple redémarrage ne reconstruit rien.

5. 10

   Prouver le correctif

   Lisez la version dans le processus en cours, pas dans le dépôt : docker exec <conteneur> node -p "require('next/package.json').version" doit afficher 16.4.1 ou 15.5.28 (ou une version plus récente de la même ligne). Contrôlez sharp avec docker exec <conteneur> grep '"version"' node_modules/sharp/package.json, qui doit afficher 0.35.5 ou supérieur.

Si vous ne pouvez pas redéployer aujourd'hui

Atténuations provisoires, pas des correctifs

• Relever sharp seul — c'est la parade officielle du RCE d'image : sharp 0.35.5 ou supérieur. Contrôlez que le build passe et que l'optimisation d'images fonctionne.
• Ne pas servir de SVG par l'optimiseur — laissez dangerouslyAllowSVG désactivé et ne l'activez pas sans besoin avéré.
• Restreindre images.remotePatterns — limitez les sources distantes que l'optimiseur accepte aux hôtes que vous maîtrisez.
• Node en exécutable PIE — l'avis de sharp cite ce mode pour réduire le risque d'exécution de code, en précisant que les binaires officiels de Node.js ne sont pas PIE.
• Réduire les dégâts possibles — processus sans droits root, conteneur en lecture seule (docker run --read-only), aucun secret inutile dans l'environnement.
• Limiter le débit devant Next.js — une règle limit_req dans nginx et une alerte sur le processeur ralentissent un déni de service, sans l'empêcher.

Après le correctif : surveiller et planifier la ligne 15

La documentation officielle