CVE-2025-55184: El DoS de loop infinito en Next.js que llegó con el parche de React2Shell

Actualizaste Next.js por el motivo correcto. CVE-2025-55182 — React2Shell — era un RCE con CVSS 10. Ejecución remota de código. Sin autenticación. Una sola petición. No había excusa para no parchear.

Lo parcheaste. Hiciste bien. Cerraste la pestaña y seguiste trabajando.

El problema es lo que venía incluido en ese parche. CVE-2025-55184 es una vulnerabilidad de denegación de servicio en el App Router de Next.js que apareció exactamente en las versiones que supuestamente te protegían de React2Shell. No fue un bug independiente que alguien encontró después. Fue introducido durante el proceso de corrección del RCE. Lo que intentó ser un fix también abrió una puerta diferente.

Y esta puerta es peculiar. No hace crash tu servidor. No lanza un 500. El proceso sigue vivo. Sigue corriendo. Solo que deja de hacer absolutamente nada.

El parche que trajo un problema nuevo

Cuando el equipo de Next.js lanzó el fix para React2Shell, los investigadores no dejaron de mirar. Siguieron probando las versiones parcheadas y encontraron que ciertas peticiones HTTP diseñadas maliciosamente podían activar un comportamiento anómalo en el manejo de solicitudes del App Router.

El resultado: un loop infinito en el runtime.

Node.js es de un solo hilo. Cuando su event loop — el mecanismo central que procesa todas las peticiones entrantes, callbacks y operaciones asíncronas — queda atrapado en un ciclo que nunca termina, no hay un segundo hilo que lo rescate. Todo lo demás se detiene también.

No es exageración. Una sola petición maliciosa contra una instancia afectada puede dejar sin servicio a todos los usuarios que la comparten.

CVE-2025-55184 es una vulnerabilidad de denegación de servicio (DoS). No requiere autenticación. No requiere conocer rutas específicas de tu app. Solo requiere que estés corriendo una versión de Next.js en el rango afectado.

Qué pasa realmente cuando se activa

El atacante manda una petición HTTP diseñada hacia cualquier ruta del App Router. El manejo de solicitudes interno de Next.js entra en un loop de procesamiento que nunca encuentra una condición de salida.

El event loop de Node.js queda bloqueado procesando esa operación. Las peticiones nuevas entran a la cola. La cola crece. La memoria sube.

Lo que ves desde afuera:

• Las respuestas dejan de llegar. Los usuarios ven un spinner infinito o un timeout del navegador.
• No hay logs de error. No hay excepción. El proceso no reporta ningún problema.
• El dashboard de Vercel o tu monitor de infraestructura muestra el proceso como "activo".
• En Vercel: el timeout de función serverless eventualmente entra. La función muere y vuelve a iniciar. Si el atacante sigue mandando peticiones, el ciclo se repite.
• En Node.js auto-hosteado: el proceso se cuelga indefinidamente. Necesitas reiniciarlo manualmente o esperar que tu process manager lo detecte y lo reinicie.

La parte que pone nervioso es el silencio. Un crash con un 503 es raro, pero al menos es diagnosticable. Un servidor que se ve sano pero no responde a nada es mucho más difícil de debuggear bajo presión.

Qué versiones están afectadas

El rango afectado son las versiones que Next.js lanzó como fix para CVE-2025-55182, antes de que corrigieran también este bug.

Si nunca actualizaste para React2Shell, también estás expuesto a ese RCE — así que en cualquier caso la respuesta es la misma: actualiza a 14.2.35+ o 15.2.4+.

Para revisar tu versión actual:

# Verificar tu versión instalada
npm list next

Si el output muestra algo por debajo de los números seguros, el fix es directo:

# Actualizar a la versión segura en la línea 15.x
npm install next@15.2.4
 
# O si estás en la línea 14.x
npm install next@14.2.35

Después de instalar, verifica que quedó bien:

# Confirmar la versión activa
npm list next

Si querés evitar hacer esto manualmente cada vez que sale un CVE nuevo, Data Hogo escanea tus dependencias automáticamente y te avisa cuando una versión instalada cae en un rango vulnerable conocido — incluyendo casos como este donde el rango afectado es una ventana específica entre dos parches.

Por qué el vibe coding es más vulnerable

Hay un patrón que vemos en muchos proyectos: se actualiza el framework una vez cuando hay un CVE ruidoso (CVSS 10, RCE, mucho ruido en Twitter), y después las dependencias se quedan quietas por meses.

Eso es exactamente el escenario que crea este tipo de exposición. Actualizaste para React2Shell. Instalaste una versión del rango afectado por CVE-2025-55184. Y si no había un segundo alerta sonando, probablemente no volviste a revisar.

Los proyectos generados con IA tienen este problema más seguido. El asistente genera el código, configura el package.json con las versiones del momento, y después nadie toca esas versiones hasta que algo se rompe o hay una alerta grande. Las vulnerabilidades que viven entre dos parches — como esta — son las que se escapan.

No es negligencia. Es que el ciclo de actualización manual no escala cuando estás construyendo rápido y solo.

La respuesta práctica es simple: después de parchear un CVE crítico, asumí que los investigadores siguen mirando las versiones parcheadas. Espera más hallazgos. El historial de React2Shell — que derivó en CVE-2025-55184 y luego en CVE-2025-67779 — es un recordatorio de que los parches raramente son la última palabra.

TL;DR

• CVE-2025-55184 es una vulnerabilidad de denegación de servicio en Next.js App Router descubierta en las mismas versiones que corregían React2Shell (CVE-2025-55182).
• Una petición HTTP maliciosa activa un loop infinito que bloquea el event loop de Node.js — todas las peticiones concurrentes dejan de recibir respuesta.
• El servidor no crashea ni lanza errores. Parece sano. Solo que no hace nada.
• En Vercel, el timeout de función serverless eventualmente lo interrumpe. En servidores propios, el proceso se cuelga hasta que lo reiniciás.
• El fix: actualizar a Next.js 14.2.35+ o 15.2.4+.
• Si actualizaste para React2Shell pero no llegaste a estas versiones, todavía estás en el rango afectado.
• Ejecuta npm list next ahora mismo para verificar.