SSRF de alta gravedad en Next.js CVE-2026-44578: alcance e indicaciones de actualización

Sun, 17 May 2026 17:27:13 +0800

Next.js divulgó en mayo de 2026 una vulnerabilidad SSRF de alta gravedad: CVE-2026-44578.

Según el aviso de seguridad de GitHub / Vercel GHSA-c4j6-fc7j-m34r y el registro de NVD, el problema afecta a aplicaciones Next.js autoalojadas que usan el servidor Node.js integrado y están expuestas a solicitudes WebSocket upgrade maliciosas. Un atacante podría hacer que el servidor proxifique solicitudes hacia destinos internos o externos arbitrarios, exponiendo servicios internos o endpoints de metadata en la nube.

Los despliegues alojados en Vercel no están afectados. Las versiones corregidas son 15.5.16 y 16.2.5.

Resumen rápido

Si ejecutas Next.js en tus propios servidores, contenedores, Kubernetes, ECS, VPS, bare metal o PaaS autogestionado, revisa esto primero.

Rangos afectados:

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

Casos no afectados o de menor riesgo:

Aplicaciones desplegadas en Vercel.
Aplicaciones actualizadas a 15.5.16, 16.2.5 o versiones posteriores.
Escenarios donde no se expone el servidor Node.js integrado.
Entornos donde el proxy inverso o balanceador ya bloquea WebSocket upgrades innecesarios y el tráfico saliente está restringido.

Orden recomendado de respuesta:

Confirmar la versión de next que realmente corre en producción.
Actualizar las aplicaciones autoalojadas a una versión corregida cuanto antes.
Si no puedes actualizar de inmediato, bloquear WebSocket upgrades innecesarios en el proxy inverso o balanceador.
Restringir el acceso de los servidores de aplicación a metadata cloud, paneles internos y servicios internos sensibles.
Revisar solicitudes WebSocket upgrade recientes y logs de acceso interno.

Qué es la vulnerabilidad

CVE-2026-44578 es una vulnerabilidad Server-Side Request Forgery, o SSRF.

El riesgo central de SSRF es que el atacante no accede directamente a sistemas internos, sino que induce a tu servidor a enviar solicitudes en su nombre. Los servidores suelen estar más cerca de redes privadas, plataformas cloud y servicios internos, por lo que si se convierten en proxy pueden alcanzar recursos que el atacante no podría tocar desde fuera.

En este caso de Next.js, el problema está en la ruta de manejo de WebSocket upgrade. El aviso indica que aplicaciones autoalojadas que usan el servidor Node.js integrado pueden ser forzadas, mediante solicitudes WebSocket upgrade construidas especialmente, a proxificar solicitudes hacia destinos internos o externos arbitrarios.

Los puntos de riesgo incluyen:

Servicios HTTP internos.
Paneles de administración.
Direcciones de metadata cloud.
Servicios internos de contenedores o clústeres.
APIs internas accesibles solo desde el servidor.

La puntuación CVSS v3.1 es 8.6 High, con este vector:

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

Esto significa que el ataque es de red, de baja complejidad, no requiere privilegios ni interacción del usuario, y afecta principalmente a la confidencialidad.

Por qué el autoalojamiento es más peligroso

El aviso afirma explícitamente que los despliegues alojados en Vercel no están afectados.

El foco real son los despliegues autoalojados. La razón es simple: sus entornos de red varían mucho. Algunos exponen directamente el origin server; otros están detrás de Nginx, Traefik, Ingress, Cloudflare, ALB o gateways propios; otros corren en VMs cloud, redes de contenedores o clústeres Kubernetes.

Si esos entornos no restringen el tráfico saliente, el proceso Next.js podría alcanzar:

Direcciones de metadata cloud como 169.254.169.254.
Rangos de IP privados.
Servicios expuestos solo dentro de una VPC.
Redis, Elasticsearch, Prometheus, Grafana y otros componentes internos.
Kubernetes Services, Pods o endpoints de administración.

Por eso el peligro de SSRF no está solo en Next.js, sino en qué puede alcanzar desde la red donde vive.

Cómo saber si estás afectado

Primer paso: revisar la versión de next.

En el directorio del proyecto:

`1`	`npm ls next`

`1`	`pnpm why next`

También puedes inspeccionar:

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

Si la versión cae dentro de estos rangos, hay que actuar:

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

Segundo paso: revisar el modelo de despliegue.

Presta atención a:

Servicios de producción iniciados con next start.
Servidores Node.js personalizados que alojan Next.js.
Imágenes Docker que arrancan directamente un servidor Next.js.
Autoalojamiento en Kubernetes / ECS / VPS / bare metal.
Un origin de Next.js todavía accesible detrás de un proxy inverso.
Redes de aplicación que pueden acceder a servicios internos o metadata cloud.

Si la aplicación está desplegada en Vercel, el aviso oficial indica que no está afectada por esta vulnerabilidad. Aun así, conviene mantener Next.js actualizado, porque versiones cercanas pueden incluir otros parches de seguridad.

A qué versión actualizar

Las versiones corregidas oficiales son:

15.5.16
16.2.5

Ejemplo de actualización:

`1`	`npm install next@15.5.16`

O si usas 16.x:

`1`	`npm install next@16.2.5`

pnpm:

`1`	`pnpm add next@15.5.16`

`1`	`pnpm add next@16.2.5`

Después, reconstruye y publica:

1
2

npm run build
npm run start

O sigue tu flujo CI/CD para reconstruir y publicar la imagen Docker.

Si tu proyecto está fijado en 14.x o 15.x, no conviene saltar apresuradamente a 16.x solo por este parche. Es más seguro actualizar primero a la línea 15.5.16, probar y publicar, y luego planificar una migración de versión mayor.

