CVE-2025-55182-research

Analisi tecnica proof-of-concept e approfondimento di CVE-2025-55182, una vulnerabilità RCE critica nel Flight Protocol di React tramite path traversal, iniezione di chunk falsi e abuso del gestore $B.

Flusso di sfruttamento```

┌─────────────────────────────────────────────────────────────────────┐ │ 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-referenziale (then)

Il then: "$1:__proto__:then" crea un auto-riferimento che risolve a una funzione reale:``` $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 - il falso _response dell'attaccante:```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Fase 1: Il then auto-referenziale dell'oggetto esterno attiva l'elaborazione dei chunk

Fase 2: Quando React risolve il modello, analizza value e incontra un altro oggetto thenable con then: "$B1337". Il prefisso $B attiva l'handler:```javascript case "B": return response._formData.get(response._prefix + obj); // obj = "1337"

Il codice interno di React può accedere a response._chunks.get() o response._chunks.has() durante l'elaborazione. Una Map vuota soddisfa queste chiamate senza errori, consentendo all'esecuzione di raggiungere il gestore vulnerabile $B.

Percorsi di codice vulnerabili

decodeReply() è il punto di ingresso, non è di per sé vulnerabile.

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. Controllo hasOwnProperty in getOutlinedModel() - Blocca l'attraversamento del prototipo ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. Gestione di __proto__ in reviveModel() - Previene l'inquinamento del prototipo ```javascript void 0 !== parentObj || "proto" === i ? (value[i] = parentObj) : delete value[i];
   root@kitploit:~

4. Controllo del tipo in initializeModelChunk() - Valida i listener ```javascript "function" === typeof listener ? listener(value) : fulfillReference(response, listener, value);
   root@kitploit:~

Impatto e Versioni

Valutazione dell'Impatto

Versioni interessate

• react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack: Stesse versioni
• Next.js: 15.x, 16.x (prima delle patch), canary da 14.3.0-canary.77+

Versioni corrette

• 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+

Perché il rilevamento WAF basato su firme fallisce

Questa sezione spiega perché le tradizionali regole WAF basate sul pattern matching non possono rilevare in modo affidabile questo exploit. Comprendere questi limiti è essenziale per i team di sicurezza che valutano la propria postura difensiva.

Il problema principale: codifica a più livelli

Il payload dell'exploit attraversa più parser, ciascuno con un diverso supporto di codifica. Un WAF che ispeziona i byte HTTP grezzi vede stringhe codificate, ma il server le decodifica prima di elaborarle:

Questo crea una discrepanza fondamentale: il WAF vede byte codificati, ma l'applicazione vede stringhe decodificate.

Cosa dovrebbero intercettare le firme

Un WAF ingenuo potrebbe cercare pattern come constructor, __proto__, resolved_model o child_process. Tuttavia, JSON consente escape unicode per qualsiasi carattere:

Il codice JavaScript all'interno del payload ha ancora più opzioni di codifica:

Il divario di rilevamento

Quando tutte le tecniche di codifica vengono combinate:

• Le chiavi JSON diventano sequenze unicode (\u0074\u0068\u0065\u006e per then)
• Gli identificatori JS diventano array numerici (S(99,104,105,108,100,95,...) per child_process)
• Il payload grezzo non contiene alcuna parola chiave riconoscibile

Un WAF che analizza il corpo della richiesta HTTP vede solo sequenze di escape e numeri - nulla che corrisponda alle firme di attacco tradizionali.

Perché questo è importante per i difensori

1. Le regole basate su firme danno una falsa sicurezza - Il payload raggiunge il server senza essere rilevato
2. La codifica è infinita - Ogni carattere può essere sottoposto a escape in modo diverso; le regex non possono enumerare tutte le varianti
3. L'attacco è conforme al protocollo - Tutte le codifiche sono JSON/JavaScript validi secondo le specifiche

Considerazioni sul rilevamento nelle intestazioni

