Exploitation Flow

Key Components

Component Deep Dive

Form Field Structure

The exploit uses three form fields with circular references:

Self-Referential Thenable (then)

The then: "$1:__proto__:then" creates a self-reference that resolves to a real function:

Why this is critical:

1. then resolves to Chunk.prototype.then - a real callable function
2. This makes the fake object a valid thenable
3. When awaited, JS calls obj.then(resolve, reject)
4. Chunk.prototype.then executes with fake object as this:

5. initializeModelChunk(this) uses this._response - the attacker's fake _response:

Without the self-reference, the fake _response would never be used. The self-reference makes Chunk.prototype.then treat the attacker's object as a real Chunk.

Two-Stage Thenable Trigger (value)

The value field contains a nested JSON string with another thenable:

Stage 1: Outer object's self-referential then triggers chunk processing

Stage 2: When React resolves the model, it parses value and encounters another thenable with then: "$B1337". The $B prefix triggers the handler:

_formData.get is "$1:constructor:constructor" → getOutlinedModel() resolves to Function.

This becomes: Function(code + "1337") → valid JS because 1337 is just a trailing expression.

Defensive Padding (_chunks)

The fake _response needs a valid _chunks property to prevent crashes:

React's internal code may access response._chunks.get() or response._chunks.has() during processing. An empty Map satisfies these calls without errors, allowing execution to reach the vulnerable $B handler.

Vulnerable Code Paths

decodeReply() is the entry point, not vulnerable itself.

Path Traversal (getOutlinedModel()):

Fake Response Usage (initializeModelChunk()):

$B Handler RCE (parseModelString()):

The Fix (19.2.1)

The patch includes multiple fixes:

1. RESPONSE_SYMBOL in initializeModelChunk() - Critical fix

   root@kitploit:~

   // BEFORE: chunk._response (attacker can set via JSON)
   value = reviveModel(chunk._response, ...);
   
   // AFTER: Symbol lookup (cannot be forged via JSON)
   var response = chunk.reason[RESPONSE_SYMBOL];
   value = reviveModel(response, ...);
   

2. hasOwnProperty check in getOutlinedModel() - Blocks prototype traversal

   root@kitploit:~

   hasOwnProperty.call(value, name) && (value = value[name]);
   

3. __proto__ handling in reviveModel() - Prevents prototype pollution

   root@kitploit:~

   void 0 !== parentObj || "__proto__" === i
     ? (value[i] = parentObj)
     : delete value[i];
   

4. Type check in initializeModelChunk() - Validates listeners

   root@kitploit:~

   "function" === typeof listener
     ? listener(value)
     : fulfillReference(response, listener, value);
   

Impact & Versions

Impact Assessment

Affected Versions

• react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack: Same versions
• Next.js: 15.x, 16.x (before patches), canaries from 14.3.0-canary.77+

Fixed Versions

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

Why Signature-Based WAF Detection Fails

This section explains why traditional pattern-matching WAF rules cannot reliably detect this exploit. Understanding these limitations is essential for security teams evaluating their defensive posture.

The Core Problem: Encoding at Multiple Layers

The exploit payload passes through multiple parsers, each with different encoding support. A WAF inspecting raw HTTP bytes sees encoded strings, but the server decodes them before processing:

This creates a fundamental mismatch: the WAF sees encoded bytes, but the application sees decoded strings.

What Signatures Would Need to Match

A naive WAF might look for patterns like constructor, __proto__, resolved_model, or child_process. However, JSON allows unicode escapes for any character:

JavaScript code within the payload has even more encoding options:

The Detection Gap

When all encoding techniques are combined:

• JSON keys become unicode sequences (\u0074\u0068\u0065\u006e for then)
• JS identifiers become numeric arrays (S(99,104,105,108,100,95,...) for child_process)
• The raw payload contains zero recognizable keywords

A WAF scanning the HTTP body sees only escape sequences and numbers - nothing that matches traditional attack signatures.

Why This Matters for Defenders

1. Signature-based rules provide false confidence - The payload reaches the server undetected
2. Encoding is infinite - Every character can be escaped differently; regex cannot enumerate all variants
3. The attack is protocol-compliant - All encodings are valid JSON/JavaScript per specification

Header Detection Considerations