Mitigaciones temporales

Si no puedes actualizar de inmediato, la idea principal del aviso es: no exponer el origin server directamente a redes no confiables; si WebSocket upgrade no es necesario, bloquearlo en el proxy inverso o balanceador; y restringir en lo posible el tráfico saliente del origin.

Medidas posibles:

No exponer directamente el origin server de Next.js.
Filtrar WebSocket upgrades innecesarios en Nginx, Ingress, ALB, Cloudflare u otros puntos de entrada.
Si el negocio no usa WebSocket, rechazar solicitudes con semántica de upgrade.
Aplicar restricciones de egress para impedir acceso a metadata cloud y rangos internos sensibles.
Usar modos de metadata más seguros ofrecidos por la nube, por ejemplo servicios de metadata que requieren token.
Añadir autenticación y aislamiento de red a paneles administrativos, bases de datos, cachés y sistemas de monitoreo.

Las reglas de proxy inverso son mitigaciones temporales, no sustituyen la actualización. Una vulnerabilidad del framework debe resolverse finalmente con una versión corregida.

Revisión operativa

Como este problema afecta sobre todo a la confidencialidad, la pregunta clave es si el servidor fue usado para alcanzar recursos internos.

Revisa:

Logs web con Upgrade, Connection, Host, rutas o IPs de origen anómalas.
Logs del proxy inverso o balanceador con WebSocket upgrades inusuales.
Conexiones salientes anómalas cerca del servicio Next.js.
Logs de acceso a metadata cloud o uso de credenciales.
Accesos anómalos a servicios internos de administración, monitoreo, caché o búsqueda.
Uso inusual de credenciales temporales IAM, access keys o tokens.
Procesos, descargas o movimientos laterales sospechosos en contenedores o hosts.

Si sospechas explotación:

Conserva logs y evidencia.
Rota credenciales cloud, API keys, contraseñas de bases de datos y session secrets que pudieran haberse expuesto.
Revisa llamadas API recientes en la cuenta cloud.
Comprueba registros de acceso a servicios internos.
Reconstruye contenedores o hosts afectados.
Revisa controles de egress y protección de metadata.

No es lo mismo que el RCE de React/Next.js

Un punto fácil de confundir: CVE-2026-44578 es un SSRF en WebSocket upgrade de Next.js, no el RCE previo relacionado con React Server Components.

Su impacto central es hacer que el servidor solicite direcciones internas o externas elegidas por el atacante. El riesgo principal es exposición de información y exploración de recursos internos.

Los problemas RCE de React Server Components son riesgos de ejecución de código, con consecuencias y rangos de parche distintos.

Por eso no basta con leer “Next.js tiene una vulnerabilidad”. Hay que mapear el CVE concreto con versiones afectadas, modelo de despliegue y versiones corregidas.

Equipos que deben priorizarlo

Prioridad máxima:

Sitios Next.js de producción autoalojados.
Despliegues en VMs cloud, contenedores, Kubernetes o redes internas.
Servidores de aplicación que pueden acceder a servicios de metadata cloud.
Servidores de aplicación que alcanzan paneles internos, bases de datos, cachés o monitoreo.
Origin servers next start expuestos directamente.
Versiones antiguas de next sin proceso claro de actualización.

Prioridad relativamente menor:

Aplicaciones desplegadas completamente en Vercel.
Aplicaciones ya actualizadas a versiones corregidas.
Origins no expuestos directamente, con la capa de entrada bloqueando WebSocket upgrades innecesarios.
Control estricto de salida que impide alcanzar recursos internos sensibles.

Pero “menor prioridad” no significa que no haya que actualizar. Next.js es un componente muy expuesto, y mantener versiones antiguas del framework acumula riesgo.

Checklist para equipos de desarrollo

Puedes seguir esta lista:

Confirmar la versión de next en todos los repositorios.
Identificar todos los despliegues autoalojados, no solo los proyectos en Vercel.
Marcar servicios que usan next start o el servidor Node.js integrado.
Actualizar a 15.5.16, 16.2.5 o posterior.
Reconstruir y publicar imágenes de producción.
Bloquear WebSocket upgrades innecesarios en la capa de entrada.
Restringir acceso de servidores de aplicación a metadata cloud y rangos internos sensibles.
Revisar solicitudes upgrade anómalas recientes y acceso saliente.
Rotar credenciales que pudieran haberse expuesto.
Incluir actualizaciones de seguridad de Next.js en el proceso de actualización de dependencias.

Resumen

CVE-2026-44578 es una vulnerabilidad SSRF de alta gravedad en Next.js que merece atención rápida.

No afecta a despliegues alojados en Vercel, pero sí cubre muchas aplicaciones Next.js autoalojadas: desde 13.4.13 hasta antes de 15.5.16, y desde 16.0.0 hasta antes de 16.2.5. El punto de activación está en el manejo de WebSocket upgrade. Un atacante puede hacer que el servidor proxifique solicitudes hacia direcciones internas o externas, exponiendo servicios internos o endpoints de metadata cloud.

La corrección directa es actualizar a 15.5.16 o 16.2.5. Las mitigaciones temporales son no exponer directamente el origin server, bloquear WebSocket upgrades innecesarios y restringir el tráfico saliente del servidor de aplicación.

Para equipos de operaciones, lo importante no es solo la puntuación CVE, sino qué puede alcanzar tu servidor Next.js desde su posición en la red. En SSRF, el impacto real suele depender de los recursos internos y permisos cloud detrás del servidor.

Referencias:

SSRF on KnightLi Blog