GitHubの新機能 Agentic Workflowsに深刻な脆弱性 GitLost|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月09日更新日時: 2026年07月09日

セキュリティ企業Noma Security(Noma Labs)は、GitHubが新たに提供を開始したAgentic Workflowsに、認証を必要としない攻撃者でも組織のプライベートリポジトリの中身を静かに持ち出せてしまう、重大なプロンプトインジェクションの脆弱性を発見し、GitLostと名付けて公表しました。攻撃者は公開リポジトリにIssueを1件投稿するだけでよく、アカウントの侵害やソフトウエアの脆弱性を突く必要は一切ありません。当サイトでも以前、GitHub CodespacesとCopilotの連携を悪用しGitHubの機密情報が漏洩しうる脆弱性RoguePilotや、GitHub Copilot Chatの脆弱性によるプライベートリポジトリからの情報持ち出しを取り上げましたが、今回のGitLostはGitHubの新機能であるAgentic Workflowsを対象にした、同じ系譜にある最新の事例です。

サマリー

Noma Securityは、GitHubの新機能Agentic Workflowsに存在する重大なプロンプトインジェクションの脆弱性を発見し、GitLostと名付けて公表した
Agentic Workflowsは、GitHub Actionsの自動化機能と、ClaudeまたはGitHub Copilotを基盤とするAIエージェントを組み合わせ、平文のMarkdownでワークフローを記述できる新機能
検証対象のワークフローは、Issueが担当者に割り当てられた際に起動し、Issueのタイトルと本文を読み取り、add-commentツールでコメントを投稿し、組織内の他のリポジトリ(公開・非公開の両方)への読み取り権限を持つよう設定されていた
攻撃者は、営業担当役員が顧客訪問後に投稿したような、ごく普通に見えるIssueを公開リポジトリに作成するだけでよく、認証情報や技術的なハッキングスキルは一切不要
Issueが担当者に割り当てられ自動化が起動すると、エージェントは非公開リポジトリを含む複数のリポジトリからREADME.mdの内容を取得し、その内容を誰でも閲覧できる公開コメントとして投稿してしまう
GitHub側はサンドボックス化や既定での読み取り専用トークン、入力のクリーニング、投稿前に出力内容を検査する脅威検知の仕組みといったガードレールをすでに備えていたが、悪意ある指示の先頭にAdditionally(加えて)という一言を付け加えるだけで、これらのガードレールをすり抜けられたとされる
GitLostはGitHubへ責任ある開示のプロセスを通じて報告済みで、脆弱性の詳細はGitHub側の把握のもとで公開されている

項目	内容
発見者	Noma Security(Noma Labs)、主任研究者:Sasi Levi氏
脆弱性名	GitLost
対象機能	GitHub Agentic Workflows(ClaudeまたはGitHub Copilotを基盤とするAIエージェント)
脆弱性の種別	間接的プロンプトインジェクション
攻撃条件	認証不要、対象組織の公開リポジトリにIssueを1件投稿するだけ
検証したワークフロー設定	issues.assignedイベントで起動、Issue本文を読み取り、add-commentで応答、他リポジトリ(非公開含む)への読み取り権限あり
ガードレール回避の手口	悪意ある指示の先頭にAdditionallyという一語を付加
開示状況	GitHubへ責任ある開示済み、GitHub側の把握のもとで詳細を公開
影響	プライベートリポジトリの内容(READMEなど)が公開コメントとして漏えい

1 何が起きたか
2 GitHub側のガードレールを回避した「Additionally」という一言
3 原因はエージェントの権限と信頼できない入力が同居する構造にある
4 同種の脆弱性が相次ぐGitHubのAIエージェント機能
5 情報システム部門への示唆
6 出典

何が起きたか

GitHubは近年、GitHub Actionsが持つイベント駆動型の自動化機能に、ClaudeまたはGitHub Copilotを基盤とするAIエージェントを組み合わせたAgentic Workflowsという新機能を提供しています。この機能を使うと、開発チームは自然言語に近い平文のMarkdownでワークフローを記述でき、GitHub側がこれをYAML形式のActionsファイルへ自動的に変換して実行します。エージェントはIssueを読み取り、各種ツールを呼び出し、組織内の他のリポジトリへアクセスするといった処理を、人間が逐一確認することなく自律的に実行できます。

Noma Labsが検証したワークフローの設定は、Issueが誰かに割り当てられた際に起動し、そのIssueのタイトルと本文を読み取ったうえでadd-commentというツールを使って応答し、さらに組織内の他のリポジトリ(公開・非公開の両方を含む)を読み取る権限を持つというものでした。Noma Labsは、営業担当役員が顧客訪問の後に投稿したような、ごく日常的で疑わしさのないIssueを公開リポジトリ上に作成し、これが誰かに割り当てられて自動化が起動すると、エージェントは非公開リポジトリを含む3つのリポジトリからREADME.mdの内容を取得し、その内容をもとのIssueへの公開コメントとして投稿してしまうことを実証しました。この一連の流れにおいて、攻撃者側には認証情報もコーディングスキルも一切必要とされていません。

GitHub側のガードレールを回避した「Additionally」という一言

