La última década posicionó a React como uno de los pilares del desarrollo web moderno. Su adopción masiva en SSR, aplicaciones híbridas y arquitecturas distribuidas llevó a millones de equipos a construir sus sistemas sobre su ecosistema.
Pero a inicios de diciembre de 2025, ese ecosistema recibió un golpe inesperado: la revelación pública de React2Shell (CVE-2025-55182), una vulnerabilidad crítica en React Server Components (RSC) evaluada como 10/10 en severidad.

Este incidente obligó a la industria a revisar de inmediato sus estrategias de seguridad, pipelines de despliegue y patrones de SSR.

Qué es React2Shell y por qué es tan grave

React2Shell es una vulnerabilidad de ejecución remota de código (RCE) dentro del protocolo Flight, el mecanismo que React usa para transportar metadatos, instrucciones y representaciones serializadas entre el servidor y el cliente en entornos con Server Components.

En términos prácticos, permitía que un atacante:

Manipulara la serialización de Flight.
Inyectara payloads en la respuesta del servidor.
Forzara al servidor a ejecutar instrucciones arbitrarias.
Afectara aplicaciones construidas sobre Next.js, Remix y cualquier framework que implemente RSC.

Aunque el exploit depende de particularidades del proyecto, el vector principal residía en que Flight asumía que su estructura era confiable, sin sanear correctamente ciertos tipos de datos enviados desde el cliente.

Cómo funciona la falla: el problema en el protocolo Flight

Para entender React2Shell, es clave comprender qué hace Flight:

RSC no envía HTML, sino descripciones serializadas de componentes.
El cliente recibe un stream binario con identificadores de módulos, props y acciones.
Ese stream es interpretado por el runtime del cliente.

El fallo aparece en la forma en que el servidor:

No validaba correctamente objetos que declaraban módulos o acciones, permitiendo que un atacante:

Manipule rutas internas.
Desvíe carga hacia módulos no autorizados.
Inyecte objetos con referencias ejecutables.
Induzca al servidor a evaluar código inesperado.

Ejemplo simplificado del patrón vulnerable

Este no es el exploit original, pero representa el tipo de patrón que permitió React2Shell:

// Ejemplo conceptual (no representa el exploit real)
function processFlightPayload(payload: unknown) {
    // Supuesto: payload siempre proviene del cliente legítimo
    const { moduleId, props } = payload as {
        moduleId: string;
        props: Record<string, unknown>;
    };
 
    // El servidor intenta cargar el módulo solicitado
    const module = require(moduleId); // <- vector crítico
    return module.render(props);
}

Si el atacante logra alterar el moduleId, puede forzar al servidor a cargar módulos internos, ejecutar archivos no destinados a ser expuestos o, en el peor caso, llegar a RCE. Este tipo de patrón existía implícitamente dentro del flujo interno de Flight antes del parche.

Versiones de React relacionadas

La raíz del problema se origina en la implementación de React Server Components y su protocolo de transmisión de datos entre cliente y servidor. Next.js advierte que el fallo se deriva de la vulnerabilidad upstream registrada como CVE-2025-55182 en React, que afecta la forma en que se deserializan datos dentro de RSC.

¿Qué frameworks estaban afectados?

Dado que RSC es un mecanismo compartido, React2Shell impactó a:

Next.js (Vercel)
Remix (Shopify)
Todos los entornos SSR que activaban Server Components

Versiones de Next.js afectadas por esta vulnerabilidad

Según el boletín oficial de seguridad de Next.js, las siguientes versiones están directamente impactadas por la vulnerabilidad relacionada con React Server Components y su implementación en el App Router:

Next.js (ecosistema afectado)

Versiones vulnerables:
Next.js 15.x (todas las releases vulnerables previas al parche)
Next.js 16.x (primeras releases antes del parche)
Next.js 14.3.0-canary.77 y posteriores builds canary relacionadas

Estas ramas del framework incluyen la integración afectada de React Server Components que permite la explotación descrita.

Cómo replicar un escenario vulnerable (ejemplo educativo)

El siguiente caso simula un servidor SSR mal asegurado, donde un usuario autenticado podría manipular la estructura de Flight:

import { parseFlightRequest } from "./flight-parser";
import { executeAction } from "./unsafe-executor";
 
export async function handleRSCRequest(req: Request) {
    const buffer = await req.arrayBuffer();
    const flightData = parseFlightRequest(buffer);
 
    // Supuesto peligroso: acciones declaradas por el cliente son válidas
    if (flightData.action) {
        return executeAction(flightData.action); // <- ejecución arbitraria
    }
 
    return renderRSC(flightData.tree);
}

