Next.js : patcher les RCE critiques du 14 octobre 2026
Une mise à jour hors calendrier
Le 14 octobre 2026, Vercel publie une mise à jour de sécurité out-of-band pour Next.js. Elle était annoncée la semaine précédente. Deux des trois correctifs avaient été reportés depuis la release de septembre, à cause de dépendances upstream non prêtes.
Le message de l'équipe Next.js est sans ambiguïté : patcher dès maintenant, sans attendre le prochain cycle de maintenance.
Les versions à installer
| Ligne | Version corrigée | Statut |
|---|---|---|
| Next.js 16.x | 16.4.1 | Active LTS |
| Next.js 15.x | 15.5.28 | Maintenance LTS |
npm install next@16.4.1 # branche 16.4
npm install next@15.5.28 # branche 15.5
Si vous utilisez pnpm ou yarn, adaptez la commande. L'important est que le lockfile soit régénéré et committé, sinon le build de production reste sur l'ancienne version.
Les trois failles
1. RCE non authentifiée dans les fonctions use cache (critique)
Une application App Router qui utilise Cache Components peut être compromise quand une fonction use cache retourne plusieurs typed arrays. Le problème est lié à un avis upstream côté React (GHSA-xqc2-xf4c-x3h3).
Point d'attention : Vercel indique qu'il n'existe aucun workaround connu. Le conseil est de mettre à jour immédiatement, même si votre code ne contient pas de fonction de ce type.
2. RCE non authentifiée via l'API Image Optimization avec SVG (critique)
Une faille mémoire dans une bibliothèque upstream utilisée par Image Optimization peut mener à une exécution de code sur Next.js, lorsque l'application tourne sur Linux basé sur glibc. Référence : CVE-2026-96889 (GHSA-2464-fhr4-w9xw).
Le contournement documenté est de s'assurer que sharp est en version 0.35.5 ou supérieure. Une mise à jour de Next.js vers les versions corrigées fait que votre gestionnaire de paquets installe automatiquement une version corrigée de sharp.
3. Déni de service dans l'App Router via Server Actions (élevée)
Des requêtes forgées ciblant une application App Router disposant d'au moins une Server Action provoquent une consommation CPU excessive. Le processus est bloqué pour les requêtes suivantes. Le Pages Router et les applications sans Server Actions ne sont pas concernés (GHSA-p3m5-59mp-jv5r, avis React lié : GHSA-h3gv-c5rc-p453).
Checklist DevOps à dérouler aujourd'hui
- Inventorier :
npm ls next sharpsur chaque repo, en local et dans les images Docker de production. - Repérer les usages :
grep -rn "use cache" app/ src/pour savoir si la failleuse cachevous touche directement. - Mettre à jour :
next@16.4.1ounext@15.5.28, puis regénérer le lockfile. - Vérifier
sharp: version 0.35.5 minimum dans l'arbre de dépendances, y compris dans les images de build. - Rebuild sans cache : une image Docker ou un cache CI ancien peut conserver l'ancienne version. Forcez un build propre.
- Redéployer : passez par votre pipeline CI/CD habituel, pas par un patch manuel sur le serveur.
- Contrôler les logs : repérez les requêtes anormales vers les routes d'images ou les Server Actions, et les pics CPU inexpliqués sur la période précédant le déploiement.
Ce que ça change pour une équipe produit
Ce type d'incident rappelle qu'un framework n'est pas une boîte noire. Dans un pipeline industrialisé, la mise à jour d'une dépendance critique doit être un processus court et reproductible : détection, branche dédiée, tests, déploiement. C'est exactement ce qui sépare une équipe qui patche en une heure d'une équipe qui découvre la faille dans ses logs une semaine plus tard.
Pour aller plus loin, la documentation officielle de Next.js reste la référence : les avis complets sont publiés sur la page de l'annonce et sur les GitHub Security Advisories du projet.
