NextSteps
React Seguridad Next.js

React2Shell: La vulnerabilidad RCE crítica que todo desarrollador de Next.js debe abordar ahora

Martin Rojas
9 min de lectura
React2Shell: La vulnerabilidad RCE crítica que todo desarrollador de Next.js debe abordar ahora

Análisis crítico de React2Shell (CVE-2025-55182), la vulnerabilidad RCE CVSS 10.0 que afecta a React Server Components y Next.js 15-16.

Has construido tu aplicación Next.js usando el App Router, la has desplegado a producción y has pasado a la siguiente funcionalidad. Entonces llegó el 4 de diciembre. Se publicaron exploits para React2Shell —una vulnerabilidad crítica de ejecución remota de código (RCE) que afecta a los React Server Components— y en pocas horas, actores de amenazas patrocinados por estados estaban atacando activamente aplicaciones vulnerables. Si tu aplicación de producción Next.js está ejecutando versiones de la 15.0.0 a la 16.0.6, es posible que ya estés comprometido.

Esto no es una hipérbole. El CVE-2025-55182 tiene la puntuación máxima CVSS de 10.0, no requiere autenticación y puede activarse con una sola solicitud HTTP contra las configuraciones predeterminadas de Next.js. Los investigadores de seguridad reportan tasas de éxito de explotación cercanas al 100%, y los proveedores de seguridad en la nube han observado campañas de criptominería, robo de credenciales y backdoors persistentes desplegados a través de esta vulnerabilidad a pocos días de su divulgación pública.

Repasemos qué está sucediendo bajo el capó, cómo determinar si estás afectado y los pasos inmediatos que debes tomar para asegurar tus aplicaciones.

Entendiendo la superficie de ataque

Los React Server Components introdujeron un protocolo de comunicación llamado “Flight” que maneja la serialización y deserialización entre el servidor y el cliente. Cuando tu aplicación Next.js procesa envíos de formularios o llamadas a funciones de servidor, utiliza este protocolo para decodificar las cargas de datos (payloads) entrantes. La vulnerabilidad reside en cómo la lógica de deserialización de React maneja cargas malformadas —específicamente, cómo recorre las cadenas de prototipos (prototype chains) al resolver referencias.

El mecanismo técnico implica la manipulación de referencias de fragmentos (chunks) especiales en datos de formularios multiparte. El protocolo Flight de React utiliza cadenas con prefijo $ para activar comportamientos específicos y resolver referencias. Al crear cargas con referencias __proto__, constructor y prototype cuidadosamente construidas, los atacantes pueden escapar de los límites de objeto previstos y ejecutar JavaScript arbitrario en tu servidor.

Lo que hace que esto sea particularmente severo es la exposición predeterminada. Un proyecto estándar generado con create-next-app usando la configuración recomendada habilita el App Router, que incluye React Server Components y expone los puntos finales vulnerables —incluso si tu aplicación no utiliza explícitamente funciones de servidor. La mera presencia del soporte para RSC crea la superficie de ataque.

Así se ve el flujo de ataque:

Atacante crea solicitud POST multipart/form-data maliciosa
    ↓
La solicitud llega al servidor Next.js con ruta habilitada para RSC
    ↓
El protocolo Flight deserializa la carga
    ↓
El recorrido de la cadena de prototipos activa ejecución de código arbitrario
    ↓
El atacante tiene RCE del lado del servidor con privilegios de aplicación

Desde ese punto inicial, se ha observado a atacantes filtrando variables de entorno (incluyendo credenciales de bases de datos y claves de API), instalando criptomineros, estableciendo reverse shells y desplegando puertas traseras (backdoors) persistentes.

¿Estás afectado? Lista de verificación de evaluación

La vulnerabilidad afecta a estos paquetes y versiones específicos:

Paquetes de React (CVE-2025-55182):

  • react-server-dom-webpack: versiones 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-parcel: versiones 19.0.0, 19.1.0, 19.1.1, 19.2.0
  • react-server-dom-turbopack: versiones 19.0.0, 19.1.0, 19.1.1, 19.2.0

