|

CVE-2026-75604 Next.js: el scanner decía limpio

En pocas palabras: Porque los escáneres leen bases que van atrasadas: Vercel divulgó CVE-2026-75604 el 25 de agosto de 2026, el registro CVE salió el 1 de septiembre y la GitHub Advisory Database, que usan Dependabot, npm audit y OSV, la listó recién el 8 de septiembre, dos semanas después.

CVE-2026-75604 Next.js es una vulnerabilidad crítica (CVSS 9.0) que Vercel divulgó el 25 de agosto de 2026 y con la que un atacante sin autenticación puede llegar a ejecutar código remoto, pero solo en apps que corren sobre Windows. GitHub Advisory Database la listó recién el 8 de septiembre.

CVE-2026-75604 es una vulnerabilidad de path traversal (CWE-22) en Next.js, el framework de React de Vercel. Un atacante remoto envía una ruta con barras invertidas codificadas, sale del directorio de caché incremental y llega a la clave de cifrado de las Server Actions. Con esa clave falsifica valores y ejecuta código en el servidor. Afecta a servidores con filesystem Windows y tiene un CVSS v3.1 de 9.0.

En 30 segundos

  • El parche está en Next.js 15.5.24 y 16.3.3; las ramas 13.x y 14.x no tienen versión corregida.
  • Linux, macOS y Vercel no están afectados: el problema es de servidores Windows, normalmente detrás de IIS.
  • Entre el aviso de Vercel (25/08) y el listado en GitHub Advisory Database (08/09) pasaron 14 días, y de esa base leen Dependabot, npm audit y OSV.
  • Si una app afectada corrió en Windows, Empirical Security recomienda rotar la clave de Server Actions después de parchear.

¿Qué es CVE-2026-75604 y qué versiones de Next.js afecta?

Afecta a Next.js desde 13.4.0 hasta antes de 15.5.24 en la rama 15, y hasta antes de 16.3.3 en la rama 16. Vercel corrigió el problema en 15.5.24 y 16.3.3, según el análisis de Empirical Security. Para 13.x y 14.x no hay release parcheado: esas apps tienen que migrar a 15.5.24 o superior.

El mecanismo es específico. Un ..%5C en un segmento de ruta sale de la carpeta de caché y llega a server-reference-manifest.json, el archivo con la clave que Next.js usa para cifrar lo que viaja entre navegador y servidor en una Server Action. Privilegios y interacción de usuario: ninguno. La complejidad está calificada como alta, probablemente por la pila de condiciones que sigue.

Ojo con un detalle: CyCognito describe el problema como una escritura de archivos fuera del caché, mientras que la descripción del CVE y Empirical hablan de exponer la clave. Las fuentes difieren en el mecanismo, no en el desenlace (ejecución remota de código).

¿Mi app Next.js es vulnerable si corre en Linux o en Vercel?

cve-2026-75604 next.js diagrama explicativo

No. El aviso de Vercel dice: “Linux and macOS are not affected by this issue” (Linux y macOS no están afectados), y CyCognito agrega que las apps en la plataforma administrada de Vercel tampoco, porque esa infraestructura corre sobre Linux. La exposición es de apps autoalojadas en Windows Server.

Dentro de Windows, Empirical detalla las condiciones para estar en el escenario crítico:

  • Versión afectada. Anterior a 15.5.24 en la rama 15 o a 16.3.3 en la 16.
  • Routers combinados. Pages Router y App Router con Cache Components desactivado. La descripción del CVE dice “o”, pero el aviso de Vercel y el módulo público de Metasploit requieren ambos.
  • Caché por defecto. Caché incremental en disco, en la ubicación predeterminada. Los builds output: 'standalone' usan el mismo caché y no quedan exentos.
  • Para el exploit público. Una ruta dinámica con ISR en Pages Router, una ruta dinámica cacheada en App Router y al menos una Server Action que capture un campo de formulario en una closure.

Si en next.config.js tenés un cacheHandler propio (Redis, S3), la falla está en el caché de filesystem por defecto, así que esa app no debería llegar a la ruta vulnerable. Empirical aclara que el aviso no dice esto de forma explícita, entonces confirmalo app por app.

Una nota sobre el post de dev.to que originó esta cobertura: el autor dice que su versión de Next.js estaba afectada, pero no menciona en qué sistema operativo corre. Sin ese dato, no sabemos si su caso entra en el escenario Windows. En nuestra comparativa de herramientas de CI/CD en 2026 profundizamos sobre esto.

