El 3 de noviembre de 2026, el equipo de Next.js publicó las versiones 16.4.5 (Active LTS) y 15.5.29 (Maintenance LTS) con correcciones para siete vulnerabilidades. Una está clasificada como alta y seis como medias. Cuatro de ellas hacen que la caché entregue a una persona contenido generado para otra: otro cliente, otro idioma u otro usuario. El aviso previo, del 27 de octubre, hablaba de siete fallos medios; la clasificación alta apareció solo en la publicación final.
Cuatro fallos en la caché y tres fuera de ella
El fallo alto (GHSA-mfr8-8qww-v76h) afecta a aplicaciones con Cache Components activado cuando la misma función use cache se llama directamente y también desde dentro de unstable_cache, y esa función lee un parámetro de ruta raíz, como el identificador de un cliente. Mientras se llena la caché, una llamada concurrente puede recibir el resultado de otra petición sin comprobar ese parámetro. El resultado queda guardado y se sigue sirviendo hasta que la entrada se revalida o se descarta. Si el parámetro separa clientes en una aplicación multiinquilino (varios clientes en el mismo sistema), el resultado puede contener datos de otro cliente.
Los otros tres fallos de caché son medios:
- funciones
use cacheanidadas pueden servir contenido generado para un valor de parámetro raíz (cliente, sitio o idioma) a quien pidió otro (GHSA-vc7v-qv4w-wrv8); - argumentos binarios distintos pasados a una función
use cachepueden generar la misma identidad de caché, lo que permite recibir el resultado de otro usuario o hacer que el propio se entregue a otra persona (GHSA-rhh4-g77r-r9qj); - en aplicaciones autoalojadas con
next start, Cache Components activado y Partial Prefetching desactivado o sin configurar, una petición sin sesión puede contaminar la estructura de página compartida y causar contenido incorrecto o 404 persistentes en otras URL. Este fallo depende de una forma de ruta concreta, descrita en el anuncio.
Fuera de la caché, la versión corrige:
- en aplicaciones autoalojadas, una respuesta obtenida con
fetchy devuelta sin cambios puede llegar al cliente equivocado cuando hay un proxy inverso HTTP/1.1 que encola peticiones en la misma conexión con el backend (GHSA-pc58-hwjq-p385); - las rutas Edge que definen cookies con
NextResponse.cookies.set()exponen el valor de la cookie en una cabecera interna que el JavaScript del mismo origen puede leer, incluso conHttpOnly. El impacto exige que ya haya JavaScript del atacante ejecutándose en el sitio (GHSA-f3mh-rxg3-f5g2); - una imagen de un origen permitido puede pasar como AVIF y saltarse
images.dangerouslyAllowSVG: false, llegando a un decodificador de SVG que la aplicación quiso excluir (GHSA-7qx7-33qx-rqx2).
Quién debe revisar primero
Según el anuncio, los fallos de caché solo aplican a quien usa Cache Components y la directiva use cache. El riesgo concreto aparece cuando la caché separa datos por cliente, idioma o usuario: SaaS con varios clientes en la misma aplicación, sitios multilingües o multimarca servidos por el mismo proyecto y áreas con sesión que guardan respuestas por usuario.
Dos fallos mencionan explícitamente aplicaciones autoalojadas, es decir, ejecutándose con next start en un servidor o contenedor propio. Los equipos con un proxy inverso propio delante de Next.js están en ese grupo. El anuncio no dice si las aplicaciones alojadas en Vercel o en otras plataformas reciben alguna protección del proveedor.
Quien sigue en Next.js 14 o anterior no aparece en la lista de versiones corregidas. Next.js 14 se quedó sin soporte el 26 de octubre de 2025, según endoflife.date.
Qué hacer y hasta cuándo
Actualizar a 16.4.5 quien está en la 16 y a 15.5.29 quien está en la 15. No hay plazo formal, pero los detalles son públicos desde el 3 de noviembre. Para quien tiene caché separada por cliente o usuario, la actualización no debería esperar a la próxima ventana de mantenimiento.
Después de actualizar, las entradas de caché escritas antes siguen ahí. El fallo alto describe resultados que quedan guardados hasta su revalidación o descarte. Mi lectura es que, donde la caché separa clientes, conviene invalidar esas entradas después del deploy, para no seguir sirviendo una respuesta que ya se guardó mal.
Para quien está en la 15, la política de soporte de Next.js extendió las correcciones de seguridad de esa versión hasta el 31 de enero de 2027. La fecha original era el 21 de octubre de 2026. Eso deja menos de tres meses para planificar el paso a la 16. Como expliqué en Una versión con soporte también exige decidir cuándo migrar, la fecha de fin de soporte es el límite; el trabajo de descubrir qué se rompe tiene que empezar antes.
Para quien está en la 14 o anterior, esta versión no trae parche. La salida es migrar.
Lo que aún no está claro
El anuncio no enumera los rangos de versiones afectadas por fallo; esa información está en los avisos individuales de GitHub. Tampoco dice si alguno de los fallos se explotó antes de la corrección. Y el fallo de contaminación de la estructura de página compartida aparece en el anuncio sin identificador GHSA, así que todavía no hay un aviso propio que consultar.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
