はじめに：DNS Rebinding攻撃とは？

DNS Rebinding攻撃は、Same-Origin Policy (SOP) というブラウザのセキュリティメカニズムを巧妙に回避し、Webページがユーザーのローカルネットワーク上のリソースにアクセスできるようにする攻撃手法です。通常、ブラウザは異なるオリジンからのリソースへのアクセスを制限しますが、DNS Rebindingは、攻撃者が制御するドメインのDNSレコードを短期間で変更することで、一度は正当なオリジンと見なされたリクエストが、後にはローカルネットワーク上のIPアドレス（例: 127.0.0.1）に解決されるように仕向けます。

フロントエンドエンジニアにとっては、ユーザーのブラウザが直接的な攻撃の媒介となるため、特に注意が必要です。この種の攻撃は、ローカルで動作する開発サーバーやAPIエンドポイントなどがターゲットになり得ます。

@zereight/mcp-gitlabの脆弱性 (CVE-2026-61568) の詳細

今回報告された脆弱性 (ID: GHSA-vmp7-252j-cwp7 / CVE: CVE-2026-61568) は、`@zereight/mcp-gitlab` ライブラリのバージョン `2.1.18`（特定のコミット `74a8c834424ff557ad8bc6f225e4dc5acf80aa13`）に存在します。この脆弱性は、深刻度が「critical」と評価されており、DNS RebindingによってローカルのStreamable HTTP MCPトランスポートにアクセスされる可能性があります。

具体的な問題点は以下の通りです。

1. **Host/Originヘッダーの検証不足**: `@zereight/mcp-gitlab` のStreamable HTTP MCPエンドポイントが、`Host`や`Origin`ヘッダーに対する効果的なホワイトリストを持たずに公開されています。これにより、攻撃者はブラウザのリクエストを被害者のローカルMCPリスナーにルーティングする際、自身が制御する`Host`および`Origin`ヘッダーを保持したままリクエストを送信できてしまいます。

2. **Expressミドルウェアの順序**: `index.ts` では、ExpressのJSONパースがグローバルに適用されており、MCPルートレベルでのHostやOriginのホワイトリストが適用される前にリクエストが処理されてしまいます。これにより、不適切なヘッダーを持つリクエストが、本来ブロックされるべきHTTP境界を越えてMCPの初期化パスに到達してしまいます。

3. **SDKの保護機能の未利用**: `StreamableHTTPServerTransport` のコンストラクタで、SDKが提供するDNS Rebinding対策（`enableDnsRebindingProtection`、`allowedHosts`、`allowedOrigins`）が有効になっていません。これにより、デフォルトでループバックアドレス (`127.0.0.1`) を使用する設定が悪用される温床となります。

この脆弱性は、CWE-350 (Reliance on Reverse DNS Resolution for a Security-Critical Action) に分類されます。

フロントエンド開発者が受ける影響

この脆弱性が悪用された場合、フロントエンド開発者が意識すべき主な影響は以下の通りです。

1. **ローカルリソースへの不正アクセス**: ユーザーが攻撃者が仕込んだ悪意のあるWebページを閲覧すると、ブラウザがDNS Rebindingを利用して、ユーザー自身のPCで動作しているローカルの`@zereight/mcp-gitlab`インスタンスにリクエストを送信します。この際、SOPを回避した上で、攻撃者が偽装した`Host`や`Origin`ヘッダーが受け入れられてしまいます。

2. **機密情報の漏洩**: MCPの`initialize`パスに到達できるため、攻撃者はセッションを確立できます。もし、ブラウザからGitLabのプライベートトークン（`Private-Token`）やジョブトークン（`JOB-TOKEN`）などの認証情報が供給可能な状態であれば、攻撃者はこれらのトークンを利用して、GitLab APIツール（例: `list_project_variables`）を実行し、CI/CD変数などの機密プロジェクトデータを盗み出す可能性があります。

