Dos vulnerabilidades RCE críticas en Next.js: qué deben hacer los equipos autoalojados

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Seguridad en tiempo de ejecución y refuerzo de plataformas para servicios de EE. UU. y la UE

La respuesta corta

Qué corrigió Vercel el 25 de agosto

Vercel preanunció la versión con una semana de antelación, lo que dio a los equipos margen para planificar ventanas de mantenimiento. La versión final llegó antes de lo previsto después de que se identificara una segunda vulnerabilidad de gravedad crítica, el fallo de imágenes AVIF, en una dependencia upstream en los días previos a la fecha planificada. Ambas correcciones se publicaron juntas en la versión de emergencia del 25 de agosto.

Las dos líneas LTS activas son los objetivos del parche. Next.js 16.3.3 es la actual Active LTS y Next.js 15.5.24 es la Maintenance LTS, que cubren las dos familias de versiones más desplegadas. Los equipos en ramas antiguas y al final de su vida útil no reciben correcciones; lo recomendable es migrar a una línea con soporte antes de parchear.

Vercel coordina las divulgaciones de seguridad a través de su programa Open Source Bug Bounty en HackerOne. Ambos avisos se notificaron de forma privada y se corrigieron antes de la divulgación pública, por lo que no existía código de exploit de prueba de concepto en el momento del anuncio.

CVE-2026-75604: RCE por recorrido de rutas en Windows

La mecánica de CVE-2026-75604 se origina en cómo Next.js gestiona la resolución de rutas cuando están activos a la vez el Pages Router y el App Router. En esa configuración híbrida, cada vez más habitual a medida que los equipos migran de forma incremental desde Pages Router, un fallo de recorrido de rutas en la capa del sistema de archivos de Windows puede activarse sin autenticación. Un atacante que pueda enviar una petición HTTP manipulada al servidor puede lograr la ejecución arbitraria de código con la identidad del proceso.

La restricción de alcance importante es el sistema de archivos: esta vulnerabilidad es exclusiva de Windows. El aviso de Next.js es explícito: «Linux y macOS no están afectados por este problema». Muchos despliegues autoalojados de Next.js se ejecutan en contenedores Linux, lo que reduce la exposición real. Pero los equipos que ejecutan el proceso del servidor de Next.js en Windows (ya sea en una VM, en una instancia de nube basada en Windows o en una cadena de desarrollo híbrida que también tiene superficie de producción) deben tratarlo como un parche de máxima prioridad.

Lo crucial es que no se conoce ninguna solución alternativa para las aplicaciones alojadas en Windows. Desactivar uno de los routers rara vez es una opción en una configuración híbrida de producción. El parche es la única mitigación completa. Fastly ha publicado un parche virtual para sus clientes de WAF, y las reglas a nivel de edge pueden reducir la exposición en tránsito, pero ninguno sustituye a la actualización del framework. Los equipos que confían en auditorías de seguridad de la capa de aplicación deben tener en cuenta que el análisis estático no detectará un recorrido de rutas en tiempo de ejecución de este tipo: hace falta actualizar.

Fallo de optimización de imágenes AVIF

La segunda vulnerabilidad (GHSA-2xp9-vwfh-vxw4) afecta a otra parte de Next.js: la Image Optimization API. Cuando un servidor Next.js procesa una imagen AVIF con la biblioteca sharp, depende de libheif para la decodificación. El fallo es un error de seguridad de memoria en la propia libheif: si un atacante consigue que el servidor decodifique un archivo AVIF manipulado de forma maliciosa, puede lograr la ejecución remota de código sin autenticación en el host.

La superficie de ataque de este fallo es más amplia que la de CVE-2026-75604. No se limita a Windows, y cualquier despliegue de Next.js que procese imágenes controladas por el usuario (ya sea de subidas, de URL de terceros pasadas al componente <Image> o de una configuración remotePatterns sin validar) está potencialmente dentro del alcance. La lista de permitidos remotePatterns de next.config.js sí limita qué URL remotas se pueden optimizar, pero una lista mal configurada o demasiado permisiva podría dejar exposición.

Como el fallo está en una biblioteca upstream y no en Next.js, el equipo de Vercel eligió una mitigación conservadora: las versiones parcheadas de Next.js desactivan por completo la optimización de imágenes AVIF hasta que la corrección se propague por la cadena de versiones de libheif. Las imágenes AVIF se seguirán sirviendo; simplemente no pasarán por el pipeline de optimización. Los equipos que dependan de la optimización AVIF por rendimiento deberían planificar reactivarla cuando haya una versión parcheada de libheif disponible e integrada en sharp.

¿Quién está protegido automáticamente?

Los equipos que despliegan en la plataforma gestionada de Vercel no necesitan hacer nada: Vercel confirmó en su changelog que la plataforma está protegida frente a ambas vulnerabilidades. Las mitigaciones a nivel de infraestructura de Vercel se aplican automáticamente a todas las aplicaciones alojadas.

