Vulnerabilidades de Next.js en mayo de 2026: la amenaza real para la caché RSC

Vulnerabilidades de Next.js: la situación en una frase y el triaje que importa

Next.js coordinó la publicación de 13 avisos de seguridad el 6 de mayo de 2026 y lanzó las versiones corregidas el 7 de mayo: 16.2.6 y 15.5.18. La prensa puso el foco en CVE-2026-44578, el SSRF por WebSocket, porque la captura resulta impactante: el atacante solicita una actualización de la conexión, el servidor llega por sí mismo a 169.254.169.254 y el endpoint de metadatos devuelve credenciales de IAM. Dramático.

Pero solo afecta al alojamiento propio. En un despliegue administrado por Vercel y protegido por Cloudflare, esa vía no es accesible. El aviso que sí puede llegar a mis lectores es el de envenenamiento de caché RSC, de gravedad Moderate, del que casi nadie habla: una respuesta RSC contaminada no se queda en la solicitud del atacante, sino que entra en mi caché de borde compartida y se sirve a todos los visitantes hasta que purgo la etiqueta.

Quien ejecute cualquier versión de Next.js >= 13.4.13 debe actualizar esta semana. Las únicas preguntas son a qué versión, en qué orden y qué hay que volver a probar después. El triaje que sigue es la matriz que utilicé en omidsaffari.com —App Router sobre Vercel, Cloudflare delante, purga mediante Cache-Tag y un webhook de revalidación— y explica por qué dejé de priorizar la CVE de los titulares.

Qué implica para fundadores sin perfil técnico

Si el producto es una aplicación de Next.js, esto debe resolverse esta semana, no quedarse como tarea pendiente. El costo no se mide en latencia ni en horas de desarrollo: una página en caché contaminada o una ruta de administración que permite saltarse la autenticación se convierte en un problema de confianza del cliente. Basta una captura de la página comercial mostrando contenido del atacante o un reporte de acceso a /admin sin sesión para pasar la semana dando explicaciones en lugar de vendiendo.

La pregunta para el equipo de ingeniería es una sola: «¿Estamos en 16.2.6 o 15.5.18 y purgamos la caché de borde después del despliegue?» Si la respuesta es menos precisa —«estamos aplicando el parche», «está en curso», «el SSRF no nos afecta»—, el trabajo no ha terminado. Los despliegues con alojamiento propio (ECS, EC2, Kubernetes o cualquier servidor gestionado por el equipo que ejecute next start) están en el grupo de mayor riesgo, porque quedan expuestos al SSRF además de a todo lo demás. Pregunte cuál es su caso. La respuesta debería tardar diez segundos.

Las 13 vulnerabilidades, ordenadas según puedan alcanzar su arquitectura

El error de todas las publicaciones que repiten «13 CVE, apliquen el parche ya» es tratar la lista como si fuera plana. No lo es. Cada aviso exige una condición previa —alojamiento propio, Turbopack, Cache Components, nonces de CSP o i18n— y la exposición real se limita a aquellos que coinciden con el despliegue. Estas son las mismas 13 vulnerabilidades, agrupadas por las condiciones necesarias para explotarlas.

Grupo de evasión de middleware y proxy (5 avisos, la mayoría High). El principal es GHSA-267c-6grr-h53f, que permite que una URL de precarga de segmento de App Router eluda las comprobaciones de autenticación del middleware. El grupo también incluye el aviso de corrección incompleta publicado el 7 de mayo (GHSA-26hh-7cqf-hhc6) para Turbopack, una evasión mediante la ruta de la configuración regional predeterminada de i18n en Pages Router y otra por inyección de parámetros en rutas dinámicas. Condición previa: usar middleware de Next.js para imponer autenticación o reescrituras. Es el caso de casi todo el mundo.

SSRF, CVE-2026-44578. El gestor de actualización a WebSocket del servidor con alojamiento propio puede llegar a endpoints HTTP internos en el puerto 80, incluidos los metadatos de la nube. Versiones afectadas: 13.4.13+ hasta <15.5.16 y 16.0.0–<16.2.5, solo con alojamiento propio. Está confirmado que los despliegues administrados por Vercel no se ven afectados.

Denegación de servicio, dos avisos. Uno corresponde al DoS de RSC upstream; el segundo es un DoS por agotamiento de conexiones en aplicaciones que han activado Cache Components (High, GHSA-q4gf-8mx6-v5v3). Condición previa para el segundo: haber habilitado Cache Components de forma explícita, algo que la mayoría de las aplicaciones no ha hecho.

Envenenamiento de caché RSC (Moderate). Las colisiones en el mecanismo que evita la caché dentro del flujo de payloads RSC permiten que una solicitud manipulada contamine una respuesta almacenada. Condición previa: guardar respuestas RSC en cualquier punto posterior, ya sea un CDN, un proxy inverso, el edge de Vercel o Cloudflare. Este es el aviso importante en mi arquitectura.

