Next.js ha publicado una actualización de seguridad fuera de ciclo el 14 de octubre que corrige dos vulnerabilidades críticas que permiten la ejecución remota de código sin autenticación, junto con un fallo de denegación de servicio de alta gravedad.
Uno de los fallos de ejecución de código se encuentra en React Server Components, y el otro en librsvg, la librería de código abierto que Next.js utiliza a través del paquete sharp para procesar imágenes SVG.
Las correcciones están en Next.js 16.4.1 y 15.5.28, las versiones actuales de soporte a largo plazo (LTS) activa y de mantenimiento.
Qué se ha corregido
La actualización cubre tres problemas distintos. Vercel, la empresa que desarrolla Next.js, calificó ambos fallos de ejecución de código como críticos, cada uno con una puntuación CVSS de 9.5. La tabla lista las versiones afectadas por cada problema y la versión que lo corrige.
Quién está afectado
El primer fallo de ejecución de código está en React Server Components, la característica de React que ejecuta componentes de interfaz de usuario en el servidor. El aviso de React abarca tres paquetes: react-server-dom-webpack, react-server-dom-parcel y react-server-dom-turbopack, en versiones 19.0.0 hasta 19.3.0. Describe el fallo como algo que afecta a "casos extremadamente raros en los que las respuestas transportan múltiples arrays tipados y un valor controlado por el atacante".
En una aplicación Next.js, el desencadenante es una función use cache que devuelve más de un array tipado, por lo que solo las aplicaciones de la versión 16 que habilitan Cache Components, la característica detrás de use cache, están expuestas. Vercel recomienda actualizar incluso si tu aplicación no tiene dicha función.
El segundo fallo es un error de memoria en librsvg, la librería que renderiza imágenes SVG, a la que Next.js accede a través del paquete sharp incluido. La ejecución de código es posible cuando Next.js se ejecuta en Linux con glibc, según el aviso.
Por defecto, Next.js no optimiza archivos SVG. Servirlos a través del optimizador de imágenes requiere activar una configuración llamada dangerouslyAllowSVG. La misma librería también renderiza imágenes para next/og, la característica que genera imágenes de vista previa para redes sociales, cuando se ejecuta en el entorno de Node.js.
El tercer fallo es un problema de denegación de servicio. En aplicaciones con App Router que definen al menos una Server Action, las solicitudes manipuladas pueden llevar un proceso del servidor al uso completo de CPU y detener su capacidad de manejar otras solicitudes. Las aplicaciones con Pages Router, o sin Server Actions, no se ven afectadas.
La exposición puede variar según el proveedor. Netlify afirmó que su plataforma no ejecuta la ruta de código del optimizador de imágenes y que los fallos tienen un impacto limitado en su configuración, aunque recomienda la actualización.
Qué hacer
Actualiza a Next.js 16.4.1 si usas la versión 16, o a 15.5.28 si usas la versión 15, luego reconstruye y vuelve a desplegar.
El aviso de Vercel indica que actualizar Next.js hace que los gestores de paquetes proporcionen automáticamente el sharp corregido. En la versión 16 esto se cumple, porque 16.4.1 requiere sharp 0.35.5.
En la versión 15 puede que no. 15.5.28 todavía acepta la versión anterior afectada, sharp 0.34.x, y actualizar sobre una instalación existente puede dejar esa versión en su lugar. Verifica con npm ls sharp y actualiza sharp a 0.35.5 o posterior si es más antigua.
Si no puedes actualizar Next.js de inmediato, el fallo de imagen tiene una opción provisional: asegúrate de que sharp sea 0.35.5 o posterior, o bloquea el renderizado de SVG en sharp con sharp.block({ operation: ["VipsForeignLoadSvg"] }), como describe el aviso de sharp. Los fallos de use cache y Server Actions no tienen solución alternativa, y solo la actualización los cierra.
A fecha del 15 de octubre, los avisos de use cache y Server Actions no tenían CVE y no aparecían en el feed de avisos de npm que utiliza npm audit, por lo que los escáneres de dependencias podrían no advertirte sobre ellos. El fallo de imagen sí aparece, a través del aviso propio de sharp.
Por qué el fallo de imagen sigue reapareciendo
Esta es la tercera vez desde agosto que el procesamiento de imágenes en Next.js produce un fallo de ejecución de código. En agosto, un error en libheif, al que se accedía a través de sharp, permitía la ejecución de código cuando el optimizador manejaba una imagen AVIF manipulada. En septiembre, un fallo en next/og permitía que texto controlado por el atacante modificara el SVG generado.
Next.js no cambió su propio código de imagen esta vez. 16.4.1 incluye el mismo optimizador que 16.4.0 y corrige el fallo de imagen elevando el sharp incluido a 0.35.5, que incorpora un librsvg parcheado (2.63.2).
El error de librsvg, CVE-2026-96889, se hizo público el 23 de septiembre y se corrigió en sharp el 27 de septiembre. Red Hat lo calificó con 7.8 y dijo que su explotación requiere interacción del usuario, como abrir un archivo malicioso. Vercel calificó la exposición de Next.js con 9.5 y accesible a través de la red.
El investigador que reportó el error de librsvg, Rafael B. Dias, afirma que es la debilidad detrás del fallo de next/og de septiembre. Desde entonces se ha publicado un exploit funcional para ese fallo anterior, diseñado para una configuración de servidor específica.
El mantenedor de sharp también advierte que si el fallo termina en ejecución de código o solo en un bloqueo puede depender de la compilación de Node.js del servidor, porque los binarios oficiales de Node.js no están reforzados contra este tipo de ataque de memoria.
No es lo mismo que React2Shell
El fallo de React Server Components se encuentra en los mismos tres paquetes que React2Shell, el fallo de máxima gravedad divulgado en diciembre de 2025 que los atacantes explotaron a gran escala. Este es mucho más limitado. React lo describe como algo que afecta a "casos extremadamente raros en los que las respuestas transportan múltiples arrays tipados y un valor controlado por el atacante".
A fecha del 15 de octubre, no hay informes públicos de que ninguno de los tres fallos corregidos el 14 de octubre haya sido utilizado en ataques.
Deja una respuesta