GHSA-2464-fhr4-w9xw (CVE-2026-96889) : RCE non authentifiée dans l'optimisation d'images Next.js

En bref

Vercel classe GHSA-2464-fhr4-w9xw comme critique (CVSS v4.0 9.5) : un attaquant non authentifié peut exécuter du code sur un serveur Next.js qui optimise des SVG sous Linux avec glibc. Installez Next.js 16.4.1 ou 15.5.28.

• L'API d'optimisation d'images intégrée à Next.js (/_next/image) transmet les octets d'images fournis par l'attaquant à sharp, dont les binaires libvips précompilés embarquent librsvg, le moteur de rendu SVG standard. Les versions de librsvg affectées sont toutes celles antérieures aux versions corrigées : versions de la branche principale avant 2.63.2 et versions stables avant les rétroportages 2.62.4, 2.61.5, 2.60.3 et 2.57.5, selon RUSTSEC-2026-0305. Ces versions libèrent une entité XML alors que libxml2 l'utilise encore : une utilisation après libération, publiée sous CVE-2026-96889.
• Toutes les versions de Next.js de 10.0.0 à 15.5.27 et de 16.0.0 à 16.4.0 sont affectées lorsqu'elles s'exécutent sur un système Linux basé sur glibc et que des fichiers SVG peuvent atteindre l'optimiseur. Vercel confirme l'existence d'une preuve de concept publique pour la faille librsvg.
• Aucune exploitation dans la nature n'est connue au 23 octobre 2026, et la vulnérabilité ne figure pas dans le catalogue Known Exploited Vulnerabilities de la CISA.
• Installez Next.js 16.4.1, ou 15.5.28 sur la branche 15.x. Sous Node.js 20.9.0 ou ultérieur, une nouvelle installation résout sharp 0.35.5 (librsvg 2.63.2). Sur 15.x, exécutez npm ls sharp après la mise à jour et installez sharp@0.35.5 si une version 0.34.x subsiste. L'avis de Vercel indique une mesure de contournement : s'assurer que sharp se résout en version 0.35.5 ou ultérieure.

Suis-je concerné ?

npm a enregistré 44 586 009 téléchargements de next pendant la semaine du 16-22 octobre 2026. Effectuez la vérification de deux minutes ci-dessous.

Vous êtes concerné si toutes ces conditions sont réunies :

• Next.js utilise une version comprise dans une plage affectée.
• Le serveur s'exécute sur un système Linux basé sur glibc, cas courant des déploiements Node.
• sharp se résout vers une version dont le librsvg embarqué n'est pas corrigé. Le tableau sharp et librsvg ci-dessous détaille chaque version.
• Du contenu SVG peut atteindre l'API d'optimisation d'images.

À partir de Next.js 15.0.0, next déclare sharp dans optionalDependencies : il s'installe donc par défaut. Next.js 12.3.0, 13.5.6 et 14.2.32 ne déclarent aucune dépendance sharp. Sur ces branches, l'optimiseur ne charge sharp que si votre projet l'installe et utilise sinon Squoosh.

La version résolue de sharp détermine la version de librsvg embarquée par votre serveur :

Vérifiez les versions installées :

# Next.js and sharp versions
npm ls next sharp

# Direct read of the installed versions
node -e "console.log('next', require('next/package.json').version)"
node -e "console.log('sharp', require('sharp/package.json').version)"

# Lock file check (lockfileVersion 2 and 3)
grep -n '"node_modules/next"' package-lock.json | head
grep -n '"node_modules/sharp"' package-lock.json | head
# lockfileVersion 1 keys packages by bare name
grep -n '"next": {' package-lock.json | head
grep -n '"sharp": {' package-lock.json | head

# Container image check
docker run --rm <your-image> node -e "console.log(require('next/package.json').version, require('sharp/package.json').version)"

Sharp 0.35.x déclare engines.node: >=20.9.0 : Node 18 se trouve donc hors de sa plage d'exécution prise en charge. Ce champ ne pousse pas npm à choisir une ancienne version compatible de sharp : sauf si engine-strict est activé, npm le traite comme indicatif et avertit de l'incompatibilité de l'environnement d'exécution.

• La plage de dépendance ^0.33.5 de Next.js 15.0.0 autorise sharp 0.33.5, qui embarque librsvg 2.58.93.
• La plage ^0.34.3 || ^0.35.5 de Next.js 15.5.28 autorise à la fois la branche 0.34.x non corrigée et 0.35.5 corrigée ; un fichier de verrouillage existant peut conserver 0.34.x.

