[!NOTE] package.json は脆弱性のあるバージョン 19.0.0 に固定されています。

概念実証

1. 脆弱なサーバーを起動する

このスクリプトは、脆弱なReactランタイムを使用してリクエストをデコードする素のHTTPサーバーをセットアップします。

2. エクスプロイトスクリプトを実行する

別のターミナルで、エクスプロイトを実行します。これにより、悪意のあるFlightペイロードがサーバーに送信されます。

応答としてコマンドの出力が返されるはずです：

期待される出力：

分析

なぜこの脆弱性が発生したのか？

ReactFlightDOMServerNode.js 内の requireModule 関数は、基本的にクライアントが送信した name をそのまま信頼していました。そのプロパティが実際に公開されることを意図されているかどうかを確認せずに、moduleExports[metadata[NAME]] を実行していました。つまり、クライアントが「このプロパティが欲しいんだけど」と言えば、サーバーは「いいよ！はい、どうぞ」と返すだけでした。

任意のプロパティへのアクセスを許可することがなぜ悪いアイデアなのか？

なぜなら、基本的に誰でもプロトタイプチェーンに到達できるようになり、非常に危険な constructor にすらアクセスできてしまうからです。モジュールがたまたま関数をエクスポートしている場合（module.exports = () => {} など）、その constructor は文字通りグローバルな Function コンストラクタになります。

Function コンストラクタを取得することがなぜRCEを意味するのか？

攻撃者は Function コンストラクタを取得すると、「Bound Server Action」機能を悪用できます。悪意のあるJavaScriptを含む文字列をそれにバインドします（基本的に new Function("evil code") に変換します）。そしてそれが実行されると、サーバーは攻撃者が仕込んだ任意のコードを実行します。

なぜReactは実際にその悪意のある関数を実行するのか？

Server ActionsはIDによってトリガーできるからです。攻撃者が自分の module#constructor 参照を指すAction IDを含むペイロードを構築すると、Reactはそれを通常のアクションとして解決し、実行します。その「アクション」は実際には攻撃者の悪意のある関数です。

なぜこれらは一切検証されていなかったのか？

システムは、Server Referenceメタデータの id と name が常に開発者によって定義された有効なエクスポートを参照するものと想定していました。要求されたプロパティが実際のエクスポートであり、プロトタイプチェーンから継承されたものではないことを確認するための hasOwnProperty のような安全チェックはありませんでした。

なぜNext.jsではなく server.js なのか？

素の server.js（およびヘルパーの webpack-runtime.js）を使用して、React Server Componentsランタイムを手動で構成しています。これにより、以下のことが可能になります：

1. 脆弱なセットアップを強制する： エクスプロイトは、モジュールが関数としてエクスポートされている場合（module.exports = fn）にのみ機能します。実際のバンドラーは、その設定によってエクスポートのラップ方法を変更する可能性がありますが。
2. バグを隔離する： これにより、問題がNext.jsではなく react-server-dom-webpack の内部にあることを示せます。
3. バンドラー環境を再現する： react-server-dom-webpack はWebpackバンドル内で実行されていることを前提としています。私たちの webpack-runtime.js は、それが期待するグローバル（__webpack_require__、__webpack_chunk_load__）を提供します。

これは脆弱性をモックしているのではなく、ライブラリが実際に動作するために必要な最低限のランタイムを提供しているだけです。

備考

開発者が child_process.exec などの危険なものを意図的に公開した場合にのみ機能する「無効なPoC」についての議論がありました。

このPoCはそのようなものではありません。通常の安全なセットアップで機能します。

1. 公開された関数は無害です アプリは単純な updateProfile 関数を公開します。これは単に文字列を返すだけで、怪しいものもシェルコマンドもありません。
2. エクスプロイトはその関数から完全に脱出します この脆弱性により、攻撃者は安全なエクスポートを無視して、グローバルな Function コンストラクタである updateProfile.constructor に直接ジャンプできます。
3. 核心的な問題はプロパティアクセスです Reactは .constructor へのアクセスを許可すべきではありませんでした。開発者は Function コンストラクタを公開する意図はありませんでしたが、安全でないデシリアライゼーションが代わりにそれを公開してしまいました。

唯一の実際の要件は、モジュールが関数を直接エクスポートしていること（module.exports = fn）です。これはCommonJSや多くのバンドラー設定で非常に一般的です。

ペイロード

exploit.js 内のペイロードは、3つのチャンクでReact Flightメッセージを構築します：

• チャンク0： チャンク1で定義されたServer Referenceを指します。
• チャンク1： Server Referenceを宣言します：
  • id："user-profile-action#constructor"、つまり「constructorをくれ」という意味です。
  • bound：引数を含むチャンク2を指します。
• チャンク2： ["console.log('nice try, diddy!')"]：悪意のあるコード文字列です。

Reactがこれをデシリアライズすると：

1. user-profile-action を解決します。
2. .constructor プロパティを読み取ります => グローバルな Function を取得します。
3. 攻撃者が提供した文字列をそれにバインドします。
4. 実質的に以下を実行します： new Function("console.log('nice try, diddy!')")

これがRCEです！

緩和策

直ちに修正済みバージョンにアップグレードしてください：

• react-server-dom-webpack >= 19.0.1
• react-server-dom-parcel >= 19.0.1
• react-server-dom-turbopack >= 19.0.1

このパッチは、継承されたプロパティへのアクセスを防ぐための hasOwnProperty チェックを導入し、base64 ファイルのアップロードを制限します。

修正済みバージョンに対してこのPoCを実行すると、サーバーは次のようにクラッシュまたはエラーになります：

これにより、エクスプロイトが constructor プロパティへのアクセスに失敗したこと（Function の代わりに undefined が返されたこと）、その結果、後続の .bind 呼び出しが失敗したことが確認できます。

免責事項

このコードは教育およびテスト目的のみです。所有していないシステムや、明示的なテスト許可を得ていないシステムに対して、このエクスプロイトを使用しないでください。

ライセンス

DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE の下で公開されています。