1. Resumen de la vulnerabilidad

Estos días se ha hablado mucho de una vulnerabilidad RCE por deserialización en React, con una puntuación CVSS oficial de 10.0, igual que Log4j en su momento. No pocos rumores la calificaban como el Log4j del frontend moderno, causando pánico entre desarrolladores de muchas empresas. Así que, al despertar, todos estaban revisando documentos y aplicando parches... Al mismo tiempo, también circularon dudas en Internet; algunos probaron la vulnerabilidad y descubrieron que no es tan grave como se decía, sino que requiere ciertas condiciones para su explotación. Por eso, decidí dedicar tiempo a investigar a fondo esta vulnerabilidad.

1.1 Información de la vulnerabilidad

• ID CVE: CVE-2025-55182
• Puntuación CVSS: 10.0 (Crítica)
• Tipo de vulnerabilidad: Contaminación de la cadena de prototipos → Ejecución remota de código
• Versiones afectadas: react-server-dom-webpack < 19.2.0, react-server-dom-turbopack < 19.2.0
• Alcance: Aplicaciones que usan React Server Components

---

2. Análisis del principio de la vulnerabilidad

2.1 Causa raíz de la vulnerabilidad

La causa de esta vulnerabilidad es la siguiente: en [email protected], la función clave del lado del servidor para analizar Server Actions es requireModule (seudocódigo):

function requireModule(metadata) {
  var moduleExports = __webpack_require__(metadata[0]);
  // ...
  return "*" === metadata[2]
    ? moduleExports
    : "" === metadata[2]
      ? moduleExports.__esModule
        ? moduleExports.default
        : moduleExports
      : moduleExports[metadata[2]];  // ← Punto vulnerable
}

2.2 Problema central de la vulnerabilidad

El núcleo del problema está en moduleExports[metadata[2]]; no se valida metadata[2], lo que permite al atacante acceder no solo a las propiedades exportadas del módulo, sino también a propiedades de la cadena de prototipos (como constructor, __proto__, etc.). Cuando el atacante construye metadata[0] (por ejemplo, apuntándolo a vm), puede construir metadata[2] para exportar métodos peligrosos del módulo especificado, como vm.runInThisContext, logrando así la explotación.

---

3. Análisis de explotación de la vulnerabilidad

En mi análisis, me basé en el entorno de prueba y la explotación proporcionados por ejpir, usando como ejemplo el gadget vm_runInThisContext para ejecución de código. El proceso es el siguiente (¡nota: en un entorno real, la explotación puede diferir!).

Paso 1: Recibir la solicitud

Primero, después de enviar una solicitud con el payload, se coloca un punto de interrupción en el lugar donde se recibe la solicitud:

Paso 2: Analizar los datos del formulario

Luego, el programa llega a const formData = parseMultipart(buffer, boundaryMatch[1]);; se ingresa a parseMultipart:

parseMultipart extrae los datos del cuerpo de la solicitud y los devuelve a formData:

Paso 3: Llamar a decodeAction (entrada de la vulnerabilidad)

Se ingresa a const actionFn = await decodeAction(formData, serverManifest); punto donde ocurre la vulnerabilidad:

Se ingresa a loadServerReference:

Paso 4: Código central de la vulnerabilidad – requireModule

Ahora llegamos al código central donde se produce la vulnerabilidad: requireModule; ingresamos:

Devuelve el valor id con # como separador entre módulo y método, y el valor bound como argumento del método:

Paso 5: Ejecutar el payload

Se ingresa a actionFn para ejecutar el payload final:

¡Con esto termina la explotación!

---

4. Resumen y defensa

Esta vulnerabilidad se debe esencialmente a una validación de entrada deficiente, similar a Log4j y fastjson. En mi prueba usé vm_runInThisContext, pero en realidad hay múltiples gadgets explotables, como:

• vm#runInThisContext
• vm#runInNewContext
• child_process#execSync
• child_process#execFileSync
• child_process#spawnSync
• fs#readFileSync
• fs#writeFileSync
• #constructor
• #__proto__
• #prototype

Un atacante puede usar esta vulnerabilidad para lograr:

• Ejecución remota de código (RCE): mediante vm#runInThisContext o child_process#execSync para ejecutar comandos arbitrarios del sistema.
• Operaciones del sistema de archivos: mediante fs#readFileSync y fs#writeFileSync para leer/escribir archivos arbitrarios.
• Ataques persistentes: escribir claves SSH, modificar .bashrc, sobrescribir archivos de la aplicación, etc.
• Fuga de información: leer archivos de configuración sensibles (.env, claves privadas, credenciales de bases de datos, etc.).

Por lo tanto, se pueden proponer las siguientes medidas defensivas:

1. Defensa temporal

Se pueden configurar reglas en el WAF para bloquear estos campos peligrosos y así interceptar ataques maliciosos a tiempo. También se puede hacer coincidencia en Nginx, por ejemplo:

# Configuración de ejemplo en Nginx
location /formaction {
    # Bloquear solicitudes que contengan referencias a módulos peligrosos
    if ($request_body ~* "(vm#|child_process#|fs#|module#)") {
        return 403;
    }
    # Bloquear intentos de contaminación de la cadena de prototipos
    if ($request_body ~* "(#constructor|#__proto__|#prototype)") {
        return 403;
    }
}

2. Actualizar lo antes posible

El equipo oficial ya ha publicado parches de seguridad. ¡Actualice inmediatamente a una versión segura!:

# Actualizar react-server-dom-webpack
npm install react-server-dom-webpack@>=19.2.0

# Actualizar react-server-dom-turbopack
npm install react-server-dom-turbopack@>=19.2.0

# Usuarios de Next.js
npm install next@>=15.0.5

Versiones corregidas:

• react-server-dom-webpack: >= 19.2.0
• react-server-dom-turbopack: >= 19.2.0
• next.js: >= 15.0.5