rootdirective-sec/cve-2025-11262-lab# CVE-2025-11262 再現用Dockerラボ Link Whisper Free WordPressプラグインにおける未認証の保存型ブラインドXSS（CVE-2025-11262）を再現するためのDockerラボです。脆弱性のあるターゲットとパッチ適用済みターゲット、PoCスクリプト、根本原因分析が含まれています。
このリポジトリには、WordPressプラグイン Link Whisper Free に影響を及ぼす無認証の保存型クロスサイトスクリプティング問題である CVE-2025-11262 を再現するためのローカルDockerラボが含まれています。
このラボでは、2つのプラグインバージョンを比較します：
| サービス | プラグインバージョン | 目的 | URL |
|---|---|---|---|
vuln | 0.9.0 | 脆弱なターゲット | http://127.0.0.1:8081 |
patched | 0.9.1 | パッチ適用済みの比較ターゲット | http://127.0.0.1:8082 |
実証される脆弱性の連鎖は次のとおりです：
無認証のRESTリクエスト
→ 攻撃者が制御する user_id が永続化される
→ 特権を持つWordPressユーザーが Link Whisper AI Subscription ページを開く
→ 保存された値が管理者のJavaScriptコンテキストにレンダリングされる
→ 脆弱なバージョンで alert("CVE-2025-11262-LAB") が実行される
攻撃者は保存型ペイロードを仕込むためにログインしている必要はありません。JavaScriptは、特権を持つWordPressユーザーが影響を受ける管理ページを開いたときに後で実行されます。
このラボは、管理されたローカル調査、ソースレベルの理解、およびポートフォリオデモンストレーションのみを目的として設計されています。
| 主張 | 証拠 | このラボでの検証方法 |
|---|---|---|
Link Whisper Free 0.9.0 は脆弱です。 | 公開アドバイザリは、Link Whisper Free の 0.9.0 以前のバージョンが影響を受けると特定しています。 | http://127.0.0.1:8081 に対してPoCを実行し、出力された管理者URLを開きます。 |
Link Whisper Free 0.9.1 には修正が含まれています。 | 公開アドバイザリとチェンジログのデータは、0.9.1 をパッチ適用済みバージョンとして特定しています。 | 同じPoCを http://127.0.0.1:8082 に対して実行します。アラートは表示されないはずです。 |
| ペイロードの仕込みは無認証です。 | PoCは、WordPressのCookie、ログイン、nonceなしでPOSTリクエストを送信します。 | poc/poc.py を確認してください。必要なのは --url のみです。 |
| 目に見える影響はWordPress管理エリアで発生します。 | 保存された値は、特権ユーザーが Link Whisper AI Subscription ページを開いたときにレンダリングされます。 | PoC実行後、管理者としてログインし、出力された管理者URLを開きます。 |
パッチ適用済みターゲットはHTTPレイヤーで依然として "ok" を返す場合があります。 | ローカルテストでは、両方のターゲットが "ok" を返すことが確認されました。意味のある違いは、ペイロードが永続化され実行されるかどうかです。 | 8081 と 8082 でのブラウザの動作を比較します。 |
これは README にそのまま置き換えられる Root Cause Summary セクションです。vuln_detail.txt のような内部ファイルには言及しないpublic-safeな内容で、現在使用しているラボ/ソースに基づいています。
CVE-2025-11262 は、Link Whisper Free 0.9.0 の保存型JavaScriptインジェクションの連鎖によって引き起こされます。
この問題は、単一のエスケープ呼び出しの欠落ではありません。複数の安全でない動作の連鎖です：
無認証のRESTエンドポイント
→ user_id の検証不足
→ wpil_ai_access_user_id への永続的保存
→ 管理者のJavaScriptコンテキストへの安全でないレンダリング
→ 特権ユーザーがAI Subscriptionページを開くと保存型XSSが発生
Link Whisper Free は、プラグインのREST名前空間の下にAI認証RESTエンドポイントを登録します：
const REST_SLUG = 'link-whisper';
const AI_AUTH = 'ai-auth';
エンドポイントは POST ルートとして登録されます：
register_rest_route(self::REST_SLUG, self::AI_AUTH, [
'methods' => 'POST',
'callback' => [
$this,
'ai_auth_handler'
],
'permission_callback' => "__return_true",
'show_in_index' => false
]);
権限コールバックが __return_true であるため、エンドポイントには認証なしで到達できます。
ラボでは、実際に有効なエンドポイントは次のとおりです：
/wp-json/link-whisper/ai-auth
つまり、無認証の攻撃者は、WordPressセッション、nonce、管理者アカウントを必要とせずにエンドポイントへリクエストを送信できます。
Link Whisper Free 0.9.0 では、ハンドラーはRESTリクエストから攻撃者が制御するパラメータを読み取ります：
public function ai_auth_handler( WP_REST_Request $request )
{
if(!empty($request->get_param('access_token'))){
$token = $request->get_param('access_token');
$user_id = $request->get_param('user_id');
$uid = (int)$request->get_param('uid');
$uemail = $request->get_param('uemail');
if(!empty($token) && false !== strpos($token, 'ai-')){
update_option('wpil_ai_access_token', Wpil_Toolbox::encrypt($token));
update_option('wpil_ai_access_user_id', $user_id);
update_option('wpil_ai_access_user_email', $uemail);
update_user_meta($uid, 'wpil_ai_access_user_id', $user_id);
update_user_meta($uid, 'wpil_ai_access_user_email', $uemail);
update_option('wpil_ai_access_authorized', true);
}
return 'ok';
}
return new WP_Error(400, 'Bad request', [ 'status' => 404 ]);
}
脆弱な動作は、弱い検証条件です：
if(!empty($token) && false !== strpos($token, 'ai-')){
これは、指定されたアクセストークンが文字列 ai- を含むかどうかのみをチェックします。
user_id は保存前に厳密な検証が行われません：
update_option('wpil_ai_access_user_id', $user_id);
その結果、攻撃者が制御するJavaScriptがWordPressのオプションテーブルに永続化される可能性があります。
攻撃者が制御する user_id の値はWordPressオプションに保存されます：
wpil_ai_access_user_id
このラボでは、PoCは次のローカルのみのペイロードを送信します：
</script><script>alert("CVE-2025-11262-LAB")</script>
脆弱なサービスでは、ペイロードは wpil_ai_access_user_id の値として保存されます。
攻撃者はペイロードを仕込むためにログインしている必要はありません。ペイロードは無認証のRESTエンドポイントを通じて仕込まれます。
保存された値は、後でプラグインの設定ロジックを通じて取得されます：
public static function get_linkwhisper_ai_user_id(){
return get_option('wpil_ai_access_user_id', '');
}
この値は $ai_id に割り当てられ、AI Subscription管理ページにレンダリングされます。
Link Whisper Free 0.9.0 では、この値はJavaScript文字列に直接挿入されます：
body: JSON.stringify({
ai_id: "<?php echo $ai_id;?>",
subscription_id: "<?php echo ((!empty($sub)) && isset($sub->subscription_id)) ? $sub->subscription_id: null;?>"
})
$ai_id はJavaScriptコンテキストに挿入される前にエスケープされないため、保存されたペイロードは意図された文字列から抜け出し、管理ページが開かれたときにJavaScriptを実行できます。
ラボのペイロードでは、脆弱なレンダリング出力は次と同等になります：
body: JSON.stringify({
ai_id: "</script><script>alert("CVE-2025-11262-LAB")</script>",
subscription_id: ""
})
ブラウザでは、注入された終了 </script> タグが元のスクリプトブロックを終了させ、注入された <script> ブロックが実行されます。
ペイロードは無認証の攻撃者によって仕込まれますが、実行には特権を持つWordPressユーザーが影響を受ける管理ページを開く必要があります：
/wp-admin/admin.php?page=link_whisper_ai_subscription
このラボでは、アラートダイアログをトリガーするために、影響を受けるページをWordPress管理者として開きます。
これにより、この問題は、Link Whisper AI Subscription管理ページにアクセスできる認証済みWordPress管理者または特権ユーザーを標的とした、無認証の保存型XSSとなります。
Link Whisper Free 0.9.1 は、AI認証値を保存する前に、より厳密な検証を追加します。
パッチ適用済みハンドラーは、トークンとユーザーIDが厳密な形式に一致することを要求します：
if(
!empty($token) &&
false !== strpos($token, 'ai-') &&
(bool) preg_match('/\Aai-[0-9a-f]{64}\z/i', $token) &&
(bool) preg_match('/\A[0-9a-f]{32}\z/i', $user_id)
){
update_option('wpil_ai_access_token', Wpil_Toolbox::encrypt($token));
update_option('wpil_ai_access_user_id', $user_id);
update_option('wpil_ai_access_user_email', sanitize_email($uemail));
update_option('wpil_ai_access_authorized', true);
}
user_id に対して追加された重要な検証は次のとおりです：
preg_match('/\A[0-9a-f]{32}\z/i', $user_id)
これにより、任意のJavaScriptがAIユーザーIDとして保存されるのを防ぎます。
バージョン0.9.1は、JavaScriptコンテキストにレンダリングする前の値もエスケープします：
body: JSON.stringify({
ai_id: "<?php echo esc_attr($ai_id);?>",
subscription_id: "<?php echo ((!empty($sub)) && isset($sub->subscription_id)) ? esc_attr($sub->subscription_id): '';?>"
})
したがって、パッチは2つの時点でこの問題を軽減します：
永続化前の入力検証
JavaScriptレンダリング前の出力エスケープ
ラボは 0.9.0 と 0.9.1 の違いを確認します。
Link Whisper Free 0.9.0 の場合：
POST /wp-json/link-whisper/ai-auth
→ "ok" を返す
→ wpil_ai_access_user_id にペイロードを保存する
→ AI Subscription管理ページを開くと alert("CVE-2025-11262-LAB") がトリガーされる
Link Whisper Free 0.9.1 の場合：
POST /wp-json/link-whisper/ai-auth
→ 依然として "ok" を返す場合がある
→ ペイロードを保存しない
→ AI Subscription管理ページを開いてもアラートはトリガーされない
HTTPレスポンスだけでは、ターゲットが脆弱かどうかを判断するのに十分ではありません。両方のバージョンが "ok" を返す可能性があるためです。意味のある動作の違いは、ペイロードが永続化され、後で管理者のJavaScriptコンテキストにレンダリングされるかどうかです。
このラボは、Docker Composeを使用して、2つの分離されたWordPressインスタンスと2つの独立したMySQLデータベースを実行します。
.
├── docker/
│ └── lab-entrypoint.sh
├── docker-compose.yml
├── patched/
│ └── Dockerfile
├── poc/
│ └── poc.py
├── README.md
└── vuln/
└── Dockerfile
Dockerエントリポイントは自動的に以下を行います：
両サービス共通のデフォルトのWordPress管理者認証情報：
admin / AdminPassw0rd!
ラボをビルドして起動します：
docker compose down -v
docker compose build --no-cache
docker compose up -d
コンテナを確認します：
docker compose ps
公開されるサービス：
脆弱なターゲット: http://127.0.0.1:8081
パッチ適用済みターゲット: http://127.0.0.1:8082
セットップログを確認することもできます：
docker compose logs vuln patched