L'intestazione Next-Action identifica le richieste Server Action. Sebbene i nomi delle intestazioni non possano essere codificati in unicode (la RFC 7230 richiede token ASCII), le differenze di normalizzazione tra WAF e server creano lacune di rilevamento:

Raccomandazioni difensive

L'applicazione delle patch è l'unica mitigazione affidabile. Le regole WAF non possono bloccare in modo completo questo attacco a causa della flessibilità di codifica.

Versioni richieste:

• 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+

Se l'applicazione delle patch viene ritardata, prendere in considerazione:

1. Decodificare prima del matching - Il WAF deve decodificare \uXXXX, \xXX e normalizzare le chiamate fromCharCode() prima del pattern matching
2. Rilevamento strutturale - Cercare strutture JSON contenenti _response, _prefix, _chunks o riferimenti circolari ($@0)
3. Normalizzazione delle intestazioni - Far corrispondere l'intestazione next-action senza distinzione tra maiuscole e minuscole e con trim degli spazi
4. Bloccare le Server Actions - Se non si utilizzano le Server Actions, bloccare del tutto le richieste con intestazione Next-Action
5. Monitoraggio a runtime - Generare alert sulle chiamate Function() con argomenti stringa dinamici

Concetto chiave: Il solo pattern matching fallirà contro questa classe di attacchi. La superficie di codifica è troppo ampia per essere enumerata.

Bypass dei limiti di ispezione del body di AWS WAF

Anche con regole WAF complete, AWS WAF ha limiti di dimensione per l'ispezione del body che possono essere sfruttati. Questa sezione documenta tecniche di bypass testate utilizzando payload sovradimensionati.

Limiti di ispezione del body

AWS WAF ispeziona solo una parte del corpo della richiesta:

Il problema di OversizeHandling

Le regole WAF specificano come gestire le richieste che superano i limiti di ispezione:

Se la tua regola WAF usa OversizeHandling: CONTINUE (predefinito comune), il bypass è banale.

Strategia di bypass: padding prima del payload

Inserisci dati di riempimento innocui prima del payload exploit in modo che ricada al di fuori della finestra di ispezione:``` ┌─────────────────────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────────────────────┘

Pattern suddiviso tra i blocchi:``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

Considerazioni sul comportamento dei WAF

Nota: AWS WAF in genere riassembla i body chunked prima dell'ispezione. Tuttavia, questo dovrebbe essere verificato per ambiente poiché le configurazioni variano.

Raccomandazioni per la mitigazione

1. Change OversizeHandling to MATCH ```json "OversizeHandling": "MATCH"
   root@kitploit:~

Questo blocca qualsiasi richiesta che supera il limite di ispezione quando le condizioni della regola sono soddisfatte.

2. Aumenta il limite di ispezione del corpo (solo CloudFront/API Gateway) Configura fino a 64KB nelle impostazioni della web ACL, ma questo non previene completamente il bypass.

3. Aggiungi una regola di blocco basata sulla dimensione Blocca le richieste POST con header Next-Action che superano una dimensione ragionevole (es., 10KB).

4. Applica una patch all'applicazione - L'unica soluzione completa.

Script di test

Vedi gli script di test inclusi:

• test-simple.cjs - Test di base del payload non-chunked
• test-oversize.cjs - Testa dimensioni di padding da 0 a 128KB
• test-chunked-v2.cjs - Codifica di trasferimento chunked con divisione $@
• test-chunked-bypass.cjs - Molteplici strategie di chunking (5-byte, 10-byte, divisioni di pattern)

Utilizzo:```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 payload "$1:constructor:constructor":

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

Percorsi bloccati che abbiamo provato

Sebbene abbiamo ottenuto Function, ottenere RCE richiede di chiamarla con argomenti controllati. Questi percorsi hanno fallito:

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

3. Percorso dell'iteratore (Bloccato)```javascript // Function.bind(null, code) needs TWO calls to execute // React only calls iterator once // Result: Returns bound function, doesn't execute