GitHub MCPの悪用: MCP経由で非公開リポジトリにアクセス

 (invariantlabs.ai)
3 ポイント 投稿者 GN⁺ 2025-05-28 | 2件のコメント | WhatsAppで共有
  • GitHub MCP統合に深刻な脆弱性が発見され、攻撃者が悪意あるGitHub Issueを通じてユーザーのエージェントを操作し、非公開リポジトリのデータを流出させる可能性がある
  • この脆弱性はToxic Agent Flowという新しいタイプで、エージェントが悪性プロンプトによって望まないデータを公開リポジトリに露出してしまう
  • 脆弱性はツール自体の欠陥ではなくアーキテクチャ上の限界から生じており、単純な使用確認ポリシーなど現実的な運用習慣がリスクを高める
  • 効果的な防御のためには、きめ細かな権限制御や継続的なセキュリティ監視のような体系的なエージェント保護策の導入が必要
  • 単にモデルのアラインメントだけでは不十分であり、MCPおよびエージェント環境全体にわたるシステムレベルのセキュリティ対策が重要

概要

Invariantは広く利用されているGitHub MCP統合（14,000 stars）で非常に深刻な脆弱性を発見した。この脆弱性により、攻撃者は悪意あるGitHub Issueを作成してユーザーのエージェントを操作し、非公開リポジトリのデータを外部へ漏えいさせることが可能になる

この問題は、Invariantの自動化されたToxic Agent Flow検知スキャナーによって最初に発見された事例である。このようなシナリオでは、エージェントは意図しない行動を取るよう誘導され、データ漏えいや悪性コード実行などの被害につながる

最近は業界全体でコーディングエージェントとIDEが幅広く導入されているため、このような攻撃への警戒を高めることが重要な時期である

攻撃シナリオ

  • 攻撃の準備

    • ユーザーがClaude DesktopのようなMCPクライアントとGitHub MCPサーバーを接続している状態を想定
    • <user>/public-repo: 誰でもIssueを作成できる公開リポジトリ
    • <user>/private-repo: 非公開リポジトリ。企業内データなどを保管
    • 攻撃者は公開リポジトリに悪意あるIssue（プロンプトインジェクションを含む）を作成する
    • ユーザーが「public-repoのIssue一覧を見て」のような何気ない依頼をしたとき、エージェントは公開リポジトリのIssueを取得する過程でインジェクションにさらされる

  • 攻撃の流れ

    • エージェントが悪性Issueを読んだ瞬間、非公開リポジトリのデータをコンテキストとして取り込み、それを公開リポジトリにPRとして作成し、誰でもアクセスできる状態にしてしまう
    • この過程をToxic Agent Flowと定義しており、Invariantのセキュリティ分析器によって実環境内で自動検知できる

攻撃の実演

  • 例として公開リポジトリ(ukend0464/pacman)と非公開リポジトリ群を用いて攻撃を再現した
  • 攻撃者は公開リポジトリに悪意あるIssueを作成し、エージェントがそのリポジトリのIssue一覧を照会した際にプロンプトインジェクションが実行される
  • ユーザーがClaude 4 Opusにサポートを依頼すると、ClaudeはGitHub MCP連携を通じてインジェクションを実行する
    • Claude Desktopはデフォルトでツール使用時に確認を求めるが、多くのユーザーが「常に許可」ポリシーで運用しており、無意識に行動してしまう
  • エージェントは非公開リポジトリのデータを抽出し、公開PRとして露出させる
  • 実験では、非公開プロジェクト名、勤務地移転計画、給与などの機密情報まで流出した

Toxic Agent Flowsの検知

  • この脆弱性は、既存のMCPツール自体が侵害されていなくても、外部プラットフォーム（GitHub）から流入した信頼できない情報によって発生する
  • 大規模なエージェントシステムでは、この種のリスク分析と緩和を手作業で行うのは非常に複雑なため、Invariantは自動検知手法を開発し、先回りした脅威分析を可能にする機能を提供している

影響範囲と対応策

  • この脆弱性は特定のエージェント/クライアントに限定されず、MCPサーバーを使うすべてのエージェントに影響する
  • GitHub MCPサーバーコード自体の欠陥ではなく設計上の問題であり、GitHubサーバーのパッチでは解決できない
  • 2つの中核的な対応戦略を提案