GitHub自身も、こうした問題が起こりうることを見越して複数のガードレールを用意していました。具体的には、サンドボックス化された実行環境、既定で読み取り専用に設定されるトークン、入力内容のクリーニング処理、そしてエージェントが投稿しようとする出力内容を事前に検査する脅威検知の仕組みです。GitHubは自社のドキュメントの中でも、AIエージェントがプロンプトインジェクションや悪意あるリポジトリの内容、侵害されたツールによって操作されうることを明記し、対策を講じていました。

しかしNoma Labsの検証では、悪意ある指示の文言の先頭にAdditionally(加えて)という一語を付け加えるだけで、これらのガードレールをすり抜けられたとされています。

この一語があることで、モデルはその指示を拒否すべき不審な要求としてではなく、既存のタスクに続く自然な追加タスクとして扱ってしまい、ガードレールがこれを見逃してしまったというわけです。わずか一語の言い回しの違いが、複数層にわたる防御をまとめてすり抜ける結果につながった点は、この種の対策がいかに脆いバランスの上に成り立っているかを物語っています。

原因はエージェントの権限と信頼できない入力が同居する構造にある

Noma SecurityのSasi Levi氏は、GitLostが単発の実装ミスではなく、AIエージェントに恒常的な認証情報を持たせたまま、攻撃者が到達可能なテキストを処理させるという構造そのものに起因する必然的な結果だと説明しています。エージェントが読み取るコンテキストウィンドウそのものが攻撃対象領域になり、Issueであれプルリクエストであれコメントであれファイルであれ、エージェントがその内容を指示として扱ってしまう限り、あらゆる読み取り対象が武器になり得るという指摘です。

海外の報道では、この問題を従来型のソフトウエアセキュリティとの対比で説明しています。従来型のソフトウエアセキュリティは、信頼の境界がコードの中で明示的に強制されることを前提としてきましたが、エージェント型のシステムはモデルの振る舞いに依存しており、指示に従うよう訓練されたモデルである以上、本質的にこの種の手口に対して脆弱だという整理です。海外の専門家の間では、プロンプトインジェクションがAIセキュリティにおいて果たす役割を、WebアプリケーションセキュリティにおけるSQLインジェクションになぞらえる見方も広がっており、個別の実装を直すだけでなく、体系的な防御が求められる脆弱性のクラスとして扱う必要があるという認識が強まっています。

同種の脆弱性が相次ぐGitHubのAIエージェント機能

GitLostは、GitHubのAIエージェント関連機能を巡って繰り返し報告されてきた問題の最新の一例にすぎません。当サイトで既報の通り、2026年2月にはOrca Securityの研究チームが、GitHub CodespacesとCopilot Agent Modeの連携を悪用するRoguePilotという手口を報告しており、Issue本文がCodespaces内のCopilotへ自動的にコンテキストとして流入する設計を突いて、GITHUB_TOKENの奪取からリポジトリの乗っ取りにまで発展しうる問題が指摘されていました。また、Legit SecurityのOmer Mayraz氏は、プルリクエストの隠しコメントとGitHubの画像プロキシ基盤を組み合わせた手口で、GitHub Copilot Chatからプライベートリポジトリの機密情報を持ち出せることを示していました。GitHub公式のMCPサーバーについても、2025年5月にInvariant Labsが同種の問題を報告しており、海外のセキュリティ研究者はこうした一連の攻撃をトキシック・エージェント・フロー(有害なエージェントの処理経路)と呼んで警鐘を鳴らしています。今回のGitLostは、対象となる機能こそAgentic Workflowsという新しいものですが、根本にある構造的な課題は、これらの過去の事例と共通しています。

情報システム部門への示唆

自組織でGitHub Agentic Workflowsをはじめ、GitHub Copilot Agent ModeやMCP経由でのGitHub連携など、AIエージェントにGitHubリポジトリへのアクセス権限を与えている場合は、今回の事例を踏まえた点検が必要です。Noma Labsは、ユーザーが制御できるコンテンツを信頼できる指示として扱わないこと、権限は必要最小限にスコープを絞ること、特にリポジトリをまたぐアクセス権を持つエージェントは重点的に警戒すること、エージェントが外部に公開できる内容を厳しく制限すること、そしてユーザー入力を指示のコンテキストから分離・サニタイズすることを推奨しています。

具体的な運用としては、自動化ワークフローに組織内の複数リポジトリ(特に非公開のもの)への読み取り権限を安易に付与しないことが重要です。どうしても複数リポジトリへのアクセスが必要な場合は、そのエージェントが外部からの入力(Issueやコメントなど)を直接処理するのではなく、人間によるレビューを介するステップを挟むことをお勧めします。あわせて、当サイトで以前紹介したMicrosoft Scoutを巡るセキュリティ懸念でも触れた通り、間接的プロンプトインジェクションはもはや個別のバグではなく、常時稼働型のAIエージェント全般に共通するクラスレベルのリスクとして扱う必要があります。自社が導入しているAIエージェントの棚卸しを行い、それぞれが持つ権限の範囲と、外部からの入力をどこまで信頼できる指示として扱っているかを、継続的に見直す体制を整えることをお勧めします。