Next.js hors calendrier : la RCE des images SVG et trois vérifications

Si vous déployez une app Next.js, vérifiez sa version aujourd'hui. L'avis GitHub GHSA-2464-fhr4-w9xw, classé critique avec un score CVSS v4 de 9.5, décrit une exécution de code à distance sans authentification dans l'API Image Optimization, quand des fichiers SVG sont utilisés et que Next.js tourne sur un Linux à base de glibc. Aucun compte ni aucune interaction utilisateur ne sont nécessaires. Les versions corrigées sont 15.5.28 et 16.4.1. Beaucoup de freelances PHP et Node maintiennent un front Next.js à côté de leur backend : même si Next n'est pas votre stack principale, cela vaut dix minutes.

Ce que dit l'avis

D'après l'avis, un bug lié à la mémoire dans une bibliothèque en amont que Next.js utilise pour optimiser les images peut mener à une exécution de code à distance. Les versions touchées du paquet next vont de 10.0.0 à 15.5.27 et de 16.0.0 à 16.4.0. Le contournement, si vous ne pouvez pas mettre à jour tout de suite, consiste à s'assurer que la version de sharp utilisée par Next.js est 0.35.5 ou plus récente ; une installation neuve récupère un sharp corrigé, et passer Next.js à une version corrigée amène le gestionnaire de paquets à en tirer un. L'avis renvoie à la CVE-2026-96889 et crédite randomguy6407 et rafabd1.

Le tracker pwn.watch ajoute un contexte que je n'ai pas pu recouper moi-même avec les autres avis. Selon lui, Vercel a publié 16.4.1 et 15.5.28 le 14 octobre 2026 hors du calendrier habituel, le bug SVG est un use-after-free dans librsvg atteint via sharp, et la même publication corrige une seconde RCE critique (GHSA-673q-mjm6-r5xr, apps App Router avec Cache Components) ainsi qu'un déni de service de gravité élevée dans les Server Actions (GHSA-p3m5-59mp-jv5r). Hors calendrier signifie que l'éditeur a choisi de ne pas attendre le cycle normal. Prenez-le comme un signal d'urgence.

Pourquoi un parseur d'images peut exécuter du code

Ceci relève de la culture générale, pas d'un détail de l'avis. Dans Node, le traitement d'images est en général du code natif : sharp est une couche JavaScript au-dessus de bibliothèques C comme libvips et librsvg, qui tournent dans votre processus Node. Un bug mémoire à cet endroit n'est pas contenu par la sûreté de JavaScript ; c'est un bug de votre application, avec vos variables d'environnement et votre système de fichiers. Le SVG élargit la surface, parce que c'est un format de document avec un vrai parseur derrière, pas une grille de pixels.

L'avis cite Linux à base de glibc. Il ne dit pas que les autres plateformes sont sûres : si votre image est Alpine ou autre chose, mettez à jour quand même plutôt que de vous convaincre que vous êtes hors de cause.

Trois vérifications

npm ls next sharp
grep -n '"version"' node_modules/sharp/package.json
docker exec my-next-app id -u

Lancez les deux premières dans le projet et la troisième sur le conteneur en production, car le lockfile de votre portable et l'image en production peuvent ne pas être d'accord. Corrigez ensuite ce que les vérifications font apparaître :

npm install next@16.4.1   # or next@15.5.28 on the 15 line
npm ls sharp              # expect 0.35.5 or later
docker build --pull -t my-next-app .

Deux habitudes, comme bonne pratique générale et non comme exigence de l'avis : limitez ce que l'optimiseur peut récupérer avec images.remotePatterns dans votre config Next, pour qu'il ne traite que les images des hôtes que vous nommez, et faites tourner l'app avec un utilisateur non root dans son conteneur. Aucune des deux ne remplace la mise à jour. Prochaine étape : lancez les trois vérifications sur chaque app Next.js que vous déployez, y compris le projet client auquel vous n'avez pas touché depuis le printemps.

Source : GitHub Advisory Database, GHSA-2464-fhr4-w9xw.