XSS, dos avisos. CVE-2026-44581 (Moderate) afecta a aplicaciones App Router que generan nonces de CSP; el otro es un XSS en scripts beforeInteractive que consumen entradas no confiables. Condiciones previas: servir una CSP con nonces o pasar entradas del usuario a una etiqueta de script beforeInteractive.

Anote qué condiciones cumple el despliegue: esa es su lista real. En omidsaffari.com, el resultado es este: grupo de evasión de middleware (sí), SSRF (no, alojado en Vercel), DoS de RSC (sí, upstream), DoS de Cache Components (no, no está activado), envenenamiento de caché RSC (sí, y amplificado), XSS por nonce de CSP (sí) y XSS en beforeInteractive (no). Ocho avisos High/Moderate se reducen a cinco que me afectan, y el de mayor radio de impacto no es el famoso.

Por qué el SSRF de las capturas probablemente no es su problema, pero el envenenamiento de caché sí

CVE-2026-44578 necesita que el servidor next start del lado de Node gestione la actualización a WebSocket y siga la redirección. Vercel no hace pasar mis solicitudes por ese servidor de una forma que permita alcanzar la vía del SSRF: la plataforma termina los WebSockets y, además, el endpoint de metadatos está protegido por IMDSv2 con un límite de saltos que tampoco sobreviviría al recorrido. Colocar Cloudflare delante no cambia el resultado. En una topología Vercel + Cloudflare, la captura dramática no se puede reproducir.

El aviso de envenenamiento de caché RSC invierte por completo la situación. La vulnerabilidad está en la ruta de gestión de solicitudes por la que pasa todo el mundo, y el resultado es un payload RSC contaminado: el árbol de React serializado que reciben los lectores. En mi sitio, ese payload no se limita a la solicitud del atacante. Termina aquí:

Cache-Control: public, s-maxage=300, stale-while-revalidate=86400
Cache-Tag: article:nextjs-may-2026-security-triage

s-maxage=300 significa que Cloudflare conserva esa respuesta durante cinco minutos. stale-while-revalidate=86400 permite seguir sirviéndola durante un día después de que caduque mientras la revalida en segundo plano. La purga se apoya en Cache-Tag: cuando publico una revisión, el webhook de revalidación activa la purga de la etiqueta y el objeto desaparece.

Veamos qué ocurre con una respuesta contaminada. El atacante solicita una ruta que aprovecha la colisión del mecanismo anticaché. Cloudflare detecta una respuesta almacenable, la guarda bajo la clave de caché de esa URL y le asigna la etiqueta article:<slug>. A partir de entonces, cada visitante de ese slug recibe desde el edge el payload RSC contaminado: no viene del origen, no atraviesa ningún middleware ni pasa por una regla de WAF que yo añada diez minutos más tarde. El objeto contaminado ya está aguas abajo. Permanece allí hasta que vence la ventana de s-maxage o mi flujo de publicación ejecuta una purga. Las reglas de WAF en el origen no sirven para una respuesta que ya está en 300 PoPs.

Por eso el activo en riesgo es la superficie de contenido publicado —la salida del motor de contenidos— y no una API interna. La lista de 13 avisos clasifica el SSRF como High y este fallo como Moderate. En un sitio RSC con caché delante, el orden del impacto práctico se invierte.

Cómo actualizar Next.js, incluida la trampa de la corrección posterior para Turbopack

Primer paso: determine la versión instalada. package.json no refleja necesariamente la versión resuelta cuando contiene un rango con caret; compruebe el lockfile.

bun pm ls | grep next
# or
npm ls next

Después, fije la versión en 16.2.6 (rama Next.js 16) o 15.5.18 (rama Next.js 15). No 16.2.5. Tampoco 15.5.16.

bun add next@16.2.6
# or
npm install next@16.2.6 --save-exact

El motivo para fijar una versión exacta es la trampa que casi nadie menciona. Los 13 avisos originales se corrigieron en 16.2.5 / 15.5.16 el 6 de mayo. El 7 de mayo, Vercel publicó GHSA-26hh-7cqf-hhc6, un seguimiento por una corrección incompleta de la evasión de middleware mediante precarga de segmento, que seguía siendo explotable cuando Turbopack servía la solicitud. Quienes no usaban Turbopack estaban protegidos con 16.2.5 / 15.5.16; quienes sí lo usaban, no. La corrección completa está en 16.2.6 / 15.5.18.

Para las ramas 13.x o 14.x no habrá parche. Vercel no publicará un backport. La solución es migrar a 15.x o 16.x y debe planificarse como una migración, no como un bun update. Reserve como mínimo una semana si la aplicación no es trivial: la superficie de cambios incompatibles es real, sobre todo en los matchers del middleware y en los valores predeterminados de caché de App Router.