1. きめ細かな権限管理

  • MCP統合環境では、エージェントが本当に必要なリポジトリにだけアクセスできるよう、最小権限の原則を適用する必要がある
  • 従来のトークンベースの認可だけでは、使い勝手の面で制約が大きい
  • Invariant Guardrailsのような動的なランタイムセキュリティレイヤーにより、ワークフローの文脈に応じてアクセス制御を強化できる
    • 例のポリシー: セッションごとに1つのリポジトリだけアクセスを許可し、リポジトリ間の情報漏えいを防ぐ
    • ポリシー定義の例: 
      raise Violation("You can access only one repo per session.") if:
    (call_before: ToolCall) -> (call_after: ToolCall)
    call_before.function.name in (...set of repo actions)
    call_after.function.name in (...set of repo actions)
    call_before.function.arguments["repo"] != call_after.function.arguments["repo"] or
    call_before.function.arguments["owner"] != call_after.function.arguments["owner"]
    • Guardrails Playgroundなどでポリシーを試せる

2. 継続的なセキュリティ監視

  • 予防策に加えて、エージェントとMCPシステム間の相互作用をリアルタイムでスキャンする強力な監視ツールが必要
  • 例: Invariant MCP-scanを導入して監視と異常兆候の検知を行う
  • 最新のproxyモードを活用すれば、現在のインフラを変更せずにMCPトラフィックだけをプロキシ経由にしてリアルタイム診断が可能
  • 包括的な監視により、脆弱性の検知、侵害の試みの記録、悪性フローの早期遮断が可能になる

モデルのアラインメントだけでは不十分な理由

  • 最新の大規模言語モデル（例: Claude 4 Opus）でさえ、単純なプロンプトインジェクション攻撃に容易にさらされる
  • 基本的なアラインメント学習だけでは、実運用環境における多様で文脈依存的な攻撃をすべて防ぐことはできない
  • したがって、システムレベルの文脈検知とセキュリティ体制を、モデル段階とは別に必ず構築しなければならない

結論

  • InvariantはGitHub MCPサーバーでエージェントを悪意あるGitHub Issueで乗っ取り、非公開リポジトリを流出させる深刻な脆弱性を実証した
  • この脆弱性はInvariantの自動検知システムで発見された代表的事例であり、MCPをはじめとするさまざまな環境で同様の攻撃が継続して発生している
  • MCP-scanやGuardrailsなどの専用セキュリティスキャナーによって、MCP/エージェントシステムの安全な導入と運用を実現することが重要である

参考・問い合わせ

  • 追加のセキュリティ適用やコンサルティングが必要な場合は、earlyaccess@invariantlabs.ai まで連絡可能

著者:
Marco Milanta
Luca Beurer-Kellner

関連記事

2件のコメント

 
crawler 2025-05-28

大げさに見えますが、要するにプロンプトインジェクションに加えて、MCPが使える権限が多すぎることで起きた問題ですね。
なので、MCPの権限を外部から制御できるツールを宣伝しているような印象です。
外部から入力されるプロンプトと内部でのみ入力するプロンプトで、MCPが使える権限を分けられるとよさそうですね
 
