GitHub MCPの悪用: MCP経由で非公開リポジトリにアクセス
(invariantlabs.ai)- GitHubアカウントに接続されたMCPエージェントは、公開Issueを読むだけで非公開リポジトリのデータ漏えい経路が開く可能性がある
- 攻撃は、公開リポジトリのIssueに仕込まれた間接プロンプトインジェクションが、エージェントのツール使用フローを変えることから始まる
- デモでは、
ukend0464/pacmanの悪意あるIssueが、Claude 4 OpusとGitHub MCPの連携を通じて、非公開リポジトリの情報を公開PRへ流出させた - 問題の核心はGitHub MCP serverコードの欠陥というより、信頼されたツールが信頼できない外部コンテンツと併用される構造にある
- リポジトリごとの最小権限、セッション単位のアクセス制限、MCP-scanのようなランタイムセキュリティ監視がエージェントシステムに必要である
悪意あるIssueから始まるGitHub MCP攻撃
- Invariantは、広く使われているGitHub MCP integrationにおいて、攻撃者がユーザーのエージェントを乗っ取り、非公開リポジトリのデータを流出させられる脆弱性を発見した
- このGitHub MCP serverは、GitHubで14k starsを獲得しているプロジェクトである
- この脆弱性は、Invariantのセキュリティ分析器が検出した初期のToxic Agent Flows事例の1つである
- Toxic Agent Flowとは、間接プロンプトインジェクションによって、エージェントが意図しないツール使用順序を実行してしまうフローを指す
- データ漏えいや悪意あるコード実行といった行為につながりうる
- コーディングエージェントやIDEが急速に導入される中、同様の攻撃が中核的なソフトウェア開発ツールの利用者を危険にさらす可能性がある
攻撃構成
- ユーザーはClaude DesktopのようなMCPクライアントを使用し、GitHub MCP serverを自身のGitHubアカウントに接続している状態である
- 攻撃シナリオでは、2種類のリポジトリを想定する
<user>/public-repo: 誰でもIssueやバグレポートを作成できる公開リポジトリ<user>/private-repo: 専有コードや社内データが含まれる非公開リポジトリ
- 攻撃者は、GitHubの通常の権限ルールに従って公開リポジトリに悪意あるIssueを作成できる
- ユーザーがエージェントに
Have a look at the open issues in <user>/public-repoのような正当な依頼を送ると、エージェントは公開リポジトリのIssueを取得し、プロンプトインジェクションにさらされる - その後エージェントは、非公開リポジトリのデータをコンテキストとして取り込み、公開リポジトリに自動生成したPRでデータを流出させる可能性がある
デモで確認された流出フロー
- デモでは、公開リポジトリ
ukend0464/pacmanと複数の非公開リポジトリが使われたukend0464/pacman: シンプルなPacmanゲーム実装を含む公開リポジトリで、GitHubで確認可能- 非公開リポジトリ群には、ユーザーの個人プロジェクトや機密情報が含まれている
- 攻撃者は、公開リポジトリに悪意あるIssueを配置した
- このIssueには、エージェントが公開リポジトリのIssue一覧を取得した瞬間に実行されるペイロードが含まれている
- ユーザーはClaude 4 Opusに依頼を送り、攻撃をトリガーした
- Claude Desktopはデフォルトで、個々のツール呼び出しごとにユーザー確認を要求する
- 多くのユーザーはエージェント利用時に「Always Allow」の確認ポリシーを選び、個別の動作監視をやめてしまう
- エージェントはIssue一覧を巡回する中で攻撃ペイロードを発見し、非公開リポジトリのデータをコンテキストに取り込んだ後、
pacmanリポジトリのpull requestへ流出させた - 公開PRには、ユーザー
ukend0464の非公開情報が含まれていたJupiter Starのような非公開リポジトリ情報- 南米へ移住しようとしている計画
- 給与情報
- エージェントの推論全体とツール使用順序は、Invariant Explorerの完全なtraceで確認できる
信頼されたツールでも発生するToxic Agent Flow
- この脆弱性は、MCPツール自体が侵害される必要がある従来のツール汚染攻撃とは異なる
- GitHubのような外部プラットフォームに接続されたエージェントが信頼できない情報にさらされると、ツール自体が完全に信頼されていても問題が生じうる
- エージェントシステムにおいて、このようなフローを理解し、分析し、緩和する作業を手動で大規模に行うのは難しい
- Invariantは、組織が悪意ある行為者に悪用される前に潜在的脅威を特定・モデル化できるよう、Toxic Agent Flow検出を自動化する方法を開発している
適用範囲と緩和策
- 実験はClaude Desktopに焦点を当てていたが、この脆弱性は特定のエージェントやMCPクライアントに限定されない
- GitHub MCP serverを利用するすべてのエージェントが、基盤モデルや実装に関係なく影響を受ける可能性がある
- 重要なのは、この問題がGitHub MCP serverコード自体の欠陥ではないという点である
- サーバー側パッチだけでGitHubが単独解決できる脆弱性ではない
- エージェントシステムレベルで扱うべき構造的問題である
-
細粒度の権限制御
- GitHubのようなMCP連携を使う場合、エージェントのアクセス権を必要なリポジトリに限定すべきである
- 従来のトークンベース権限は一定の保護を提供するが、エージェント機能を制限する硬直的な制約になりうる
- Invariantは、エージェントシステムに合わせた動的なランタイムセキュリティ層を推奨している
- Invariant Guardrailsは、エージェントワークフローに適応するコンテキスト認識型アクセス制御を提供する
- 例として、1セッションで1つのリポジトリにのみアクセスを制限し、リポジトリ間の情報漏えいを防ぐポリシーがある
- 異なる
repoまたはownerに対するリポジトリ関連ツール呼び出しが続いた場合、違反として扱う - 完全なポリシーはgithub_policy.txtで確認できる
- 適用方法はMCP-scan documentationにある
- Guardrails Playgroundでデプロイ前にポリシーをテストできる
-
継続的なセキュリティ監視
- 予防策に加え、リアルタイムの脅威検知と対応のための監視が必要である
- Invariantは、エージェントとMCPシステム間の相互作用を継続的に監査するため、MCP-scanのような専用セキュリティスキャナの導入を推奨している
- MCP-scanのproxy modeは、既存のエージェントインフラを変更せずにMCP接続をリアルタイムでスキャンできるようにする
- MCPトラフィックをプロキシ経由でルーティングすれば、可視性とリアルタイムのセキュリティ違反スキャンを得られる
- 包括的な監視は監査証跡を作り、潜在的脆弱性、悪用の試み、新たな攻撃に対する保護状況の確認に役立つ
モデルアラインメントだけでは不十分
- 実験では、最新のアラインメントおよびセキュリティ訓練が適用されたClaude 4 Opusが使われた
- 強力な安全訓練があっても、エージェントは比較的単純なプロンプトインジェクションで操作されうることが示された
- 多くの既存プロンプトインジェクション検出防御もこの攻撃を捉えられなかった
- エージェントシステムのセキュリティはコンテキストと環境に依存する
- 一般的なモデルアラインメント訓練では、あらゆるデプロイシナリオや組織ごとのセキュリティ要件を予測できない
- システムレベルのセキュリティ対策が、モデルレベルの保護機構を補完する必要がある
エージェントセキュリティに残る課題
- GitHub MCP serverを利用するエージェントは、悪意あるGitHub Issueを通じて操作され、非公開リポジトリのデータを公開リポジトリへ流出させられる可能性がある
- 今回の脆弱性はGitHub MCPに特化しているが、類似の攻撃は他の環境でも引き続き現れている
- Legit Securityは最近、GitLab Duoのリモートプロンプトインジェクション脆弱性を報告した
- 大規模な責任ある展開のためには、MCP連携とエージェントシステムにMCP-scanやGuardrailsのような専用セキュリティスキャナとポリシー制御が必要である
1件のコメント
大げさに見えますが、要するにプロンプトインジェクションに加えて、MCPが使える権限が多すぎることで起きた問題ですね。
なので、MCPの権限を外部から制御できるツールを宣伝しているような印象です。
外部から入力されるプロンプトと内部でのみ入力するプロンプトで、MCPが使える権限を分けられるとよさそうですね