The Next-Action header identifies Server Action requests. While header names cannot be unicode-encoded (RFC 7230 requires ASCII tokens), normalization differences between WAF and server create detection gaps:

Defensive Recommendations

Patching is the only reliable mitigation. WAF rules cannot comprehensively block this attack due to encoding flexibility.

Required versions:

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

If patching is delayed, consider:

1. Decode before matching - WAF must decode \uXXXX, \xXX, and normalize fromCharCode() calls before pattern matching
2. Structural detection - Look for JSON structures containing _response, _prefix, _chunks, or circular references ($@0)
3. Header normalization - Match next-action header case-insensitively with whitespace trimming
4. Block Server Actions - If not using Server Actions, block requests with Next-Action header entirely
5. Runtime monitoring - Alert on Function() calls with dynamic string arguments

Key takeaway: Pattern matching alone will fail against this class of attack. The encoding surface is too large to enumerate.

AWS WAF Body Inspection Limits Bypass

Even with comprehensive WAF rules, AWS WAF has body inspection size limits that can be exploited. This section documents tested bypass techniques using oversized payloads.

Body Inspection Limits

AWS WAF only inspects a portion of the request body:

The OversizeHandling Problem

WAF rules specify how to handle requests exceeding inspection limits:

If your WAF rule uses OversizeHandling: CONTINUE (common default), the bypass is trivial.

Bypass Strategy: Padding Before Payload

Place harmless padding data before the exploit payload so it falls outside the inspection window:

Test Results

All oversize payloads successfully achieved RCE on Next.js:

Chunked Transfer Encoding Bypass

HTTP/1.1 chunked transfer encoding splits the body into discrete chunks. If WAF inspects chunks before reassembly, patterns spanning chunk boundaries won't match.

How It Works

Pattern split across chunks:

Chunking Strategies Tested

All strategies successfully achieved RCE - Next.js correctly reassembles chunked requests.

Raw Socket Example

WAF Behavior Considerations

Note: AWS WAF typically reassembles chunked bodies before inspection. However, this should be verified per-environment as configurations vary.

Mitigation Recommendations

1. Change OversizeHandling to MATCH

   root@kitploit:~

   "OversizeHandling": "MATCH"
   

   This blocks any request exceeding the inspection limit when rule conditions are met.

2. Increase body inspection limit (CloudFront/API Gateway only) Configure up to 64KB in web ACL settings, but this doesn't fully prevent the bypass.

3. Add size-based blocking rule Block POST requests with Next-Action header exceeding a reasonable size (e.g., 10KB).

4. Patch the application - The only complete solution.

Test Scripts

See included test scripts:

• test-simple.cjs - Baseline non-chunked payload test
• test-oversize.cjs - Tests padding sizes from 0-128KB
• test-chunked-v2.cjs - Chunked transfer encoding with $@ split
• test-chunked-bypass.cjs - Multiple chunking strategies (5-byte, 10-byte, pattern splits)

Usage:

Research Journey

The Vulnerability: Path Traversal

With payload "$1:constructor:constructor":

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

Blocked Paths We Tried

While we obtained Function, achieving RCE requires calling it with controlled arguments. These paths failed:

1. Thenable Path (Blocked)

2. decodeAction Path (Blocked)

3. Iterator Path (Blocked)

The Breakthrough

maple3142 found the missing piece: the $B handler + fake _response chain. By making then resolve to Chunk.prototype.then via self-reference, the fake _response gets used, enabling RCE.

Key Findings

1. getOutlinedModel() vulnerability is real - Colon-separated paths allow prototype chain traversal

2. Function constructor is accessible - $1:constructor:constructor works without serverManifest

3. RCE is achievable - By crafting a fake chunk with controlled _response:

   • Self-reference $1:__proto__:then → Chunk.prototype.then makes fake _response get used
   • Fake chunk structure mimics React's internal Chunk class
   • _response._formData.get → Function constructor
   • _response._prefix → malicious code string
   • $B handler triggers Function(malicious_code)

4. The fix is comprehensive - Multiple hasOwnProperty checks and type validations

References

• maple3142's Gist - RCE chain discovery
• React Security Advisory
• Next.js CVE-2025-66478
• msanft PoC
• react2shell.com
• AWS WAF Rule

Disclaimer

This repository is for educational and defensive security research only. The vulnerability has been patched. Upgrade your dependencies immediately.