Ponele un ejemplo hipotético: tenés 40 repos con Next.js 15.5.20 y desde el 8 de septiembre el scanner te levanta 40 alertas. Cerrarlas en bloque como “Linux, no aplica” es tentador. Empirical lo desaconseja: la persona que cierra el ticket conoce la versión del paquete, pero a menudo no sabe en qué servidor aterriza el build.

¿Por qué npm audit y Dependabot decían que no había vulnerabilidades?

Porque esas herramientas leen GitHub Advisory Database, que listó CVE-2026-75604 el 8 de septiembre, 14 días después del aviso público de Vercel. No estaban rotas: consultaban una base que todavía no tenía el dato. Esta es la cronología de Empirical Security:

  • 17 de agosto: se reserva el ID del CVE.
  • 25 de agosto: el aviso de Vercel cita el ID públicamente.
  • 1 de septiembre: se publican el registro CVE y la entrada de NVD.
  • 8 de septiembre: lo listan GitHub Advisory Database y OSV.
  • 18 y 24 de septiembre: primera actividad contra el CVE y última explotación registrada por los sensores de Empirical.

Los números de contexto, también de Empirical: EPSS de 0.023 (percentil 82), sin presencia en el catálogo KEV de CISA y un módulo público de Metasploit. Los propios analistas avisan que su señal de explotación sale de una sola fuente de sensores y que, con un módulo público circulando, parte de esa actividad puede ser prueba y no intrusión. Según Empirical, las notas de fines de agosto (The Hacker News, el 27/08) informaron que no había explotación y nadie volvió sobre el tema.

Hay un punto que no cierra del post original. El autor dice que su escaneo salió limpio unas dos semanas antes de publicar (el texto es del 8 de octubre), lo que caería cerca del 24 de septiembre, cuando la base de GitHub ya tenía el CVE desde hacía unos 16 días. No podemos verificar su escaneo ni explicar la diferencia con las fuentes que tenemos, así que tomalo como relato del autor, no como dato confirmado. También afirma que la explotación empezó a fines de septiembre; la telemetría de Empirical marca el primer registro el 18.

¿Qué significa que un CVE esté “Reserved but Public”?

Reserved but Public (RBP) es un CVE ID reservado que un aviso público ya cita mientras el registro CVE todavía no se publicó. En ese lapso, las herramientas que dependen del registro, como NVD y EPSS, no tienen nada a qué engancharse. En este caso la ventana duró siete días, del 25 de agosto al 1 de septiembre.

Según Empirical, las reglas para las CNA fijan un objetivo de 72 horas desde que el ID es público. Acá se tardó una semana, un retraso que en la industria ya tiene nombre.

¿Cómo cubrir la brecha entre el aviso del proveedor y el scanner?

Sumá el aviso del proveedor como segunda señal para tus dependencias críticas, sin esperar a NVD ni a GitHub. Empirical lo plantea así: abrir el ticket apenas un aviso cita un CVE ID, guardar también el ID GHSA para fusionar hallazgos de dependencias y hosts, y revisar el alcance cuando se publique el registro.

  • Parchear lo que aplique. 15.5.24 o 16.3.3 como mínimo; Empirical prefiere las actuales, 15.5.26 y 16.3.6. Los parches también desactivan la optimización de imágenes AVIF por una falla aparte, según CyCognito, así que esas imágenes se sirven sin optimizar.
  • Bloquear mientras tanto. En el WAF o proxy inverso, rechazar paths con %5C, %255C o barra invertida literal, y probar la regla con tráfico legítimo antes de aplicarla.
  • Rotar la clave. Con el build corregido ya desplegado, borrar .next/cache/.rscinfo, regenerar la clave (o fijarla con NEXT_SERVER_ACTIONS_ENCRYPTION_KEY) y redesplegar en todas las instancias, incluidas las Linux que la compartan.
  • Buscar en logs desde el 25 de agosto. Patrones de barra invertida en segmentos de ruta, sobre todo bajo /_next/data/.

El autor del post suma un script que mira el RSS de Vercel y filtra títulos con “security”, “vulnerability” o “cve”. Sirve de punto de partida (que no es poco), pero tiene límites: el feed es el changelog general, no uno de seguridad; mira solo las últimas cinco entradas, que en un changelog movido se pueden llenar de otras novedades; y el filtro por palabras clave da falsos positivos y negativos. Si lo adoptás, pasalo por un feed de seguridad dedicado. Para más detalles técnicos, mirá elegir entre Jenkins y GitHub Actions.