executeAction() es el punto crítico: antes del parche de React, existían rutas internas que permitían interpretar acciones recibidas desde el cliente sin sanear completamente el origen.

Cómo se corrige el problema: los cambios oficiales

Aunque React no publica versiones explícitas de RSC por separado, las versiones de React que se deben usar como base en conjunto con Next.js parcheado son:

En React y React DOM:

React 19.2.1 o superior (incluye parches de seguridad para RSC)
React DOM 19.2.1 o superior

React introdujo parches que incluyen:

Validación estricta de tipos del protocolo Flight

El servidor ahora rechaza cualquier payload que no cumpla estructuras exactas.

Eliminación de rutas de acción implícitas

Actions ahora deben estar declaradas explícitamente en el servidor.

Aislamiento de módulos sensibles

El runtime de RSC ya no permite cargar módulos arbitrarios.

Verificación criptográfica opcional (dependiendo del framework)

Frameworks como Next.js añadieron verificaciones adicionales dentro del stream.

Estas versiones parcheadas de React corrigen los vectores de deserialización y sanitización que daban lugar a la raíz de la vulnerabilidad. Siempre se recomienda usar la versión mínima corregida o superior.

En Next.js

Lista de versiones parcheadas / seguras:

15.0.5
15.1.9
15.2.6
15.3.6
15.4.8
15.5.7
16.0.7

También hay versiones canary parcheadas:

15.6.0-canary.58
16.1.0-canary.12

Mantener estas versiones o superiores es la forma recomendada de mitigar completamente el riesgo a nivel de framework.

En Vercel

La vía más rápida y directa propuesta por Vercel es ejecutar:

bash

npx fix-react2shell-next

Este comando verificará si tu versión está afectada y te recomendará la actualización corregida.

Este parche agrega:

Sanitización de rutas internas.
Limitación explícita de módulos cargables.
Revisión del parser de Flight.

Ejemplo de implementacion:

import { safeParseFlight } from "react/server-flight";
 
export async function handleRSCRequest(req: Request) {
    const buffer = await req.arrayBuffer();
    const flightData = safeParseFlight(buffer);
 
    // Las acciones ya no pueden ser declaradas desde el cliente
    if (flightData.action) {
        throw new Error("Client-defined actions are not allowed.");
    }
 
    return renderRSC(flightData.tree);
}

El flujo ahora evita:

Carga dinámica no controlada.
Declaración de acciones externas.
Ejecución de módulos no autorizados.

¿Qué deberían hacer las empresas afectadas?

Auditoria interna inmediata

Revisar endpoints SSR.
Confirmar que los servidores se actualizan automáticamente.

Revisión de Actions

Asegurar que ninguna acción depende de input del cliente.
Validar todas las rutas de ejecución con estructuras estáticas.

Endurecimiento del servidor

Aislar módulos críticos.
Implementar sandboxes cuando sea posible.

Monitoreo de tráfico Flight

Agregar validaciones en CDN.
Rechazar payloads con estructuras inesperadas.

¿Qué nos enseña React2Shell sobre el futuro de la web?

React2Shell no es un error aislado: es un síntoma de la complejidad creciente de la web moderna.

La industria avanza hacia:

Componentes del lado del servidor.
Protocolos binarios propietarios.
Arquitecturas híbridas cada vez más sofisticadas.

Con esa complejidad, también aumenta la superficie de ataque.

Este incidente refuerza un principio central:

La seguridad no ocurre sola. Debe diseñarse desde la arquitectura.

Y React2Shell demostró que incluso las plataformas más maduras pueden caer ante una suposición incorrecta en su modelo de confianza.

Conclusión

React2Shell marca un antes y un después en la seguridad del ecosistema React. El incidente obligó a la industria a reevaluar cómo funcionan los protocolos internos, cómo se valida la comunicación cliente-servidor y qué supone realmente "confiar" en datos serializados.

La buena noticia es que la respuesta de React, Vercel y la comunidad fue rápida, coordinada y transparente. La mala noticia es que la web moderna seguirá enfrentando vulnerabilidades de este tipo, porque la innovación avanza más rápido que la estandarización.

La lección es clara: La arquitectura segura ya no es una mejora: es un requisito fundamental.

Referencias

https://react2shell.com/
https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
https://github.com/vercel/next.js/security/advisories/GHSA-9qr9-h5gf-34mp
https://vercel.com/kb/bulletin/react2shell