Para todos los demás, la respuesta es más matizada. Los despliegues autoalojados en cualquier plataforma (AWS, GCP, Azure, infraestructura local, contenedores Docker, VM bare-metal) requieren una actualización manual. La versión de Next.js que ejecuta su aplicación la determina lo que está instalado en node_modules, no el proveedor de alojamiento. Si su pipeline de CI no fija y verifica la versión del framework en cada compilación, es un buen momento para añadir esa comprobación.

Los runtimes edge y las funciones serverless que no ejecutan un servidor Next.js completo sobre Node.js no se ven afectados por CVE-2026-75604, porque el recorrido de rutas ocurre en el proceso del servidor. El fallo de AVIF queda de forma similar confinado a la Image Optimization API: si su despliegue gestiona la optimización de imágenes externamente (mediante una CDN o un servicio aparte), su superficie es menor, pero actualizar sigue siendo lo correcto.

Qué significa para los equipos de software de EE. UU. y la UE

Para los equipos que ejecutan Next.js en producción, la pregunta principal es operativa: ¿cuánto se tarda en pasar de «hay un parche crítico» a «todos los servicios afectados ejecutan la versión corregida»? Si su respuesta se mide en horas, esta semana parece manejable. Si se mide en semanas, ese intervalo es el verdadero riesgo, no solo por este CVE, sino por el siguiente.

Conviene comprobar el alcance exclusivo de Windows de CVE-2026-75604 frente a su despliegue real. Muchos equipos dan por hecho que usan contenedores Linux, pero los entornos mixtos (donde Next.js se ejecuta en un proceso de Node.js sobre un host Windows por motivos heredados, o donde un sistema en fase de desarrollo tiene una exposición cercana a producción) pueden pillar desprevenidos a los equipos. Un inventario de dónde se ejecuta realmente Next.js en su entorno es un entregable útil de este incidente, aunque no se vea afectado de inmediato.

Para los equipos de sectores regulados, estas divulgaciones tienen además una dimensión de cumplimiento. Marcos como SOC 2, ISO 27001 y la directiva NIS2 de la UE esperan un proceso documentado de gestión de vulnerabilidades: cómo vigila los avisos, cómo clasifica la gravedad y cómo es su SLA de parcheo. Un RCE crítico en un framework de código abierto muy extendido es un caso de prueba concreto. Demostrar que identificó, clasificó y parcheó dentro de un SLA definido, y que dispone de registros que lo prueban, es exactamente lo que quiere ver un evaluador.

Cómo parchear esta semana

El camino hacia un despliegue parcheado es sencillo, pero los detalles importan.

1. Compruebe su versión de Next.js. Ejecute npx next --version o inspeccione package.json en todos sus servicios. Si usa Docker, revise los registros de compilación de la imagen base o inspeccione el contenedor: docker exec <container> npx next --version.
2. Actualice el framework. Para la línea 15.x: npm install next@15.5.24. Para la línea 16.x: npm install next@16.3.3. Haga commit del package-lock.json actualizado para que CI imponga la versión.
3. Reconstruya las imágenes de contenedor. Si Next.js está incluido en una imagen de Docker, no basta con subir la versión de la dependencia: reconstruya la imagen desde cero para que la nueva versión quede integrada. Un contenedor en ejecución no se actualiza solo.
4. Verifique el comportamiento de AVIF. Tras actualizar, confirme que su pipeline de optimización de imágenes se comporta como espera. Los archivos AVIF se servirán, pero no se optimizarán en las versiones parcheadas; si sirve mucho AVIF, revise los índices de acierto de su CDN y valore si la cobertura de WebP es suficiente mientras se propaga la corrección upstream.
5. Audite sus remotePatterns. Mientras esté en la configuración, ajuste las entradas demasiado amplias de la lista de permitidos. El fallo AVIF requiere que el servidor procese una imagen maliciosa: una configuración estricta de remotePatterns limita qué URL de imágenes externas pueden llegar al optimizador.
6. Actualice su análisis de dependencias. Añada la verificación de la versión de Next.js a su pipeline de CI para que cualquier regresión futura, como una actualización de dependencias que degrade el framework, se detecte antes de llegar a producción.

Preguntas frecuentes

Fuentes

Vercel / Next.js — August 2026 Security Release (en inglés; aviso oficial, fuente primaria)
Vercel Changelog — Next.js August 2026 security vulnerabilities (en inglés; confirmación de la protección de la plataforma)
SecurityOnline — 45M Weekly Downloads at Risk: Next.js CVE-2026-75604 (CVSS 9.0) Enables Unauthenticated RCE (en inglés)
Endor Labs — Critical RCE Vulnerabilities in React and Next.js (en inglés)