El autor también es fundador de Krova Cloud y su flujo de validar parches en un clon descartable de producción es el producto que vende. Lo citamos como contexto de la fuente, no como recomendación. Cobertura relacionada: el XSS almacenado en JetAppointment.

Propuesta editorial para verificar (no viene de ninguna fuente ni la probamos): para cada app, registrá el sistema operativo del runtime con evidencia (manifiesto de despliegue, imagen base del contenedor o inventario de hosts), corré npm ls next sobre el build desplegado y confirmá que la regla del WAF rechaza %5C en un entorno de prueba tuyo. Si mover la app fuera de Windows es una opción, un VPS Linux, por ejemplo en donweb.com, saca el problema de raíz, aunque no reemplaza el parche.

¿Qué está confirmado y qué no sobre CVE-2026-75604?

  • Confirmado por varias fuentes: CVSS 9.0 (v3.1), versiones corregidas 15.5.24 y 16.3.3, alcance limitado a Windows, aviso de Vercel el 25/08, listado en GitHub el 08/09.
  • Según Empirical: actividad contra el CVE entre el 18 y el 24/09 en sus sensores y un módulo público de Metasploit. Parte puede ser prueba.
  • No confirmado: el escaneo limpio del autor del post, su sistema operativo y la fecha de inicio de la explotación que cita.
  • Sin resolver: el mecanismo exacto (lectura de la clave o escritura de archivos) según la fuente, y el “o” contra “ambos” entre el CVE y el aviso.

Errores comunes

  • Cerrar alertas por “Linux” sin evidencia. La versión del repositorio no prueba dónde corre el build. Cerralas solo con un manifiesto, una imagen base o un inventario de hosts.
  • Actualizar y darlo por terminado. Si la app estuvo en Windows, la clave pudo filtrarse y un upgrade solo puede no cambiarla, porque Next.js cachea la clave en .next/cache/.rscinfo hasta 14 días.
  • Tomar el “verde” del scanner como un “no se sabe nada”. Un resultado “limpio” habla de la base que lee la herramienta, no de lo que ya es público.
  • Detectar solo por el header Next-Action. Empirical pide no basar la detección únicamente en eso; también hay POSTs con campos $ACTION_REF_ o $ACTION_ID_.

Preguntas Frecuentes

¿A qué versión de Next.js tengo que actualizar para corregir CVE-2026-75604?

A 15.5.24 o 16.3.3 como mínimo, según la ficha de GitLab y las demás fuentes. Empirical prefiere las versiones actuales, 15.5.26 y 16.3.6. Para 13.x y 14.x no hay parche, hay que migrar a 15.5.24 o superior.

¿Una app Next.js en Vercel está afectada por CVE-2026-75604?

No. CyCognito explica que las apps en la plataforma administrada de Vercel no están afectadas porque esa infraestructura corre sobre Linux. La falla solo aplica a servidores con filesystem Windows. Lo complementamos en la inyección de objetos PHP en wpForo.

¿Por qué npm audit dijo que no había vulnerabilidades si el CVE ya era público?

Porque npm audit, Dependabot y OSV leen GitHub Advisory Database, que lo listó el 8 de septiembre, 14 días después del aviso de Vercel del 25 de agosto. Las herramientas funcionaban bien, solo que su base iba atrasada.

¿Qué significa Reserved but Public en un CVE?

Es un CVE ID reservado que un aviso público ya cita, con el registro CVE todavía sin publicar. Las herramientas que dependen del registro, como NVD y EPSS, no tienen dato hasta que se publica.

¿Hay que rotar la clave de Server Actions después de parchear?

Sí, si una app afectada corrió en Windows, según la recomendación de Empirical Security (el aviso de Vercel no trata el tema). Rotá solo cuando el build corregido ya esté desplegado, porque una app vulnerable expondría la clave nueva igual que la vieja.

Conclusión

El episodio deja dos cosas distintas. Una es técnica: CVE-2026-75604 Next.js es crítico, pero afecta a un escenario acotado (Windows, routers combinados, caché por defecto), y la mayoría de los equipos está fuera de él. La otra es de proceso: una ventana de 14 días entre el aviso del proveedor y la base que leen tus scanners es real, y un “verde” no la cubre.

Qué hacer esta semana: confirmá con evidencia dónde corre cada app, parcheá a 15.5.24 o 16.3.3 (o más nuevas) lo que esté en Windows, rotá la clave, y sumá los avisos de seguridad de Next.js, tu base de datos y tu proveedor de autenticación como segunda señal. Después medí, para tu dependencia más crítica, cuánto tardó el último aviso en aparecer en tu scanner.

Fuentes

Te puede interesar...