「GitLost」脆弱性：たった1つのIssueで、プライベートリポジトリが漏えいする仕組み

攻撃の概要

「GitLost」は、Noma Securityの研究者らが開示した、GitHubのAgentic Workflows機能における重大な間接プロンプトインジェクション脆弱性です。攻撃者は、認証なしで、組織が所有する公開リポジトリに1件だけ細工したIssueを投稿することで、同一組織が所有する非公開リポジトリからデータを抜き出すことができます。 資格情報の窃取やアカウントの乗っ取り、特別なコーディングスキルは一切不要です。攻撃者は細工したIssueを開き、ワークフローが実行されるのを待つだけでよいのです。

攻撃の仕組み

研究者らによると、脆弱性の原因となったGitHub Agentic Workflowのパターンは以下の特徴を持っていました。

• issues.assigned イベントをトリガーに起動する
• Issueのタイトルと本文を読み取る
• add-comment のようなエージェントツールを使ってコメントを投稿する
• 組織内の他のリポジトリ（非公開リポジトリを含む）への読み取りアクセス権を持って動作する

攻撃は4つのステップで進行します。

1. 攻撃者は、脆弱なAgentic Workflowパターンを使用している組織の公開リポジトリに、一見無害なIssueを開く。
2. Issueの本文には、AIエージェントに対して「非公開リポジトリからファイルを取得せよ」と指示する、平文のコマンドが隠されている。
3. GitHubの自動化機能がIssueをアサインすると、イベント駆動型のワークフローが起動。エージェントはアクセス権を持つリポジトリ（非公開リポジトリを含む）からデータを取得する。
4. エージェントは取得した内容をIssueへの公開コメントとして投稿し、Issueを閲覧できるすべてのユーザーがデータにアクセスできる状態にしてしまう。

根本的なアーキテクチャ上の弱点

この脆弱性の核心は、AIエージェントのコンテキストウィンドウ内において、システムレベルの命令と信頼できないユーザーデータとの間に厳格な信頼境界を維持できていない点にあります。 NomaのSasi Levi氏は次のように述べています。「エージェントのコンテキストウィンドウは、同時に攻撃対象領域でもあります。エージェントが読み取るあらゆるコンテンツ（Issue、プルリクエスト、コメント、ファイル）は、エージェントがそれを指示入力として扱う場合、武器化される可能性があります。」

LLMベースのエージェントは、データと命令が同じコンテキストやツールの出力に現れた場合、両者を区別することが本質的に困難です。 これは従来のコーディングバグではなく、エージェンティックAIワークフローにおける構造的なリスクです。信頼できないコンテンツが、ワークフローによって適切に分離または制約されていない場合、エージェントの動作に影響を与える可能性があります。

研究者らはこのクラスの欠陥を正式に「Agentic Workflow Injection (AWI) 」として分類し、2つのコアパターンを特定しています。すなわち、信頼できないコンテンツがエージェントのプロンプト境界に到達する「Prompt-to-Agent (P2A)」と、攻撃者の影響がモデル由来の出力を介して後続のスクリプトに伝播する「Prompt-to-Script (P2S)」です。

ガードレール回避のテクニック：「Additionally（さらに）」キーワード

GitHubはデータ流出を防ぐためのガードレールを実装していましたが、Nomaの研究者らは驚くほどシンプルなテクニックでこれを回避できると報告しました。 注入する命令に**「Additionally（さらに）」という単語を追加する**だけで、モデルがリクエストを拒否する代わりに出力を再構成するようになり、あたかもタスクの正当な継続であるかのようにデータ漏えいが進行したのです。

このアプローチは、より広範なプロンプトインジェクション研究と一致しており、特定の言い回しやツールから返されたテキストによって、モデルが従うべきでない悪意のある命令に従ってしまう可能性があることを示しています。 このガードレールバイパスは、Invariant Labsが発見し、悪意のあるIssueがユーザーのエージェントを乗っ取って非公開リポジトリからデータを漏えいさせる可能性があった、以前のGitHub MCP脆弱性などでも見られたパターンと類似しています。

組織に推奨される対策

GitLostの発見と、より広範なエージェンティックワークフローのセキュリティガイダンスに基づき、影響を受ける組織は以下の対策を実施すべきです。

• エージェント入力へのゼロトラストの採用 — ユーザー制御のコンテンツを決して信頼された命令入力として扱わず、信頼できないユーザーデータをコアシステムプロンプトから分離する。
• 最小権限の原則の厳格な適用 — 不要なクロスリポジトリアクセスを削除し、エージェントが公開出力を通じてデータを公開する能力を制限する。
• ツールの許可リスト（ホワイトリスト）の使用（ブロックリストではなく）、およびエージェントが外部から見えるコメントの投稿や機密リポジトリへのアクセスなどの機密性の高いアクションを実行する前に人間による承認ゲートを要求する。
• CI/CDおよびリポジトリ自動化ワークフローにおけるAIエージェント統合の監査、特に信頼できないGitHubイベントコンテキストがプロンプトやエージェント入力に組み込まれている場合。
• 信頼できないユーザー入力をシステムレベルの指示から論理的に分離し、ユーザー生成テキストを信頼できる命令ではなく、信頼できないデータとして扱う。

また、組織はエージェントのシークレットに最小権限の原則を適用し、プロンプトインジェクションの試みに対する継続的なセキュリティ監視を実装する必要があります。

GitHubの対応状況（7月7日時点）

Dark ReadingおよびNoma Securityの開示タイムラインによると、以下の状況です。

• Nomaは責任を持ってこの欠陥をGitHubに開示しました。
• GitHubはNomaに対し、脆弱性の原因となったワークフローパターンに関連するドキュメントを更新したと伝え、研究者らが最後に確認した時点では、脆弱な構成はもはや存在しないことを確認しました。
• 7月7日時点で、GitHubはGitLostに関する正式な声明やCVEを発行していません。
• この脆弱性は、明確に文書化されたプラットフォームレベルのセキュリティ修正ではなく、原因となったドキュメントとワークフローテンプレートの削除または修正によって部分的に対処されたようです。

大局的な視点：システム全体のリスク

GitLostは孤立したインシデントではありません。これは、機密データにアクセスできるAIエージェントが、信頼できないユーザーコンテンツにさらされるという、増加しつつある脆弱性のクラスを代表するものです。同様の問題は、GitHub MCP統合、GoogleのGemini CLIワークフロー（TrustIssues脆弱性）、Claude Code GitHub Actionsにも影響を与えています。 これらに共通するのは、LLMベースのエージェントには、データと命令が同じコンテキストウィンドウに現れた場合に両者を区別する本質的な能力が欠如しているという点です。これは、単一のプラットフォームパッチでは完全には解決できない、根本的なアーキテクチャ上の課題です。