3. **開発環境への影響**: 開発者がローカル環境でこのライブラリを使用している場合、開発マシン上の機密データが狙われるリスクも存在します。たとえ`REMOTE_AUTHORIZATION=true`が設定されていても、HTTP境界での検証不足が問題の根源であるため、認証が通るケースでは攻撃が成立し得ます。

PoC (Proof of Concept) で示された攻撃の流れ

提供されたPoCでは、以下のシナリオが実証されています。

1. **偽のGitLab APIサーバー**を起動し、特定のプロジェクト変数（例: `PRODUCTION_DEPLOY_TOKEN`）を保持させておきます。

2. **脆弱なMCPサーバー**を`@zereight/mcp-gitlab`の該当バージョンで起動します。この際、`STREAMABLE_HTTP=true`や`REMOTE_AUTHORIZATION=true`などを設定します。

3. **攻撃者のクライアント**が、DNS Rebindingを模倣した`Host` (`attacker.example:8082`) と`Origin` (`http://attacker.example:8082`) ヘッダーを付けてMCPサーバーにリクエストを送信します。

結果として、認証トークンなしのリクエストでは`initialize`は成功するものの`tools/list`は401 Unauthorizedで拒否されます。しかし、有効な`Private-Token`を付与したリクエストでは、`initialize`に加えて`tools/list`が成功し、さらに`list_project_variables`を呼び出すことで、偽のGitLab APIサーバーから「glpat-FAKE-PROJECT-CI-SECRET-0001」という機密データが取得できてしまうことが確認されています。

これは、HTTP境界でのOrigin検証の欠如が、認証の有無にかかわらず、攻撃者にMCPセッション初期化への道を開いてしまうことを明確に示しています。

今すぐできる対策

この脆弱性に対処するために、以下の対策を速やかに実施してください。

1. **ライブラリのアップデート**: 最も推奨される対策は、`@zereight/mcp-gitlab`の修正済みバージョンへのアップデートです。公開され次第、速やかに適用してください。

2. **SDKのDNS Rebinding保護の有効化**: `StreamableHTTPServerTransport`のインスタンスを生成する際に、以下の設定を追加または確認してください。

```typescript transport = new StreamableHTTPServerTransport({ sessionIdGenerator: () => randomUUID(), enableDnsRebindingProtection: true, allowedHosts: [ `127.0.0.1:${PORT}`, `localhost:${PORT}`, ], allowedOrigins: [ `http://127.0.0.1:${PORT}`, `http://localhost:${PORT}`, ], onsessioninitialized: (newSessionId: string) => { streamableTransports[newSessionId] = transport; }, }); ```

3. **Expressミドルウェアによる`Host`/`Origin`ヘッダーの検証**: `/mcp` ルートの前に、Expressミドルウェアを追加して、予期しない`Host`や`Origin`ヘッダーを持つリクエストを拒否するロジックを実装します。これは、SDKの保護機能に加えて、多層防御の一部として重要です。同様に、SSEトランスポートが使用されている場合も同様の対策が必要です。

4. **開発環境での注意**: 開発時においても、信頼できないWebサイトへのアクセスは避け、ローカルで実行しているAPIやサービスの設定に細心の注意を払うようにしてください。

まとめ

DNS Rebinding攻撃は、一見するとバックエンドの問題に見えますが、ブラウザの挙動を悪用するため、フロントエンド開発者もそのメカニズムと影響を深く理解しておくべき重要なセキュリティ脅威です。今回の`@zereight/mcp-gitlab`の脆弱性は、ローカルで実行されるAPIエンドポイントが、Host/Originヘッダーの不適切な処理によっていかに危険に晒されるかを示しています。

皆さんの開発プロジェクトでこのライブラリが使用されている場合は、速やかに上記対策を検討・実施し、安全なフロントエンド・バックエンド連携を確保しましょう。セキュリティは単一の層でなく、複数の層での対策によって成り立っています。