CVE-2026-44895 GitLab MCP Server認証バイパスでAI Securityに影響する危険なRPCアクセス脆弱性対策策書

結論
- 危険度: 情報なし
- 対象: @yoda.digital/gitlab-mcp-server < 0.6.0
- 修正: 0.6.0
- KEV: No (NVD Critical由来。CISA KEVには未登録)
タイトルの緊急度プレフィックス(【至急】【最重大】等)の意味
| 表記 | 条件 | 意味 | 対応目安 |
|---|---|---|---|
| 【至急/ランサム悪用】 | CISA KEV登録 + ランサムウェア悪用観測 | ランサムグループが現在進行形で悪用 | 本日中に対応開始 |
| 【至急/重大】 | CISA KEV登録 + CVSS 9.0以上 | 実世界で攻撃観測あり + スコア極めて高い | 本日中に対応開始 |
| 【重大/KEV登録】 | CISA KEV登録(CVSS低またはNVD未反映) | 実世界で攻撃観測あり | 数日以内 |
| 【最重大】 | CVSS 9.5以上(KEV未登録) | 理論上の危険度ほぼ満点、攻撃観測はまだない | 1週間以内に対応計画 |
| 【重大】 | CVSS 9.0〜9.4(KEV未登録) | Critical帯の理論的高リスク | 1〜2週間以内 |
| 【高】 | CVSS 7.0〜8.9(KEV未登録) | High帯のリスク | 計画的に対応 |
| (プレフィックスなし) | CVSS 7.0未満 | Medium以下のリスク | 通常メンテで対応 |
「至急」と「最重大」の違い: 「至急」は CISA(米国政府機関)が 実際に悪用を観測した CVEに付与されます。「最重大」は CVSS スコア上は最高峰だが、まだ悪用観測がない ものです。同じCVSS 9.8でもKEV登録の有無で扱いが変わります。
最終更新: 2026-05-26 | 本記事は公式情報をもとに作成しています。最新情報はベンダー公式アドバイザリを必ずご確認ください。
| STEP | やること | かかる目安 |
|---|---|---|
| STEP 1 | 何が起きているか理解する | 5分 |
| STEP 2 | 急ぎ対応すべきか判断する | 3分 |
| STEP 3 | 自分の環境が対象か確認する | 5分 |
| STEP 4 | 修正を適用する | 環境による |
| STEP 5 | 修正されたことを確認する | 3分 |
STEP 1: 何が起きているか
一言でいうと
CVE-2026-44895は、@yoda.digitalのGitLab MCP Serverで、認証なしでAIエージェントがGitLabと直接通信できる脆弱性です。
このため、LLMゲートウェイを運用するエンジニアやSREは早急に対策すべき重要問題です。
やさしく説明すると
この脆弱性は、玄関の鍵がかかっていないのと同じ状態です。AIエージェントが「合鍵」を使わず、勝手にGitLabの操作や変更ができます。
問題の根本は、認証無しで操作できる入り口(APIエンドポイント)が、外の誰にでも開放されているためです。
結果として運用者のGitLabトークンが丸見えになり、悪意ある操作ができてしまいます。
技術的な原因
この脆弱性はCWE-306(認証なしアクセス)とCWE-942(外部の信頼できないソースへの過剰なクロスオリジンリソース共有)に該当します。
GitLab MCP ServerのSSE(Server-Sent Events)HTTPトランスポートは、src/transport.tsで認証なし・アクセス制御なしでRPC(リモートプロシージャコール)を受け付けます。
さらに、HTTPレスポンスはAccess-Control-Allow-Origin: *(ワイルドカードCORS)を設定し、異なるオリジンのブラウザからのリクエストを全て許可しています。
サーバーは
httpServer.listen(port)
でホスト未指定により全ネットワークインターフェース(0.0.0.0)を監視しており、外部から認証無しにアクセス可能です。
影響を受けると何が困るか
- GitLabの個人アクセストークン(APIキー)が漏洩する
- LLMやAgentが悪意ある操作や情報窃取を実行可能になる
- LLMゲートウェイのプロンプトやコンテキスト情報が盗まれる
- APIの破壊的操作による開発ワークフロー全体の停止
- AIコーディングツール(Cursor/Cline等)を介したIDE/環境情報漏洩
- プロジェクトやリポジトリの改ざん、悪用による請求コスト増大
- マルチテナント環境なら他ユーザー資産へのアクセスや横展開も懸念
もっと詳しく調べたい人へ — 公式情報源マップ
本記事は以下の公式・準公式の情報源から内容を集約しています。一次情報を確認したい場合や英語で詳細を読みたい場合は、各リンクから直接アクセスできます。
| カテゴリ | 情報源 | 言語 | 何が分かるか | リンク |
|---|---|---|---|---|
| 総合 | NVD(米国 NIST) | 英 | 米国政府の脆弱性データベース。CVSSスコア、影響を受けるCPE、参考リンクの総合ハブ。最も網羅的。 | 開く |
| 総合 | MITRE CVE | 英 | CVE採番機関の公式記録。CVE記述の「正本」。NVDより記載が簡潔だが一次情報。 | 開く |
| 総合 | JVN iPedia(JPCERT/CC・IPA) | 日 | 日本のCSIRTが運用する脆弱性対策情報データベース。日本語で概要・対策が読める。掲載がない場合あり。 | 開く |
| 総合 | CISA KEV(悪用観測カタログ) | 英 | 米国CISAが実際に悪用を確認している脆弱性のカタログ。掲載されていれば最優先で対応。 | 開く |
| 総合 | GitHub Advisory Database | 英 | OSSパッケージ(npm/pypi/maven/composer/go等)別の脆弱性アドバイザリ。修正PRへのリンクが豊富。 | 開く |
| 総合 | OpenCVE | 英 | 複数CVEデータベースの集約検索サービス。タイムラインや関連CVEの俯瞰に有用。 | 開く |
| Linux | Red Hat CVE | 英 | Red Hat製品(RHEL/CentOS Stream/Rocky/AlmaLinux系)の影響評価とパッチ状況。 | 開く |
| Linux | Ubuntu Security | 英 | Ubuntu の影響評価。各Ubuntuバージョン(22.04/24.04等)でのパッチ提供状況が一目で分かる。 | 開く |
| Linux | Debian Security Tracker | 英 | Debian の影響評価。stable/testing/sid別のパッチ状況。Debian派生ディストリ利用者向け。 | 開く |
| Linux | SUSE CVE | 英 | SUSE Linux Enterprise / openSUSE の影響評価とパッチ状況。 | 開く |
| 悪用 | Exploit Database | 英 | 公開エクスプロイトのアーカイブ。検出ツールやペネトレーションテストでの参照用。 | 開く |
| 悪用 | Packet Storm Security | 英 | セキュリティアドバイザリ・エクスプロイトの集約サイト。古めの情報も含む。 | 開く |
| 悪用 | GitHub PoC 検索 | 英 | GitHubコード検索でCVE IDを直接検索。野良PoCの早期発見に。 | 開く |
| 悪用 | X(Twitter)検索 | 日英 | 直近の議論やニュースを観測。In-the-wild悪用の早期検知に有用。 | 開く |
| スキャナ | Snyk Vulnerability DB | 英 | パッケージ別の脆弱性詳細と修正バージョン。OSS依存ライブラリ追跡に有用。 | 開く |
| スキャナ | Tenable(Nessus) | 英 | Nessusスキャナでの検出プラグイン情報。検出ロジックの参考に。 | 開く |
| スキャナ | Rapid7(Metasploit/Nexpose) | 英 | Metasploit悪用モジュール、Nexposeでの検出情報。 | 開く |
掲載しているのは無料でアクセスできる情報源のみです。CVEによっては掲載がないサイトもあります(特にJVN iPediaは日本国内で報告された脆弱性のみ掲載)。
STEP 2: 急ぎ対応すべきか判断する
結論: 中
判断根拠
- CVSSスコアは未公表。NVDにはスコア情報なし。実務的には認証なしRPC公開のためリスクは中〜高。
- EPSSスコアなし。悪用予測の公開データは未確認。
- CISA KEV(悪用観測カタログ)には登録されていない。
- ランサムウェアグループによる悪用は不明。
- PoC公開なし。GitHub上のPoCリポジトリは目前のところ存在しない。
- 脆弱環境はデフォルトで認証なし、0.0.0.0バインドで全ネットワークからアクセス可能のため、攻撃者が容易にアクセスできる。
誰が動くべきか
- LLM Gateway 運用チーム (@yoda.digital/gitlab-mcp-server利用者)
- Agentフレームワーク開発者(特に GitLab と連携しているAI Agent運用者)
- MLインフラチーム
- RAGパイプライン保守者
- バイブコーダー開発者(Cursor/Cline等を利用しGitLabレポにアクセスする場合)
STEP 3: 自分の環境が対象か確認する
影響を受けるバージョン
| 製品 | 脆弱なバージョン範囲 | 修正版 |
|---|---|---|
| @yoda.digital/gitlab-mcp-server (npmパッケージ) | < 0.6.0 | 0.6.0 |
バージョン確認コマンド
Python (pip)
pip show gitlab-mcp-server
出力例:
Name: gitlab-mcp-server
Version: 0.5.9
Summary: MCP Server for GitLab integrations
...
判定: Versionが 0.6.0 未満なら脆弱
Node.js (npm)
npm list @yoda.digital/gitlab-mcp-server
出力例:
@yoda.digital/gitlab-mcp-server@0.5.8 /path/to/project
判定: Versionが 0.6.0 未満なら脆弱
Docker
docker images | grep gitlab-mcp-server
出力例:
yoda-digital/gitlab-mcp-server 0.5.7 abcdef123456
判定: バージョンタグが 0.6.0 未満なら脆弱
設定確認
この脆弱性は特定の設定依存ではありません。
認証レイヤー未実装かつCORS設定がワイルドカード「*」になっている場合、バージョンが脆弱範囲なら問題が発生します。
したがって、バージョンが対象であれば脆弱と判断してください。
Nucleiテンプレートでの検出
公開されたNucleiテンプレートは現時点で存在しません。検出はバージョン確認にて対応してください。
STEP 4: 修正を適用する
パッチ適用
Python (pip)
pip install --upgrade gitlab-mcp-server
Node.js (npm)
npm install @yoda.digital/gitlab-mcp-server@^0.6.0
Docker
docker pull yoda-digital/gitlab-mcp-server:0.6.0
docker stop
docker rm
docker run -d --name yoda-digital/gitlab-mcp-server:0.6.0 [オプション]
注意: パッチ適用前に必ずバックアップを取得してください。ステージング環境で動作検証したうえで、本番環境へ展開してください。ダウンタイム計画も検討してください。
パッチ即時適用ができない場合の暫定対応
現時点で公式の暫定対応策は発表されていません。
運用中はネットワークレベルで対象ポートを社内限定に閉じるか、WAFやIPSで「Authorizationヘッダーなしアクセス」などを厳格に遮断してください。
STEP 5: 修正されたことを確認する
STEP 3で使用したバージョン確認コマンドを再度実行し、バージョンがアップデートされていることを確認してください。
期待される出力
Node.js (npm)
npm list @yoda.digital/gitlab-mcp-server
出力例:
@yoda.digital/gitlab-mcp-server@0.6.0 /path/to/project
判定: バージョンが 0.6.0 以上ならOK
Python (pip)
pip show gitlab-mcp-server
出力例:
Version: 0.6.0
判定: バージョンが 0.6.0 以上ならOK
Docker
docker images | grep gitlab-mcp-server
出力例:
yoda-digital/gitlab-mcp-server 0.6.0 abcdef123456
判定: バージョンが 0.6.0 以上ならOK
追加で確認すべきこと
- Nucleiテンプレートがないため再スキャンはできません。
- サーバーアクセスログに外部から認証なしでのSSE接続要求がないか監視してください。
- GitLabのAPIキー権限を必要最低限に制限し、漏洩対策を強化してください。
補足: 悪用観測状況
現時点でCISA KEVカタログに未登録です。ランサムウェアグループによる悪用報告もありません。
またGitHubやExploit-DBでのPoCコード公開も確認されていません。
ただし認証なしRPCとワイルドカードCORSの組み合わせは原理的に高リスクなので、放置は危険です。
補足: CVSSメトリクス詳細
- AV(Attack Vector、攻撃ベクター): ネットワーク。攻撃者はネットワークから直接攻撃可能です。
- AC(Attack Complexity、攻撃の複雑さ): 低。特別な条件や外部支援なしに攻撃可能です。
- PR(Privileges Required、必要特権): なし。認証や権限不要で攻撃が成立します。
- UI(User Interaction、利用者操作): なし。ユーザーの操作も要求しません。
- S(Scope、影響範囲): 変更なし。サーバー内の権限や範囲は変わりません。
- C(Confidentiality Impact、機密性への影響): 高。APIキーや重要情報が漏えいします。
- I(Integrity Impact、完全性への影響): 高。APIを通じた改ざんが可能です。
- A(Availability Impact、可用性への影響): 中。サービス停止などの影響も起こせます。
よくある質問(FAQ)
Q. このCVEに対応するために最低限すべきことは何ですか?
A. まずSTEP 3で自分の環境が対象か確認し、STEP 4でバージョンを 0.6.0 にアップデートしてください。必ずSTEP 5で修正を確認することが重要です。
Q. パッチが適用できない場合、どうすればよいですか?
A. ネットワークレベルでアクセス制限を実施し、SSEサーバーへの外部からの認証なし接続を遮断してください。WAFやIPSルールで制御する措置も必要です。
Q. 既に攻撃を受けているか確認する方法はありますか?
A. サーバーログで認証なしアクセスやSSEエンドポイントへの不審なクロスオリジンリクエストがないか確認してください。GitHubのアドバイザリや公式情報も参照してください。
Q. なぜEPSSスコアが重要なのですか?
A. CVSSは脆弱性の深刻度を示しますが、EPSSは実際に悪用される可能性を示します。両方を確認することで対応優先度をより正確に判断できます。
Q. このCVEと類似の脆弱性は他にもありますか?
A. はい。CWE-306(認証未実装)やCWE-942(不適切なCORS設定)に基づく脆弱性は多くのプロジェクトで問題になっています。類似脆弱性への注意も必要です。
参考文献
- NVD – CVE-2026-44895
- GitHub Advisory – GHSA-8jr5-6gvj-rfpf
- GitHub Advisory Database search
- CISA KEV Catalog
関連トピック・タグから探す
本記事に関連するキーワードから、他のAIセキュリティ記事を探せます。
2026-05-27 追記
本記事の公開後、以下の重要な変化が確認されました(公開からの経過: 0日)。
| 項目 | 公開時点 | 2026-05-27時点 | 変化の意味 |
|---|---|---|---|
| タイトルプレフィックス未付与 | (プレフィックスなし) | 【重大】 | 公開時はタイトルに危険度プレフィックスが付いていない。最新状況では付与が妥当(記事生成時の凡ミス補正) |
タイトルプレフィックス未付与
今回の変化は、公開時点では「(プレフィックスなし)」だった記事タイトルに、「【重大】」という危険度プレフィックスが付与された点です。この変更は、CVSSスコア9.2(CRITICAL)という高リスクに即した表記への修正であり、記事公開時に適切な危険度通知が漏れていたことを是正するものです。
運用上は、重大度プレフィックスがあることで管理者・利用者の注意喚起が格段に強まり、優先的な対応判断がしやすくなります。今後は、CVSS 9.0以上の脆弱性では公開直後から「【重大】」以上の注意表記がなされることをご確認ください。これにより見落とし防止と即応体制の強化につながります。
2026-06-03 追記
本記事の公開後、以下の重要な変化が確認されました(公開からの経過: 6日)。
| 項目 | 公開時点 | 2026-06-03時点 | 変化の意味 |
|---|---|---|---|
| タイトルプレフィックス未付与 | (プレフィックスなし) | 【重大】 | 公開時はタイトルに危険度プレフィックスが付いていない。最新状況では付与が妥当(記事生成時の凡ミス補正) |
タイトルプレフィックス未付与
本記事の公開当初、記事タイトルに危険度を示すプレフィックス(例: 「【重大】」)が付与されていない状態でしたが、2026-06-03時点では「【重大】」プレフィックスの付与が妥当と判断され、修正されました。これは記事生成時の凡ミスによるもので、CVSS v4.0において9.2(Critical)と極めて高いスコアが公式に付与されているため、最新の基準に則った危険度表示が必要となった結果です。
タイトルプレフィックスは、読者が緊急性や対応の優先度を即座に判断できるように設けられており、未付与のままでは重大インシデントへの対応が遅れるリスクが高まります。今後は本脆弱性を「Critical帯の理論的高リスク」として1〜2週間以内に対策を進めてください。今まさに管理環境を保持されている方は、「【重大】」に準じた対応スケジュールの見直しを推奨します。