Les versions 0.33.x et 0.34.x du tableau sharp/librsvg ne contiennent aucun librsvg corrigé.

Comment corriger le problème ?

Mettez Next.js à jour. Sous Node.js 20.9.0 ou ultérieur, une nouvelle résolution récupère sharp 0.35.5 (librsvg 2.63.2). Vérifiez deux exceptions :

• Sur la branche 15.x, la plage accepte toujours ^0.34.3, si bien qu'un fichier de verrouillage existant peut conserver une version 0.34.x non corrigée. Exécutez npm ls sharp après la mise à jour et installez explicitement sharp@0.35.5 s'il reste en 0.34.x.
• Les hôtes Node 18 utilisant la branche 15.x doivent passer à Node.js 20.9.0 ou ultérieur avant que le correctif soit effectif.

# Next.js 16 line
npm install next@16.4.1
# or: pnpm add next@16.4.1   |   yarn add next@16.4.1

# Next.js 15 line
npm install next@15.5.28

Si vous ne pouvez pas encore mettre Next.js à jour, forcez uniquement la mise à jour de sharp. Le contournement indiqué par l'avis consiste à s'assurer que la version de sharp utilisée par Next.js est 0.35.5 ou ultérieure. Cela nécessite Node.js 20.9.0 ou ultérieur, car 0.35.x est la seule branche sharp embarquant un librsvg corrigé.

npm install sharp@0.35.5

Cette installation ne change ce que Next.js charge que si sa propre plage sharp accepte 0.35.5. Next.js 15.5.27 déclare ^0.34.3 || ^0.35.4, qui l'accepte. Next.js 15.0.0 déclare ^0.33.5, qui ne l'accepte pas : sa version imbriquée 0.33.5 reste donc en place. Dans ce cas, forcez la résolution dans package.json et réinstallez :

{
  "overrides": { "sharp": "0.35.5" }
}

Utilisez pnpm.overrides avec pnpm et resolutions avec Yarn.

Limites du contournement : il ne remplace que librsvg embarqué. Il ne modifie pas le traitement des requêtes par l'optimiseur.

• Le correctif 16.4.1 exige sharp ^0.35.5, qui fournit librsvg 2.63.2 corrigé.
• Le correctif 15.5.28 conserve le plancher ^0.34.3 dans sa plage ^0.34.3 || ^0.35.5. Ce plancher n'apporte aucun correctif : les versions 0.34.x embarquent librsvg 2.60.0 à 2.61.2, toutes antérieures aux rétroportages 2.60.3 et 2.61.5.
• Sous Node 18, la mise à jour 15.x reste incomplète. Passez à Node.js 20.9.0 ou ultérieur pour exécuter sharp 0.35.5 dans un environnement pris en charge, puis vérifiez la version résolue de sharp.

Quelle est la cause profonde ?

Une utilisation après libération survient quand du code libère de la mémoire et continue à utiliser son pointeur. Dans librsvg, la bibliothèque Rust qui effectue le rendu des fichiers SVG en analysant leur XML avec libxml2, un XInclude imbriqué contenant des déclarations d'entités en double libère une structure xmlEntity encore détenue par l'analyse externe. XInclude est un mécanisme permettant à un document XML d'importer des nœuds d'un autre document. La fiche CVE-2026-96889 de Red Hat décrit cette séquence.

RUSTSEC-2026-0305 décrit la défaillance en quatre étapes :

1. Pendant l'expansion d'une entité interne, libxml2 analyse récursivement un document XInclude qui redéclare le même nom d'entité.
2. Les deux analyses partagent la table d'entités XmlState de librsvg. L'ajout du doublon remplace l'entrée d'origine.
3. La destruction de la structure xmlEntity remplacée appelle xmlFreeNode(), libérant sa mémoire.
4. L'appel externe xmlCtxtParseEntity() continue à accéder à cette structure libérée de 144 octets.

En une phrase : la table d'entités pouvait remplacer une entrée sans vérifier si libxml2 en conservait un pointeur ; un document qui redéclare un nom d'entité à travers une frontière XInclude transforme donc un pointeur interne de l'analyseur en pointeur pendant.