Next.js (identificado como GHSA-9qr9-h5gf-34mp):

  • Todas las versiones estables desde la 15.0.0 hasta la 16.0.6
  • Versiones canary 14.3.0-canary.77 y posteriores
  • Versiones canary anteriores a la 15.6.0-canary.58

Otros frameworks afectados que usan React Server Components:

  • react-router (con APIs RSC inestables)
  • waku
  • @parcel/rsc
  • @vitejs/plugin-rsc
  • rwsdk

Para verificar rápidamente tu versión desplegada, abre la consola de desarrollador del navegador en cualquier página de tu aplicación y ejecuta:

// Retorna tu versión de Next.js desplegada
next.version;

O revisa tu package.json y el archivo de bloqueo (lockfile):

# Revisar package.json
cat package.json | grep '"next"'

# Revisar la versión real resuelta en el lockfile
npm ls next
# o
yarn why next
# o
pnpm why next

Los usuarios de Vercel deberían ver un banner en el tablero si los despliegues de producción están ejecutando versiones vulnerables. Sin embargo, no confíes únicamente en esto —verifica tus versiones directamente.

Importante: Las aplicaciones son vulnerables incluso si no usan explícitamente funciones de servidor, siempre que soporten React Server Components. Si tu aplicación Next.js usa el App Router (tiene un directorio app/), debes asumir vulnerabilidad a menos que estés ejecutando una versión parchada.

Pasos inmediatos de remediación

Paso 1: Identifica tu versión actual y ruta de actualización

Consulta esta tabla para encontrar tu versión parchada específica:

Versión actualActualizar a
Next.js 15.0.x15.0.5
Next.js 15.1.x15.1.9
Next.js 15.2.x15.2.6
Next.js 15.3.x15.3.6
Next.js 15.4.x15.4.8
Next.js 15.5.x15.5.7
Next.js 16.0.x16.0.7
Next.js 14 canaries (≥14.3.0-canary.77)Degradado a 14.2.x estable
Next.js 15 canaries (<15.6.0-canary.58)15.6.0-canary.58 o posterior

Paso 2: Aplica el parche

Vercel ha lanzado una utilidad de reparación automática. En la raíz de tu proyecto:

npx fix-react2shell-next

Esto escanea tu proyecto en busca de paquetes vulnerables y los actualiza a las versiones parchadas. Para actualizaciones manuales:

# Actualizar package.json a la versión parchada
npm install next@15.3.6  # Reemplaza con tu versión objetivo

# Asegurar que el lockfile esté actualizado
npm install

# Verificar la actualización
npm ls next

Crítico: Siempre realiza el commit de los cambios del lockfile junto con los de package.json. Los lockfiles desalineados son una fuente común de parches fallidos.

Paso 3: Despliega inmediatamente

Una vez probado localmente, despliega sin demora:

# Vercel CLI
vercel --prod

# O haz push para activar CI/CD
git add package.json package-lock.json
git commit -m "fix: parche para vulnerabilidad React2Shell (CVE-2025-55182)"
git push origin main

Paso 4: Rota todos los secretos

Este es el paso que los equipos a menudo omiten —no lo hagas—. Si tu aplicación era accesible públicamente y no estaba parchada el 4 de diciembre de 2025 a la 1:00 PM PT (cuando surgieron los exploits públicos), asume que tus variables de entorno han sido comprometidas. Rota en orden de prioridad:

  1. Credenciales de bases de datos
  2. Claves de API de terceros (Stripe, SendGrid, AWS, etc.)
  3. Secretos de cliente OAuth
  4. Claves de firma JWT
  5. Tokens de autenticación de servicios internos

Para despliegues en Vercel, su documentación sobre rotación de secretos proporciona un enfoque sistemático. El proceso implica generar nuevas credenciales en cada servicio, actualizar tus variables de entorno de Vercel, volver a desplegar e invalidar las credenciales antiguas.

Detección post-explotación

Determinar si tu aplicación fue explotada no es sencillo. Sin embargo, varios indicadores justifican una investigación:

Análisis de logs: Revisa los registros de la aplicación en busca de solicitudes POST inusuales, particularmente a rutas que no configuraste explícitamente. Busca:

  • Solicitudes multipart/form-data inesperadas
  • Solicitudes con encabezados content-type malformados o sospechosos
  • Picos en errores 500 desde rutas RSC
  • Patrones de tiempo de espera de funciones (timeout)

Anomalías en tiempo de ejecución:

  • Procesos inesperados ejecutándose en tu entorno de contenedores
  • Conexiones de red inusuales a hosts externos
  • Consultas DNS a dominios desconocidos
  • Picos de uso de CPU inconsistentes con los patrones de tráfico

Comportamientos comunes observados tras la explotación:

  • Intentos de acceder a servicios de metadatos en la nube (169.254.169.254)
  • Exfiltración de variables de entorno
  • Instalación de criptomineros (a menudo disfrazados como procesos del sistema como systemd-devd)
  • Establecimiento de reverse shells
  • Tareas cron o reiniciadores de procesos persistentes

Si identificas actividad sospechosa, trátala como una brecha confirmada: aisla los sistemas afectados, preserva los logs para análisis forense y activa tus procedimientos de respuesta ante incidentes.

Defensa en profundidad: Protecciones adicionales

Aunque el parche es la única solución completa, las defensas por capas proporcionan margen de maniobra:

Reglas de Firewall de Aplicaciones Web (WAF): Los principales proveedores de WAF han desplegado reglas que apuntan a patrones de explotación conocidos. Vercel aplicó mitigaciones de WAF a nivel global antes de la divulgación pública, el AWSManagedRulesKnownBadInputsRuleSet de AWS WAF incluye reglas para CVE-2025-55182, y Cloudflare, Fastly y otros proveedores tienen protecciones similares. Ten en cuenta que las reglas de WAF no pueden garantizar la protección contra todas las variantes —son un paliativo, no una solución—.

Protección de despliegue: Habilita la autenticación para despliegues que no sean de producción. En Vercel, la Standard Protection previene el acceso no autorizado a los despliegues de vista previa (preview deployments). Audita cualquier enlace compartible que evada la protección de despliegue.

Segmentación de red: Limita la conectividad saliente desde los contenedores de la aplicación siempre que sea posible. Esto restringe la capacidad de un atacante para filtrar datos o establecer canales de comando y control incluso si logra la ejecución de código.

Lo que esto significa para los React Server Components

Esta vulnerabilidad revela un desafío fundamental con la deserialización de JavaScript del lado del servidor. La complejidad del protocolo Flight creó oportunidades para ataques de contaminación de prototipos (prototype pollution) —una clase de vulnerabilidad que es notoriamente difícil de eliminar por completo en JavaScript—. El equipo de React merece crédito por su rápida respuesta, pero este incidente plantea preguntas para los equipos que evalúan la adopción de RSC.

Para aplicaciones Next.js existentes: el App Router y los React Server Components siguen siendo herramientas potentes para construir aplicaciones de alto rendimiento. Las versiones parchadas abordan la falla de deserialización específica. Continúa usando RSC con confianza una vez que hayas actualizado.

Para equipos que evalúan nuevos proyectos: esta vulnerabilidad no debería disuadirte de usar React Server Components, pero es un recordatorio de que el renderizado del lado del servidor introduce riesgos del lado del servidor. Factoriza el monitoreo de seguridad y los procedimientos de actualización en tu planificación arquitectónica.

Próximos pasos para tu equipo

  1. Inmediato (hoy): Verifica que todas las aplicaciones de producción Next.js ejecuten versiones parchadas. Despliega soluciones para las que no lo hagan.
  2. Esta semana: Rota los secretos para cualquier aplicación que pueda haber estado expuesta. Revisa los logs en busca de indicadores de compromiso.
  3. Este mes: Audita la configuración de protección de despliegue. Asegura que los entornos de vista previa y staging no sean accesibles públicamente sin autenticación.
  4. Continuo: Establece un proceso de actualización de seguridad. Esta no será la última vulnerabilidad crítica de un framework, y el tiempo de respuesta importa.

El desarrollo de una respuesta de seguridad ágil en tu flujo de trabajo ya no es opcional.

Fuentes