CVE-2025-67779: El parche de Next.js que necesitaba otro parche

Actualizaste Next.js. Viste el aviso de seguridad de React2Shell, corriste npm install next@latest, hiciste el deploy, y seguiste adelante. Listo. Ya estabas protegido.

O eso creías.

Lo que pasó en los meses siguientes a React2Shell (CVE-2025-55182) es un ejemplo textbook de algo que le pasa más seguido de lo que los vendors admiten: el parche está incompleto. Los investigadores encuentran una variante. Sale otro CVE. Developers que ya actualizaron se enteran, semanas después, de que en realidad nunca terminaron de tapar el hueco. CVE-2025-67779 es el tercero en esta cadena — el parche del parche del parche.

Si usás Next.js App Router y no revisaste tu versión en los últimos meses, este artículo es para ti.

La cadena de tres CVEs, en términos simples

Cuando salió React2Shell, el mundo de Next.js entró en modo pánico. CVSS 10. Ejecución remota de código. Sin autenticación. Todo. El equipo de Vercel/Next.js respondió rápido, lanzó un fix, y la mayoría de la comunidad actualizó y siguió adelante.

El problema: el fix inicial fue validado para bloquear el vector de ataque original. Pero los investigadores siguieron probando las versiones parcheadas. Y encontraron que algo seguía roto — solo que de otra forma.

La secuencia completa quedó así:

Tres CVEs. Cada uno encontrado en el intento de corregir el anterior. La versión que finalmente cierra toda la cadena es la misma: 14.2.35+ o 15.2.4+. Pero hay una ventana de tiempo en la que developers que ya habían actualizado estaban corriendo versiones con CVE-2025-55184 o CVE-2025-67779 sin saberlo.

Qué corrigió CVE-2025-55184 — y qué dejó abierto

El fix para React2Shell modificó cómo el App Router maneja ciertos tipos de peticiones durante el procesamiento de Server Functions. La idea era cortar el vector de deserialización que permitía la ejecución de código arbitrario.

Lo que el fix no contempló bien: un atacante podía enviar peticiones con una estructura específica que ponía al worker del App Router en un loop de procesamiento. No era ejecución de código. Era algo más sutil: el servidor seguía intentando manejar la petición, consumiendo CPU y memoria, sin terminar ni responder.

Eso es CVE-2025-55184 — una vulnerabilidad de denegación de servicio (DoS) en el parche mismo. Un atacante con suficientes requests concurrentes podía degradar o tirar completamente una instancia de Next.js App Router.

El fix para CVE-2025-55184 ajustó la lógica de manejo de esas peticiones problemáticas. Cortó el loop. Pero no del todo.

Qué cambió en CVE-2025-67779

CVE-2025-67779 es otra variante DoS. Misma familia, distinto vector de entrada.

El segundo fix introdujo una condición de error que en ciertos casos no terminaba de limpiar el estado interno del request handler. Con una secuencia de peticiones diseñada para explotar esa condición, un atacante podía causar el mismo efecto que CVE-2025-55184: acumulación de recursos sin liberación, degradación de rendimiento, y eventual falla del servidor bajo carga.

La diferencia con CVE-2025-55184 no es dramática desde afuera. Ambas son DoS. Ambas apuntan al App Router. Ambas requieren que el servidor esté accesible públicamente. Pero son superficies de ataque distintas — por eso necesitaron dos CVEs separados.

Lo que importa en la práctica:

# Si tu versión está en este rango, sos vulnerable a CVE-2025-67779
# Next.js 14.x: cualquier versión antes de 14.2.35
# Next.js 15.x: cualquier versión antes de 15.2.4
 
# Esto incluye versiones que ya corregían React2Shell,
# como 14.2.33 o 14.2.34 — que solucionaban CVE-2025-55182
# pero todavía tenían CVE-2025-55184 o CVE-2025-67779

Si actualizaste cuando salió React2Shell pero quedaste en una versión intermedia, es posible que hayas cruzado un CVE pero seguido expuesto al siguiente.

La versión que realmente lo corrige todo

Next.js 14.2.35 y 15.2.4 son las versiones que cierran la cadena completa. Las tres vulnerabilidades — CVE-2025-55182, CVE-2025-55184, y CVE-2025-67779 — están corregidas en estas releases.

No hay una versión "parcialmente segura" que valga la pena mantener. Si estás en 14.x, necesitás 14.2.35 o más nuevo. Si estás en 15.x, necesitás 15.2.4 o más nuevo.

