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 autorreferencial (then)

El then: "$1:__proto__:then" crea una autorreferencia 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) utiliza this._response - el _response falso del atacante:```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Etapa 1: El then autorreferencial del objeto externo activa el procesamiento por fragmentos

Etapa 2: Cuando React resuelve el modelo, analiza value y se encuentra con otro thenable con then: "$B1337". El prefijo $B activa 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, lo que permite que la ejecución alcance el controlador vulnerable $B.

Rutas de Código Vulnerables

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

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

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

2. Verificación de hasOwnProperty en getOutlinedModel() - Bloquea el recorrido de prototipos ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

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

4. Verificación de tipos 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), versiones canary 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 WAF basada en firmas

Esta sección explica por qué las reglas WAF tradicionales de coincidencia de patrones no pueden detectar de forma fiable este exploit. Comprender estas limitaciones es esencial para los equipos de seguridad que evalúan su postura defensiva.

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

El payload del exploit pasa por múltiples analizadores, cada uno con soporte de codificación diferente. Un WAF que inspecciona bytes HTTP crudos 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é tendrían que coincidir las firmas

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 incluso 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 matrices numéricas (S(99,104,105,108,100,95,...) para child_process)
• El payload bruto no contiene ninguna palabra clave reconocible

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 importa para los defensores

1. Las reglas basadas en firmas generan falsa confianza - El payload llega al servidor sin ser detectado
2. La codificación es infinita - Cada carácter puede escaparse de forma diferente; las regex 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 peticiones de Server Actions. Aunque los nombres de cabecera no pueden codificarse en unicode (RFC 7230 exige tokens ASCII), las diferencias de normalización entre el WAF y el servidor crean brechas de detección:

Recomendaciones defensivas

Aplicar parches es la única mitigación fiable. Las reglas WAF no pueden bloquear de forma exhaustiva 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 parcheo se retrasa, considera:

1. Decodificar antes de buscar coincidencias - El WAF debe decodificar \uXXXX, \xXX y normalizar las llamadas a 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 de minúsculas y recortando espacios
4. Bloquear Server Actions - Si no se utilizan Server Actions, bloquear por completo las peticiones con la cabecera Next-Action
5. Monitorización 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á frente a esta clase de ataque. La superficie de codificación es demasiado extensa para enumerarla.

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

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

Límites de inspección del cuerpo

AWS WAF solo inspecciona una parte del cuerpo de la petición:

El problema de OversizeHandling

Las reglas WAF especifican cómo manejar las peticiones que superan los límites de inspección:

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

Estrategia de bypass: relleno antes del payload

Coloca datos de relleno inofensivos antes del payload del exploit 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 en 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 de los WAF

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

Recomendaciones de mitigación

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

Esto bloquea cualquier solicitud que supere 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) Configura hasta 64KB en los ajustes de la ACL web, pero esto no previene completamente el bypass.

3. Agregar regla de bloqueo basada en tamaño Bloquear solicitudes POST con cabecera Next-Action que superen un tamaño razonable (p. ej., 10KB).

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

Scripts de Prueba

Consulte los scripts de prueba incluidos:

• test-simple.cjs - Prueba de carga útil no fragmentada de referencia
• test-oversize.cjs - Prueba tamaños de relleno de 0 a 128KB
• 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 por 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 Probamos

Si bien obtuvimos Function, lograr RCE requiere invocarla con argumentos controlados. Estas rutas 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 (Bloqueada)```javascript // Function.bind(null, code) needs TWO calls to execute // React only calls iterator once // Result: Returns bound function, doesn't execute