GN⁺ 2025-05-28
Hacker Newsの意見

  • この攻撃がいまひとつ完全には理解できていない。Claude にアクセストークンを渡せば、どんな用途に使うよう指示していても、Claude はそのトークンの権限内で何でもできるよう誘導されうる、という話だ。LLM に認証情報を与えるなら、その認証情報が持つあらゆる権限を LLM が利用できると考えるべきだ。特にツール使用の呼び出しを自動承認している場合は要注意だ。ただし GitHub には細かく権限を絞れるアクセストークンがあるので、特定のリポジトリだけにアクセス可能な権限だけを与えれば、LLM が悪用されうる範囲は限定される。この攻撃は LLM がアカウント全体へのアクセスを持っている場合にのみ可能で、そんな危険な認証情報を Claude に渡すこと自体が問題だ

    • この話題で重要なのは、ほとんどのプロンプトインジェクション攻撃と同じく、LLM に攻撃者が操作するデータ、機密情報、データ流出機能の少なくとも 3 つのうち 2 つへ同時にアクセスできる環境が与えられている点だ。エージェント設計の基本原則は、一度に 2 つまでしか許さないことにあるし、そうしたルールで設計してこそセキュリティ問題を防げる。たとえば信頼できない人が作った issue を見た時点で、LLM のコンテキストはすでに攻撃者が作ったデータで汚染される。その次に機密情報へアクセスするなら、インターネット接続のような機能は無効化すべきだ。このモデルに従えば、リポジトリごとのトークンがなくても安全だ。残念ながら MCP にはこれを保証する仕組みがない

    • トークン権限が広すぎるという問題はあるが、同時に開発者はリポジトリごとに 1 つずつトークンを開いておきたくはない。だからトークンに広範な権限を与えたうえで、LLM を無条件に信頼してしまう。この注意深さは賢明だが、現実には多くのエコシステム参加者がそんな実践をしていない。今回のレポートが重要なのも、LLM は権限と信頼できないデータさえあれば何でもハイジャックされうると教育している点にある。解決策は、トークンの利用範囲を動的に制限することだ。私たちは このリスト でその方法を研究している

    • これは Railway のようなサービスでも起こりうる問題だ。Railway は単一プロジェクトのデプロイでも GitHub リポジトリ全体へのアクセス権を要求することがあるが、Netlify は望むリポジトリだけに権限を与えることを尊重している。GitHub はこうしたアクセス権を尊重しないアプリは承認自体を拒否すべきだ

    • 新しい技術が出るたびにいつも繰り返される現象だ。まるで基本的なセキュリティ原則が新しい文脈では無視していいかのように錯覚してしまう。実際にはどんな「キラキラした」最新技術を使おうと、基本的なセキュリティ原則は決して無視してはいけない。暗号資産界隈でも、過去の詐欺や金銭犯罪がそのまま再現されたのは、技術が違うという理由で以前の教訓を無視した結果だ

    • チャットボットがユーザーと相互作用するなら、そのチャットボットは許された範囲内で何でもすると前提すべきだ。チャットボットは API の上に載った利便レイヤーにすぎず、それ自体がセキュリティ機構ではないのは明らかだ

  • MCP やエージェントセキュリティに関心があるなら、これまでに取り組んだ資料がいくつかある。攻撃シナリオ全体に対する Claude の実行トレース(リンク)、MCP 接続用セキュリティスキャナー(リンク)、MCP ツール汚染攻撃(ブログ)、WhatsApp MCP のエクスプロイト事例(ブログ)、エージェント向けセキュリティレイヤー Guardrails(ブログ)、AI エージェントのセキュリティとユーティリティを共同評価する AgentDojo(ブログ) を参照

  • これが本当に「エクスプロイト」と呼べるのか疑問だ。エージェントに非公開リポジトリへアクセスできるトークンを与えれば、アクセスできて当然だ。MCP はただの API サーバーだ。API で公開しないものには、権限も与えないのが正しい

    • 多くの人と同じく、私も記事を読む前にコメントから見た。実際の記事内容を見ると、悪意ある issue が GitHub に登録され、その issue の中に LLM を使ってデータ流出を誘導するプロンプトが含まれている。リポジトリ所有者がエージェントをトリガーすると、エージェントがその悪性プロンプトに従って行動するようにさせるものだ

    • これは人間のミス、あるいは過信を悪用する真のエクスプロイトだ。人々が誇大宣伝に乗せられて、GitHub 全体にアクセスできる私的で機密性の高いトークンを安心して LLM に渡してしまうことが問題だ

    • 話題が重要なので少し突っ込みたいが、AI ツール実行の危険性を皆が正確に理解する必要がある。エージェントは現在、注意対象つまりコンテキストに応じてツールを実行するが、その注意対象はツール実行結果やプロンプトの影響を受けやすい。なのにコメント欄では単に「トークンを渡したから起きたことだ」という主張ばかりが繰り返されている。さらに、問題をきちんと説明した後でも「ユーザーが許可したからだ」といった形で論点をぼかし続けるのが残念だ。これは confused deputy 問題に対する古典的な誤った主張だ。また「ユーザー責任論」を掲げつつ、実際には MCP がアクセス後の制御機能やログを提供していないこと自体が問題でもある。私は必ず記録（logging）を残せるようにしておくべきだと思う。加えて、セキュリティ研究を無視して「常識だ」と非難するが、セキュリティの話は常に有益だ。脆弱性が弱いからといって語る価値がないわけではない。SQL インジェクションと同じだとさえ言える。そして、システムを間接的に汚染する、つまり公開 issue の登録を通じて悪意あるコードを届けるという視点を理解できないのは危険だと思う。最後に、防御的になるばかりでなく新しい意見に開かれているべきなのに、そうなっていないのが残念だ

  • セキュリティの観点から見ると、LLM が信頼できないソースのテキストを見るときは、そのソースが LLM の出力生成を望むままに操作できると仮定すべきだ。その結果がツール呼び出しにつながるなら、今度は信頼できないソースもそのツールを使えることになる。関連情報を探していて、invariant labs の Guardrails ドキュメント もマーケティング的な性格を帯びているなと思った。セキュリティ的に、こうした guardrail 製品が必要になるほど構造が難しいというのは不気味だ。そもそも AI 企業がセキュリティ中心で設計していれば、こんな製品まで必要なかったのにという残念さもある

    • 入力値の区別さえしっかりすれば簡単な問題だ。プロンプトに <github_pr_comment> のようなタグでマーキングし、必ず読み取り専用として扱い、決して命令として解釈するなと明示すればいい。今回の攻撃は実際には構造が少し複雑だ。以前のチャットボットのプロンプトインジェクション問題のときと似た感じだ。今では MCP も問題になっている

    • 一部のテキストを未精製の、つまり不純なデータとしてマーキングし、LLM がその部分の命令的な解釈を無視するよう訓練する方法も可能なのか気になる

    • 実際、AI 企業はセキュリティ設計を念頭に置いている。ただし今回の「エクスプロイト」は、セキュリティを無効化したときにしか成立しないシナリオだ（太字の警告付きで提供されている）。たとえば Claude Desktop はデフォルトで各ツール呼び出しごとに直接の許可確認を求める。だが多くのユーザーが「常に許可」に設定してしまい、個々の動作を監視していない

    • こうしたソフトウェア脆弱性のパターンは伝統的に繰り返されてきたし、新しい技術でも常に現れるのが面白くもあり呆れるところだ。「ユーザー入力を受け取り、十分に防御されていない環境で命令のように解釈して実行する」というパターンはずっと繰り返されている。SQL インジェクション、XSS、PHP include などで何度も見た話が、今度は LLM にまで繰り返されている

  • MCP 自体が革新的だったり、ハッキングに特別弱かったりするとは思わない（もちろん MCP については別の考えはある）。プロンプトインジェクション手法をマーケティング的に包み直した感じだ。私がエージェントシステムを設計するときは常に、「エージェントがアクセスできるものはすべて、そのエージェントにアクセスできる誰もがアクセスできる」という哲学を使う。LLM にアクセス制御を任せず、エージェントが行うこと自体のセキュリティ責任は常にリクエスト主体本人にあることを明確にする。この記事を最初から最後まで見て、本当に注目すべきなのはエージェントに実際どんなリソースへアクセスさせるかだ。メールデータへのアクセスを許し、プロンプトインジェクション入りのメールがセキュリティトークンを盗んで送信するよう LLM を誘導するなら、それこそが本当に深刻なリスクだ

    • MCP という話を付け足すのは、まるで 10 年前の「ブロックチェーンに載せました」という流行のように感じる。「LLM が承認と行動の主体なのだから最小権限の原則を厳格に適用すべきだ」というのは経験者には自明の話だが、もしかするとまた新しい世代がこうした基本を学び直さなければならないのかもしれない

  • 実際の攻撃事例とエージェントの反応は ここ で確認できる。エージェントが攻撃を完全に成功させてしまった点は少し笑ってしまう

  • 私も 1 週間前に Google's Jules コーディングエージェントを試したが、GitHub OAuth の権限要求がアカウント内のすべてのリポジトリと権限への全面的なアクセスを求めていた。こうした設計は開発者の利便性ゆえでもあり、GitHub OAuth 認証フロー自体も原因だ。本来はもっと簡単に、リポジトリ単位の制限付き権限付与や後からの追加権限要求ができるべきだ。しかし現実には、特定のリポジトリだけ権限を与える別の GitHub アカウントを作るしかない（例のアカウント）。かなり面倒だ。GitHub の公式ドキュメントでもこうしたマシンユーザーを別に作ることを勧めてはいるが、デフォルトでのリポジトリ範囲指定はもっと簡単であるべきだ。もっと良いやり方を知っている人がいたらぜひ教えてほしい

  • 今回の記事の主張はかなり誇張されていると感じる。単純な issue でデータ流出が起きたという説明に対して、実際にはユーザーが複数のセキュリティ上危険な措置をすべて自分で取って初めて可能になったことだからだ。つまり、MCP サーバーを設定し、public/private repo の両方にアクセスできる認証情報を与え、LLM にそのサーバーアクセスとリポジトリ issue の読み取りを許可し、さらに悪意ある issue まで自分で読ませ、結果を外部に公開するような設定にしなければ成立しなかった。悪い結果ではあるが、これを実際に「他者が悪意をもって攻撃するセキュリティ脆弱性」と呼べるものではない。ユーザー自身が信頼できないデータを読み、結果も信頼できない場所へ出力するようにした結果だ。それでも GitHub MCP にも一定の責任はある。公開リポジトリと非公開リポジトリの間の横断処理を防がなかったのは問題だ

    • 本質的に、「issue を要約してください」程度の単純な命令だけでも、悪意ある issue 内に直接書かれた命令が実行されうる点を見落としてはいけない

    • MCP マーケティングの観点も重要だ。プロトコル自体は信頼できる環境やユーザーだけがアクセスできるように分離するのが正しい。MCP サーバーにスコープ指定や認証を行う標準的な方法がないのが問題だ。私は GitHub MCP そのものより、業界全体の使い方や実装方法に根本的な問題があると感じる。実際、カスタム MCP サーバーを使うときは AI 以外の情報（ID、JWT など）も追加で渡してセキュリティ遮断をかけている

    • 最近の AI ブームのせいで、実際にはこうした危険な設定やフローを深く考えずに適用してしまう人が多いのが現実だ。「こんなもの使うべきじゃない」ともっともらしく言うことはできるが、だからこそ guardrails（安全レール）が必要なのだ。人はしばしば危険な判断をするからだ

    • 公開リポジトリと非公開リポジトリを混ぜて使うなという主張については、実際にはこれは完全に分離されたツール呼び出しだ。MCP サーバー側からはその相互作用を検知する方法がない

  • この議論が 該当の HN スレッド で行われていることに気づいた

    • 向こうでもすでに言及されていたが、セキュリティ上のリスクは明白だ。つまり、システムに私的データへのアクセス権を与え、外部ユーザーにも任意の入力テキストを入れられるよう許可すれば、結果として外部ユーザーに非公開データまで間接的に提供することになる。標準的なセキュリティ慣行を守るだけで簡単に防げる問題だ

    • 現在コメントは ここ に移動して集まっている

  • MCP は単なる 1 つのプロトコルにすぎず、A2A など類似ケースや原始的なアプローチも多い。LLM に GitHub API ドキュメントを読ませて、トークンで API を使えと指示することもできる。まだすべての LLM がこのレベルの機能を持っているわけではないが、じきにそうなるだろう。ツール登録メカニズムを完全に安全化するのは、現実的にはほとんど不可能に近い。データ流出の最終責任は結局 LLM にある。開発者は LLM による生産性向上を望むので、安全性が担保されるか、さもなければすべてのノートPCにセキュリティファイアウォールを追加しなければならない状況にまで行くかもしれない。本当に厄介なのは、将来は LLM がセキュリティファイアウォールまで悪用した「悪い振る舞いをする LLM を捕まえる LLM」の対決にまで発展しそうなことだ