C'est le contrôle de durée de vie manquant, et c'est ce que le correctif amont élimine. Le commit librsvg 8a1b0cd319e9af2d1e9cf878081dd77f227a0504 cesse de libérer les pointeurs xmlEntity encore utilisés par libxml2. Le correctif a d'abord été livré dans librsvg 2.63.2, avec des rétroportages vers 2.62.4, 2.61.5, 2.60.3 et 2.57.5, et a été rendu public le 23 septembre 2026.

Next.js atteint ce code via l'optimisation d'images. Le point de terminaison /_next/image accepte un paramètre url, le contrôle par rapport aux listes d'autorisation configurées (images.domains dans les anciennes branches, images.localPatterns et images.remotePatterns dans les plus récentes), récupère les octets et les transmet à sharp, qui charge l'image via libvips. L'optimiseur de Next.js 16.4.0 active explicitement le chargeur SVG de libvips à cette fin, dans packages/next/src/server/image-optimizer/transform.ts :

// packages/next/src/server/image-optimizer/transform.ts (v16.4.0)
export function getSharp(concurrency, operationCache) {
  ...
  _sharp.block({ operation: ['VipsForeignLoad'] })
  _sharp.unblock({
    operation: [
      'VipsForeignLoadHeif',   // avif
      'VipsForeignLoadJpeg',
      'VipsForeignLoadNsgif',
      'VipsForeignLoadPng',
      'VipsForeignLoadSvg',    // librsvg parses SVG bytes here
      ...
    ],
  })

Lorsque libvips identifie l'entrée comme un SVG, VipsForeignLoadSvg transmet le document à librsvg, et la faille de table d'entités devient accessible depuis les octets de la requête. Le même déblocage de VipsForeignLoadSvg existe dans l'optimiseur 15.5.x. Dans les anciennes versions affectées, le cheminement diffère : Next.js 14.2.x, par exemple, transmet directement à sharp tout tampon qu'il ne peut pas identifier par ses octets magiques, pour détecter son format, dans packages/next/src/server/image-optimizer.ts (v14.2.32) :

// Fallback to sharp if available
if (sharp) {
  const meta = await sharp(buffer)
    .metadata()
    .catch((_) => null)
  switch (meta?.format) {
    ...
    case 'svg':
      return SVG

Remarquez l'ordre dans cette version : sharp(buffer).metadata() analyse le fichier avant l'exécution du contrôle dangerouslyAllowSVG de l'optimiseur. Sur ce chemin de code, la garde SVG n'empêche donc pas l'analyse, seulement le renvoi de l'image.

Comment la faille est-elle exploitée ?

Il n'existe pas d'exploit public de bout en bout contre Next.js. Pour la faille librsvg elle-même, un reproducer public existe : l'entrée du suivi GitLab de GNOME est marquée comme contenant du matériel d'exploitation, et la fiche vulnrichment de la CISA pour CVE-2026-96889 indique une exploitation « poc » et un impact technique « total ». Nous ne le reproduisons pas ici ; les étapes ci-dessous décrivent le chemin publié sans code d'exploitation.

1. L'attaquant crée un SVG contenant un XInclude d'un second document, où ce second document déclare une entité XML portant le même nom qu'une entité déjà déclarée dans le document externe.
2. L'attaquant place ce SVG là où l'optimiseur cible peut le récupérer : un chemin local ou un hôte distant qui passe la liste d'autorisation images de l'application.
3. L'attaquant le demande via le point de terminaison d'optimisation d'images, avec une largeur figurant dans les deviceSizes ou imageSizes configurés de l'application et une qualité dans la plage autorisée, par exemple GET /_next/image?url=https%3A%2F%2Fcdn.attacker.example%2Favatar.svg&w=640&q=75.
4. L'optimiseur récupère les octets et les transmet à sharp. Libvips identifie le document comme un SVG et librsvg l'analyse.
5. Pendant l'expansion des entités, le XInclude imbriqué redéclare l'entité. La table remplace l'ancienne entrée et la libère, tandis que l'analyse externe en conserve un pointeur.
6. L'analyseur externe lit la structure xmlEntity libérée de 144 octets : une utilisation après libération. Sur un tas glibc, un attaquant qui contrôle le contenu libéré et la séquence d'allocations peut transformer cela en exécution de code arbitraire dans le processus serveur Node.js.

L'avis limite la RCE à Linux basé sur glibc, car les binaires sharp précompilés installés par Next.js sont des builds glibc ; les builds musl sont des paquets distincts.

Comment l'exploit traverse-t-il l'optimiseur ?

Le contrôle manquant correspond au nœud E du schéma : rien ne vérifie que l'entité n'est plus utilisée avant de la libérer.

Que peut faire un attaquant ?

Une exploitation réussie exécute du code arbitraire avec les privilèges du processus serveur Next.js, généralement le processus Node.js qui sert l'application. Cela donne accès à tout ce que ce processus peut atteindre : variables d'environnement et identifiants de déploiement, services internes, bases de données, ainsi qu'à la modification des réponses envoyées aux utilisateurs. Une exploitation ratée ou partielle peut également faire planter le processus, car le pointeur pendant est déréférencé, que l'attaquant gagne ou non la course de l'allocateur.

Les conditions nécessaires à l'attaquant :

• Aucune authentification ni interaction utilisateur, selon le vecteur CVSS v4.0 AV:N/AC:L/AT:P/PR:N/UI:N (réseau, faible complexité, aucun privilège, aucune interaction utilisateur ; conditions d'attaque présentes).
• Le serveur s'exécute sur un système Linux basé sur glibc.
• sharp se résout vers une version dont librsvg embarqué n'est pas corrigé (0.35.4 embarque librsvg 2.62.91 ; 0.34.x embarque 2.60.0, 2.61.1 ou 2.61.2 ; 0.33.5 embarque 2.58.93).
• Des octets SVG peuvent atteindre l'optimiseur : l'attaquant a besoin d'une URL source qui passe la liste de motifs autorisés images de l'application. Dans Next.js 14.2.x, l'analyse SVG précède le contrôle dangerouslyAllowSVG ; ce paramètre ne contrôle donc que la réponse, pas l'analyse vulnérable.
• Une combinaison de largeur et de qualité acceptée par l'application.

Pourquoi le correctif fonctionne-t-il ?

Vercel a corrigé le problème en mettant à jour librsvg embarqué via la dépendance sharp, sans modifier le traitement des requêtes. Le commit de correction 16.x (9571ec8) relève l'exigence sharp dans packages/next/package.json :

   "optionalDependencies": {
-    "sharp": "^0.35.4"
+    "sharp": "^0.35.5"
   }

Le commit de correction 15.x (5e3b687) fait de même pour sa plage : "sharp": "^0.34.3 || ^0.35.4" devient "^0.34.3 || ^0.35.5". Sharp 0.35.5 remplace les paquets libvips précompilés @img/sharp-libvips-* 1.3.3 par 1.3.4. La version 1.3.4 embarque rsvg 2.63.2 (selon ses notes de version), première version corrigée de la branche principale selon RustSec, qui contient le commit amont 8a1b0cd3. Ce commit cesse de libérer les pointeurs xmlEntity encore utilisés par libxml2. La faille supprimée, le document à XInclude imbriqué ne produit plus de référence pendante : ni le plantage ni le chemin d'exécution de code ne subsistent.

Le correctif est-il complet ? Pour le chemin utilisant les binaires embarqués, oui : librsvg corrigé supprime la cause profonde, et les plages de versions de l'avis correspondent au changement de dépendance. Deux réserves subsistent :

• Versions sharp verrouillées. Verrouiller sharp sous 0.35.5, y compris sur n'importe quelle version 0.34.x, conserve un librsvg vulnérable même avec un Next.js corrigé. C'est pourquoi l'avis formule le contournement en termes de version sharp.
• Une RCE « possible » reste une exposition. L'avis qualifie la RCE de « possible », car l'exploitation d'une utilisation après libération dépend du comportement de l'allocateur. Considérez chaque déploiement affecté comme exposé plutôt que de trier selon la probabilité.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission n'a été publié pour cette vulnérabilité. En l'absence de recommandations publiques, recherchez ces signaux généraux autour du point de terminaison d'images :

• Des requêtes vers /_next/image dont les paramètres url pointent vers des hôtes ou chemins inattendus, en particulier ceux qui se sont avérés servir du contenu SVG.
• Des rafales de réponses HTTP 400 de l'optimiseur, qui rejette le contenu SVG lorsque dangerouslyAllowSVG est désactivé ; le trafic de reconnaissance peut laisser cette trace.
• Des plantages ou redémarrages du processus Node.js corrélés à l'optimisation d'images, puisque le même défaut peut faire planter l'analyseur au lieu de donner le contrôle à l'attaquant.
• Des erreurs sharp dans les journaux, comme « Input buffer contains unsupported image format », que l'optimiseur journalise lorsqu'un chargement échoue en cours de route.

Si vous trouvez une activité suspecte, renouvelez tous les identifiants accessibles au processus serveur, car une exécution de code dans ce processus peut les lire.

Chronologie

• 23 septembre 2026 : Rafael B. Dias signale l'utilisation après libération de librsvg à Red Hat. Elle est divulguée le même jour avec RUSTSEC-2026-0305 et CVE-2026-96889.
• 25 septembre 2026 : l'enrichissement ADP vulnrichment de la CISA pour CVE-2026-96889 enregistre une preuve de concept publique (« Exploitation: poc », impact technique « total »).
• 27 septembre 2026 : sharp-libvips 1.3.4 est livré avec librsvg 2.63.2, et sharp 0.35.5 est publié avec cette version.
• 14 octobre 2026 : Vercel publie GHSA-2464-fhr4-w9xw et les versions Next.js 15.5.28 et 16.4.1 intégrant la mise à jour de sharp.
• 22 octobre 2026 : l'avis est publié et examiné dans la GitHub Advisory Database.
• 23 octobre 2026 : publication de cet article. Aucune exploitation dans la nature n'est connue ; la vulnérabilité ne figure pas dans le catalogue KEV de la CISA.

FAQ

Mon application est-elle exposée avec la configuration Next.js par défaut ? L'API d'optimisation d'images est activée par défaut pour les applications utilisant next/image avec le chargeur par défaut. La possibilité pour du contenu SVG d'atteindre sharp dépend du chemin de détection de votre version et de votre configuration images. Effectuez la mise à jour quelle que soit la configuration.

Sharp est-il installé chez moi ? À partir de 15.0.0, Next.js déclare sharp dans ses dépendances facultatives : un npm install normal sur une plateforme prise en charge l'inclut donc. Les versions antérieures à 15.0.0 que nous avons vérifiées (12.3.0, 13.5.6, 14.2.32) ne le font pas ; sharp n'est alors présent que si votre projet l'installe. Exécutez npm ls sharp. Un résultat 0.35.5 ou ultérieur contient librsvg 2.63.2 corrigé. Un résultat 0.34.x ne le contient pas : ces versions embarquent 2.60.0, 2.61.1 ou 2.61.2, toutes antérieures aux rétroportages 2.60.3 et 2.61.5.

Existe-t-il une CVE pour l'avis Next.js lui-même ? Au 23 octobre 2026, l'avis GitHub GHSA-2464-fhr4-w9xw n'a pas de CVE propre. La faille librsvg sous-jacente est CVE-2026-96889, identifiant sous lequel NVD et les distributions Linux la suivent.

Mon application ne sert que des PNG et JPEG. Dois-je m'inquiéter ? L'avis limite la faille aux fichiers SVG utilisés dans l'optimisation d'images. Une application dont les listes d'autorisation ne peuvent pas être amenées à servir des SVG à l'optimiseur se trouve hors du chemin décrit. La mesure sûre reste la mise à jour en une ligne.

Alpine Linux (musl) me protège-t-il ? L'avis limite la RCE à Linux basé sur glibc. Les binaires musl précompilés sont des paquets distincts, et l'avis ne se prononce pas sur eux. Ne considérez pas cette différence de plateforme comme un correctif ; mettez quand même sharp et Next.js à jour.

Cette faille est-elle exploitée ? Aucune exploitation dans la nature n'est connue au 23 octobre 2026, et la vulnérabilité ne figure pas dans le catalogue KEV de la CISA. Une preuve de concept publique de la faille librsvg existe : supposez donc l'intérêt d'attaquants opportunistes et appliquez le correctif en conséquence.

Analysez vos dépôts Next.js avec l'analyse de code source Ostorlab, puis utilisez les contrôles de version ci-dessus pour vérifier les versions de Next.js et sharp installées dans chaque déploiement.

Références

• Avis Vercel GHSA-2464-fhr4-w9xw : https://github.com/vercel/next.js/security/advisories/GHSA-2464-fhr4-w9xw (consulté le 23 octobre 2026 ; crédite les découvreurs randomguy6407 et rafabd1, vérifié le 27 octobre 2026)
• Entrée GitHub Advisory Database : https://github.com/advisories/GHSA-2464-fhr4-w9xw (consulté le 23 octobre 2026)
• Fiche CVE-2026-96889 (CNA Red Hat) : https://cveawg.mitre.org/api/cve/CVE-2026-96889 (consulté le 23 octobre 2026)
• Avis RustSec RUSTSEC-2026-0305 (matrice des versions corrigées revérifiée le 24 octobre 2026) : https://rustsec.org/advisories/RUSTSEC-2026-0305.html
• Entrée du suivi librsvg (élément #1241), qui référence le commit de correction 8a1b0cd319e9af2d1e9cf878081dd77f227a0504 : https://gitlab.gnome.org/GNOME/librsvg/-/work_items/1241 (consulté le 23 octobre 2026)
• Commit de correction Next.js 16.x (mise à jour de sharp) : https://github.com/vercel/next.js/commit/9571ec899f063df6533351bec390ccb2cc0af6a3 (consulté le 23 octobre 2026)
• Commit de correction Next.js 15.x (mise à jour de sharp) : https://github.com/vercel/next.js/commit/5e3b687b5edb868b064bdc058d768a7021e7f6ad (consulté le 23 octobre 2026)
• Notes de version Next.js 16.4.1 : https://github.com/vercel/next.js/releases/tag/v16.4.1 (consulté le 23 octobre 2026)
• Notes de version sharp 0.35.5 : https://github.com/lovell/sharp/releases/tag/v0.35.5 (consulté le 23 octobre 2026)
• Métadonnées du paquet sharp 0.35.5 (verrouillage @img/sharp-libvips-* 1.3.4, moteur Node >=20.9.0) : https://raw.githubusercontent.com/lovell/sharp/v0.35.5/package.json (consulté le 27 octobre 2026)
• Métadonnées du paquet sharp 0.33.5 (verrouillage @img/sharp-libvips-* 1.0.4) : https://raw.githubusercontent.com/lovell/sharp/v0.33.5/package.json (consulté le 27 octobre 2026)
• Paquet publié @img/sharp-libvips-linux-x64 1.0.4, versions.json (rsvg 2.58.93) : https://registry.npmjs.org/@img/sharp-libvips-linux-x64/-/sharp-libvips-linux-x64-1.0.4.tgz (consulté le 27 octobre 2026)
• Métadonnées du paquet Next.js, étiquettes v14.2.32 (aucune dépendance sharp) et v15.0.0 ("sharp": "^0.33.5") : https://github.com/vercel/next.js/blob/v14.2.32/packages/next/package.json et https://github.com/vercel/next.js/blob/v15.0.0/packages/next/package.json (consulté le 27 octobre 2026)
• Métadonnées du paquet sharp 0.34.3 (verrouillage @img/sharp-libvips-* 1.2.0, plage du moteur Node) : https://raw.githubusercontent.com/lovell/sharp/v0.34.3/package.json (consulté le 24 octobre 2026)
• Versions de compilation sharp-libvips 1.2.0 (rsvg 2.60.0) : https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.0/versions.properties (consulté le 24 octobre 2026)
• Versions de compilation sharp-libvips 1.2.3 (rsvg 2.61.1) : https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.3/versions.properties (consulté le 24 octobre 2026)
• Versions de compilation sharp-libvips 1.2.4 (rsvg 2.61.2) : https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.4/versions.properties (consulté le 24 octobre 2026)
• Notes de version sharp-libvips 1.3.4 (rsvg 2.63.2) : https://github.com/lovell/sharp-libvips/releases/tag/v1.3.4 (consulté le 23 octobre 2026)
• Notes de version sharp-libvips 1.3.3 (rsvg 2.62.91) : https://github.com/lovell/sharp-libvips/releases/tag/v1.3.3 (consulté le 23 octobre 2026)
• Source de l'optimiseur Next.js, étiquette v16.4.0 : https://github.com/vercel/next.js/blob/v16.4.0/packages/next/src/server/image-optimizer/transform.ts (consulté le 23 octobre 2026)
• Source de l'optimiseur Next.js, étiquette v14.2.32 : https://github.com/vercel/next.js/blob/v14.2.32/packages/next/src/server/image-optimizer.ts (consulté le 23 octobre 2026)
• Nombre de téléchargements npm de next (44 586 009 téléchargements, semaine du 16-22 octobre 2026) : https://api.npmjs.org/downloads/point/last-week/next (consulté le 24 octobre 2026)
• Documentation des métadonnées de paquets npm (engines est indicatif sauf si engine-strict est défini) : https://docs.npmjs.com/cli/v11/configuring-npm/package-json/#engines (consulté le 28 octobre 2026)