Un dato importante: Next.js 13 y versiones anteriores están fuera de soporte activo. Si estás en Next.js 13 con App Router, no vas a recibir fixes de seguridad. La recomendación es migrar a 14.2.35+ o 15.2.4+. Si eso no es posible en el corto plazo, evaluar si podés desactivar features de Server Functions hasta migrar.

Por qué es fácil perderse esta actualización

El problema de los parches incompletos no es técnico — es de fatiga.

Cuando React2Shell salió, la urgencia era clara. CVSS 10. RCE. Todos actualizaron rápido. Pero CVE-2025-55184 y CVE-2025-67779 son denegaciones de servicio. Severidad más baja. Menos cobertura mediática. Menos sensación de urgencia.

El ciclo típico de alguien que se perdió la segunda o tercera actualización fue más o menos este:

1. Recibió el aviso de React2Shell. Actualizó rápido a, digamos, 14.2.31.
2. Semanas después sale CVE-2025-55184. El aviso llegó como una notificación de GitHub Dependabot, o como un post en la comunidad. Tal vez no lo vio. Tal vez lo vio y lo anotó para después.
3. Antes de que actualizara, salió CVE-2025-67779. Ahora hay dos CVEs pendientes en su versión.
4. Recién hoy, leyendo este artículo, se está enterando de que no alcanzó con actualizar una vez.

Esto pasa. No es negligencia. Es la realidad de mantener proyectos cuando hay otras cosas que hacer.

Lo que complica más el panorama: si usás un monorepo o heredaste un proyecto con muchas dependencias, npm install next@latest puede traer conflictos que te hacen postergarlo. Y mientras lo postponés, tu app sigue expuesta.

Cómo verificar y corregir ahora mismo

Primero, revisá qué versión de Next.js estás corriendo:

npm list next

La salida debería verse algo así:

mi-proyecto@1.0.0 /ruta/a/tu/proyecto
└── next@14.2.31  # <-- si ves algo menor a 14.2.35, necesitás actualizar

Si estás en 14.x por debajo de 14.2.35, o en 15.x por debajo de 15.2.4, actualizá:

# Para la línea 14.x
npm install next@14.2.35
 
# Para la línea 15.x
npm install next@15.2.4
 
# O simplemente latest si no tenés restricciones de versión
npm install next@latest

Después del update, verificá de nuevo:

npm list next

Y revisá que tu package.json refleje la versión correcta:

{
  "dependencies": {
    "next": "^14.2.35"
  }
}

Ojo con el caret (^): ^14.2.35 permite actualizaciones automáticas a futuras versiones 14.x, lo cual en general es lo que querés para recibir patches de seguridad. Si tenés ~14.2.35 o la versión exacta sin prefijo, solo recibirás patches de patch-level, no minor releases.

Si tu app está en producción y querés confirmar que el update está activo, podés verificar la versión en runtime:

// pages/api/version.ts o app/api/version/route.ts
// Solo para verificación interna — no expongas esto en producción
import { NextResponse } from 'next/server'
 
export async function GET() {
  const { version } = await import('next/package.json')
  return NextResponse.json({ nextVersion: version })
}

Si querés un escaneo más completo — uno que revise tu repo en busca de dependencias desactualizadas, CVEs conocidos, y otros problemas de seguridad sin buscar manualmente CVE por CVE — Data Hogo hace exactamente eso. Conectás tu repo, el scanner revisa todo, y te dice qué está desactualizado y por qué importa.

TL;DR

• CVE-2025-67779 es el tercer CVE en una cadena que empezó con React2Shell (CVE-2025-55182).
• El primer parche para React2Shell introdujo CVE-2025-55184 (DoS por loop infinito). El fix de ese introdujo CVE-2025-67779 (otra variante DoS).
• Si actualizaste una vez cuando salió React2Shell pero no volviste a actualizar, es probable que sigas siendo vulnerable.
• Las versiones que cierran toda la cadena son Next.js 14.2.35+ o 15.2.4+.
• Correr npm list next te dice en qué versión estás. Si es menor a esas, npm install next@latest lo soluciona.
• Las vulnerabilidades DoS no tienen la urgencia de un CVSS 10, pero siguen siendo explotables. Un atacante puede tirar tu servidor desde afuera sin necesidad de autenticación.