Cuando termine el despliegue, purgue la caché de borde. Es el paso que falta en todos los demás análisis que he leído esta semana. Sin una purga, cualquier payload RSC almacenado por Cloudflare antes de activar el parche seguirá allí; si alguien aprovechó la vulnerabilidad durante ese intervalo, podría estar contaminado y continuar sirviéndose desde el edge hasta que venza s-maxage. En mi arquitectura:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Después, verifique el resultado. Elija una ruta protegida por autenticación en el middleware, construya la URL de precarga de segmento descrita en el aviso y repita la solicitud en producción. La respuesta debería ser un 401 / 302 / o cualquier código que devuelva el middleware a una solicitud sin autenticar. Si obtiene un 200 con contenido, el parche del middleware no se aplicó y el problema está en el despliegue, no en Next.js.

Qué dejó de funcionar en 16.2.6, sin suavizarlo

La realidad es que no se trata de simples parches de seguridad. Varios modifican deliberadamente el enrutamiento y el comportamiento de las claves de caché porque las vulnerabilidades estaban precisamente en esas áreas. Por tanto, hay que esperar diferencias.

Matchers de middleware más estrictos para URLs .rsc y de precarga de segmento. La corrección de la evasión mediante precarga de segmento cambió la forma de evaluar los matchers. Si algún patrón dependía de la estructura anterior —en particular, si utilizaba un negative lookahead para excluir rutas _next y daba por hecho que .rsc siempre estaba debajo—, debe volver a verificarse. Tuve que ampliar un matcher para capturar de forma explícita el sufijo de precarga de segmento en una ruta protegida. Fue un ajuste de cinco minutos, pero habría provocado una regresión silenciosa si no hubiera repetido la prueba.

Gestión de nonces de CSP. La corrección del XSS (CVE-2026-44581) cambia la propagación de los nonces durante el renderizado de App Router. Si genera los nonces en el middleware y los referencia desde un componente Script, ejecute la CSP en modo report-only durante un día después del despliegue. No observé infracciones, pero el cambio existe y un equipo me contó que tuvo que actualizar su flujo de generación de nonces.

Cambio de comportamiento en Cache Components. Para quienes usan Cache Components y están en la ruta de corrección del DoS por agotamiento de conexiones, el parche modifica cómo se agrupan los fallos de caché bajo carga. Vuelva a probar las rutas con más tráfico. Yo no uso Cache Components, así que no tuve que hacerlo.

La lista de verificación que utilicé antes de dar por terminada la actualización:

[ ] next version pinned to 16.2.6 in lockfile
[ ] middleware auth replay on /admin via segment-prefetch URL → 401
[ ] middleware auth replay via .rsc URL → 401
[ ] RSC cache key sanity: same URL, two clients, identical payload
[ ] forced edge purge after deploy
[ ] CSP report-only on for 24h with no new violations
[ ] one full revalidate cycle on a high-traffic page

Reserve una pasada por staging. No es una actualización de parche sin riesgo, porque las correcciones de seguridad cambian deliberadamente el enrutamiento y las claves de caché. La diferencia entre un despliegue el martes por la tarde y un incidente esa misma noche está en haber repetido las pruebas de las rutas de autenticación antes de pasar a producción.

Aplique el parche, no confíe en el WAF: la lección estructural

Vercel no publicó reglas de WAF para esta versión. El changelog afirma que aplicar el parche es la única mitigación completa, y tiene razón: ninguno de estos avisos puede filtrarse de forma limpia en el edge porque las formas de las solicitudes maliciosas se solapan demasiado con las legítimas. Cloudflare publicó reglas de WAF y mitigaciones en el adaptador del framework el 6 de mayo como defensa en profundidad, no como sustituto de la actualización. Conviene leer la formulación con atención: el changelog de Cloudflare aclara que las reglas de WAF reducen la exposición durante el periodo de despliegue, no después.

Esa diferencia encierra la lección estructural de esta semana. Una arquitectura capaz de actualizar un framework, volver a desplegar y purgar su caché de borde en una sola tarde convierte la divulgación coordinada de 13 CVE en una tarea operativa rutinaria. Otra que no pueda hacerlo —porque la actualización exige una migración, porque no existe un mecanismo de purga o porque el flujo de despliegue tiene controles manuales— permanecerá expuesta durante todo el proceso. Días. A veces semanas.

Es el mismo patrón del argumento sobre el radio de impacto de los agentes: una recuperación rápida integrada en la estructura supera al filtrado reactivo. No se pueden impedir todas las solicitudes maliciosas ni todas las llamadas erróneas de un agente. Lo importante es diseñar el sistema para que, cuando ocurra una, la respuesta se mida en minutos y el radio de impacto quede limitado por la topología, no por la esperanza.

Actualice esta noche. Fije 16.2.6 o 15.5.18. Después, purgue la caché. La CVE de la captura no es la preocupación correcta; la vulnerabilidad Moderate que alcanza todas las páginas almacenadas es la que importa.