はじめに：なぜこの脆弱性がフロントエンドエンジニアに関わるのか？

日本のフロントエンドエンジニアの皆さん、こんにちは！今回は、GitLabの運用やCI/CD環境で利用される可能性のある`@yoda.digital/gitlab-mcp-server`というツールに発見された、非常に深刻な脆弱性GHSA-8jr5-6gvj-rfpf（CVE-2026-44895）について解説します。この脆弱性は、サーバー側の設定ミスがブラウザを介した攻撃経路を生み出す典型例であり、CORSの理解と適切な設定の重要性を改めて認識させてくれます。あなたのGitLabアカウントが、たった一つの悪意あるウェブサイトへの訪問で乗っ取られる危険性があるため、ぜひ最後まで読んで対策を講じてください。

脆弱性の概要と仕組み：認証なきSSEと危険なCORS

この脆弱性は、主に以下の3つの要因が組み合わさることで発生します。

1. **SSE (Server-Sent Events) トランスポート機能の認証欠如:** `@yoda.digital/gitlab-mcp-server`のSSE機能は、本来認証が必要であるにもかかわらず、全く認証メカニズムが実装されていません。これにより、誰でもSSE接続を確立できてしまいます。

2. **ワイルドカードCORS設定 (`Access-Control-Allow-Origin: *`):** HTTPレスポンスヘッダーに`Access-Control-Allow-Origin: *`が設定されています。これは「どのオリジンからのクロスオリジンアクセスも許可する」という意味で、セキュリティ上極めて危険な設定です。これにより、任意のWebサイトからこの脆弱なサーバーへのアクセスが可能になります。

3. **デフォルトのバインド先 (`0.0.0.0`):** HTTPサーバーがデフォルトで`0.0.0.0`（すべてのネットワークインターフェース）にバインドされるため、外部ネットワークから容易にアクセス可能な状態になります。

これらの設定が重なることで、`USE_SSE=true`を有効にして運用している場合、このサーバーが内部で保持しているGitLabの個人アクセストークン（PAT）に紐づく、なんと合計86種類ものGitLabツールが、認証なしで誰でも利用できる状態になってしまうのです。

具体的な影響と攻撃経路：ブラウザからのGitLab全操作

攻撃者は、特別な認証情報なしに`GET /sse`エンドポイントでSSE接続を確立し、取得したセッションIDを使って`POST /messages?sessionId=<id>`エンドポイント経由でサーバーにMCPメッセージを送信できます。これにより、サーバーがGitLab PATを使用して実行可能なあらゆるAPI操作を、認証なしでリモートから実行できてしまいます。

想像してください。これには、`delete_repository`（リポジトリの削除）、`delete_group`（グループの削除）、`push_files`（ファイルのプッシュ）、`create_merge_request`（マージリクエストの作成）、`update_repository_settings`（リポジトリ設定の更新）など、GitLab上で破壊的または機密性の高い操作がすべて含まれます。あなたの大切なプロジェクトのリポジトリが瞬時に消去されたり、悪意のあるコードがプッシュされたりする可能性があるのです。

特に恐ろしいのは、ワイルドカードCORSの設定により「ブラウザタブからの攻撃」が可能になる点です。つまり、`@yoda.digital/gitlab-mcp-server`を起動しているユーザーが、悪意のあるWebページを訪問するだけで、そのWebページがユーザーのブラウザを通じてこの脆弱なサーバーにアクセスし、上記のGitLabツールを操作できてしまいます。ユーザーはWebページを訪問する以外の特別な操作は一切必要ありません。フィッシングサイトや、知らないうちに読み込まれた悪意のある広告などがトリガーになる可能性もあります。

推奨される対応策：今すぐ行うべき4つの変更

この脆弱性はCVSS 4.0で約6.3（Medium）と評価されていますが、`USE_SSE=true`を有効にしている環境では、GitLab PATへのフルアクセスを許すため、実質的には**High（高）**の深刻度と見なすべきです。直ちに以下の対策を適用してください。

1. **認証トークンの必須化:** `USE_SSE=true`を使用する場合、起動時に認証トークン`MCP_GITLAB_AUTH_TOKEN`の設定を必須とし、リクエストヘッダーに含まれるトークンを検証する機能を導入してください。トークンが未設定または不正な場合はサーバーの起動を停止するか、アクセスを拒否するようにします。

2. **デフォルトのバインド先変更:** SSEトランスポートのHTTPサーバーは、デフォルトで`127.0.0.1`（ローカルホストのみ）にバインドするように変更してください。ネットワーク経由でのアクセスが必要な場合は、明示的な設定とセキュリティ警告を伴うようにすべきです。

3. **CORSオリジンの制限:** `Access-Control-Allow-Origin: *`の設定を削除し、デフォルトではローカルホストのみを許可するようにします。ネットワーク経由でのアクセスが必要な場合でも、`CORS_ORIGINS`として許可するオリジンを明示的な許可リストで指定するようにしましょう。**フロントエンド開発者にとって、CORSの「*」がいかに危険かを再認識する良い機会です。**

4. **長期的対応:** 今後のロードマップに含まれるSAML/OAuth3認証の実装は、より堅牢な認証基盤を提供する長期的な解決策となるでしょう。

まとめ：セキュリティは「自分ごと」として捉えよう

この脆弱性は、認証の欠如とCORS設定の誤りが組み合わさることで、システム全体に甚大な影響を与える典型的な例です。フロントエンドエンジニアとして、たとえ直接サーバーサイドのコードを書かない場合でも、CORSやネットワーク設定がアプリケーションのセキュリティにどのように影響するかを理解しておくことは非常に重要です。常に最新のセキュリティ情報をチェックし、自身が関わるシステムやツールの設定には細心の注意を払いましょう。あなたのGitLabアカウント、そしてプロジェクトを守るために、今すぐ対策を講じてください。