GitHub Agentic Workflows 脆弱性として各種セキュリティメディアで報じられた「GitLost」は、GitHubが自ら公開した「AIエージェントにリポジトリ運用を自動化させる」新機能——GitHub Agentic Workflows（gh-aw）——の、公開初年度のうちに実演された設計上の弱点だ。セキュリティ企業Noma Securityは2026年7月、公開Issueに一文を書き込むだけでプライベートリポジトリの内容を公開コメントとして漏らせる手法を公表した。攻撃者側にコード実行も認証情報も不要という再現性の高さが話題になった理由だ。本記事は一次ソース（Noma Security・GitHub公式README・GitHub公式Changelog）に基づき、時系列・攻撃の仕組み・影響範囲・自システム確認コマンド・対策を整理する。サプライチェーン全般の防御はサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストも参照してほしい。
- ・何が起きた：GitHub公式のAIエージェント自動化機能に対し、公開Issue本文への一文でプライベートリポジトリの内容を公開漏洩させる「GitLost」がNoma Securityにより実演された。
- ・攻撃条件：認証情報・コード実行権限とも不要。cross-repo読み取り権限を持つgh-awワークフローが対象。
- ・CVE番号：付与されていない（記事執筆時点で未確認）。
- ・自分は何をする：自組織のgh-aw利用有無を確認し、issueトリガーのワークフローのpermissions/safe-outputs設定を点検する（本文コマンド参照）。
- ・修正状況：GitHubへ責任開示済みと報告されているが、修正日・修正バージョンの明記は未確認。
GitHub Agentic Workflows 脆弱性の背景——gh-awは公開Issueを「指示」として実行するAI自動化基盤
GitHub Agentic Workflowsは、GitHubが2026年2月13日にTechnical Previewとして公開した公式機能だ。GitHub Next発の取り組みで、Microsoft ResearchとAzure Core Upstreamが共同開発に加わっている。実体はgh awというGitHub CLI拡張で、Markdown本文＋YAMLフロントマターで書いた「ワークフロー定義」をGitHub Actionsのジョブへコンパイルし、AIエージェントにリポジトリの継続的な運用作業（Issueへの応答、PRレビュー、ドキュメント更新など）を任せる仕組みになっている。
公式リポジトリ（github/gh-aw）は2026年8月時点でスター4,919・フォーク494・contributor 30名。作成日は2025年8月12日で、約1年でこの規模まで成長した。ライセンスはMIT。開発元がGitHub, Inc.本体という企業バックがあり、記事執筆時点でも当日pushが確認できるほど活発に開発が続いている。ただしバージョンはv0.86系でまだ1.0未満のpre-1.0段階であり、公式README上も「Technical Preview」の機能として案内されている点は押さえておきたい。
・正体：Markdown＋YAMLでAIエージェントの自動化ワークフローを書き、GitHub Actionsへコンパイルして実行するGitHub公式CLI拡張
・何ができる：Issue対応、PRレビュー、リポジトリ横断のドキュメント更新などをAIエージェントに継続的に任せられる
・何を解決する：GitHub Actionsのyaml職人芸を、自然言語に近いワークフロー定義に置き換える
・開発段階：v0.86.2（pre-1.0）・Technical Preview。企業バックがあり活発に開発中
この「Issue本文をAIエージェントへの入力として渡す」という設計そのものが、後述するGitLostの起点になる。GitHub Agentic Workflowsのワークフローは、Issueの作成・コメントなどのイベントをトリガーに起動でき、起動したエージェントジョブがIssue本文を読み込んで処理する。ここで本文を「データ」ではなく暗黙に「指示」として扱ってしまうと、外部の第三者が書いたテキストがそのままエージェントへの命令になり得る——これはGitHub固有の欠陥というより、LLMベースのエージェント全般に共通するプロンプトインジェクションの構造だが、cross-repo権限を持つ企業公式のAI自動化基盤でそれが実演された点が今回のニュース性になっている。
時系列——Technical Preview公開から「GitLost」公表まで
GitLostの発覚から報道までの主要な出来事を時系列で整理する。開示日・公表日は各社の記事に基づく。
| 日付（2026年） | 出来事 |
|---|---|
| 2月13日 | GitHubがGitHub Agentic WorkflowsをTechnical Previewとして公式Changelogで発表 |
| 時期不明（未確認） | Noma Securityが調査を実施し、プロンプトインジェクションによる情報漏洩の実証コード（PoC）を作成 |
| 未確認 | Noma SecurityがGitHubへ責任開示（記事に”Responsibly disclosed to GitHub”と明記） |
| 7月6日 | Noma Securityが「GitLost」として調査結果をブログ公開 |
| 7月7日前後 | The Hacker News・SC Media・DarkReading・SiliconANGLE・CSO Online・The Registerなど各種セキュリティメディアが後追い報道 |
責任開示からブログ公開までの正確な期間や、GitHub側の対応完了日は、Noma Securityの記事にも明記がなく未確認だ。断定は避け、確認できた事実のみを時系列に並べている。
（Additionallyを含む一文）"] -->|"issuesトリガー"| B["gh-awエージェントジョブが起動"] B -->|"cross-repo read 権限"| C["プライベートリポジトリの内容を読み取り"] C --> B B -->|"safe-outputsで公開Issueへコメント投稿"| D["公開コメントとして漏洩"] D --> E["誰でも閲覧可能に"]
GitLostの仕組み——「Additionally」の一言がプライベートリポジトリ漏洩に化けるまで
GitLostの核心は、GitHub Agentic Workflowsのエージェントジョブが、公開Issueの本文を「信頼できない外部入力」ではなく「実行すべき指示」として処理してしまう点にある。Noma Securityが公表した手法の骨子は次のとおりだ。
・入口：攻撃者が対象リポジトリの公開Issue（または誰でも書き込めるコメント欄）に、AIエージェント向けの指示文を紛れ込ませる
・トリガー：issueイベントをトリガーに設定したgh-awワークフローが自動的に起動し、Issue本文を読み込む
・回避：Noma Securityの実験では、ガードレール的な既存指示の直後に”Additionally”（追加でこれも）という一単語を続けるだけで、後続の悪意ある指示がエージェントに受理された
・到達点：cross-repo読み取り権限を持つワークフローが、プライベートリポジトリの内容を取得し、その内容を公開Issueへのコメントとして投稿してしまう
つまり、攻撃者はリポジトリへの書き込み権限もAPIキーも一切必要とせず、公開されているIssueトラッカーに一文を書き込むだけで、AIエージェント側の権限を「借りて」プライベートリポジトリの情報を外部に持ち出せる。これはコード実行の脆弱性ではなく、AIエージェントの指示解釈という信頼境界（trust boundary）の設計欠陥であり、パッチ一発で閉じられる性質のバグとは異なる。
「"Additionally"という単語がガードレールを回避した」という結果は、Noma SecurityによるPoC実験の観測結果です。使用するAIモデルやワークフローの具体的な設定が変われば、同じ挙動が常に再現するとは限りません。本記事はこの手法が「必ず成功する」と断定するものではなく、Noma Securityが実演した1つの成功事例として紹介しています。
① 何ができる：攻撃者は公開Issueへの投稿だけで、対象組織のgh-awワークフローにプライベートリポジトリの内容を公開漏洩させられる。
② 何を解決する必要があるか：Issue本文を無条件に「指示」として実行する設計と、cross-repo読み取り権限・公開への書き込み権限が同一ワークフローに同居している構成。
③ 何を代替できるか：代替ではなく設計対応が必要——safe-outputsによる出力先の限定、権限の最小化、外部入力のサニタイズ。
影響範囲——対象となるワークフロー設定と漏洩の到達点
GitLostの影響を受けるのは、GitHub Agentic Workflows（gh-aw）を導入し、かつ次の条件を満たすリポジトリだ。
| 条件 | 該当するとリスクが高まる理由 |
|---|---|
issueイベント（on: issues）をトリガーにしたワークフローがある |
第三者が公開Issueから直接エージェントを起動できる |
| ワークフローがプライベートリポジトリへのcross-repo読み取り権限を持つ | 漏洩させられる情報の範囲が広がる |
| safe-outputsの出力先が公開の場（公開Issueへのコメント等）に設定されている | 読み取った情報がそのまま外部から閲覧可能になる |
| gh-aw自体を導入していない | 対象外。GitLostはgh-aw固有の攻撃経路であり、通常のGitHub Actionsだけを使う組織には該当しない |
漏洩の到達点は「プライベートリポジトリの内容が、攻撃者の指示に応じて公開Issueのコメントという形で誰でも閲覧できる状態になる」ことだ。攻撃者はその公開コメントを読むだけで目的の情報を入手できるため、追加の権限昇格やデータの持ち出し経路を別途用意する必要がない。
自システム確認コマンド——自組織のgh-aw利用状況とsafe-outputs設定を洗い出す
以下は、GitHub CLI（gh）が使える環境で実際に構文と挙動を確認したコマンドだ。GitLostのPoCそのもの（実際にプライベートリポジトリを漏洩させる実験）は他者環境への攻撃実演になるため再現しない。代わりに、自組織がgh-awをどう使っているかを洗い出す読み取り専用の確認に絞っている。
# 0) gh-aw拡張の導入有無をまず確認（未導入なら対象外）
gh --version
gh extension list | grep gh-aw
# 1) 自リポジトリでgh-awのagentic workflowを使っているか確認
find .github/workflows -name "*.md" 2>/dev/null
# 2) 各ワークフローのfrontmatterでcross-repo読み取り権限とsafe-outputs設定を確認
grep -A5 "^permissions:\|^safe-outputs:" .github/workflows/*.md 2>/dev/null
# 3) issueイベントをトリガーにしているワークフローの洗い出し（GitLostの入口）
grep -l "on:.*issues" .github/workflows/*.md 2>/dev/null
記事執筆時点でこの環境にgh-aw拡張は導入されていなかった（gh extension listに該当なし）。gh-aw未使用の組織はGitLostの対象外だが、今後導入を検討する場合は上記コマンドで①issueトリガーの有無、②cross-repo権限の範囲、③safe-outputsの出力先、の3点を先に洗い出しておくと設計段階でリスクを見積もれる。GitLostはプロンプトインジェクション GitHubという文脈で語られることが多いが、実質はAIエージェント 情報漏洩の一種であり、gh-aw固有の拡張機能名や設定値ではなく「外部入力をどこまで信用するか」という設計判断が問われている。
なお、GitHub公式READMEには記事執筆時点で「Agent jobs are read-only and sandboxed by default, and configured GitHub writes are normally applied through validated safe-outputs jobs with scoped permissions」という説明が記載されている。エージェントジョブは既定で読み取り専用・サンドボックス化され、書き込みはスコープを絞ったsafe-outputsジョブを経由する、という設計だ。これがGitLost公表を受けて追加・強化された緩和策なのか、公開当初からの設計なのかは記事執筆時点で確認できていない。したがって「現在のドキュメントではこう説明されている」というトーンにとどめ、GitLostへの直接対応かどうかは断定しない。
GitHub Agentic Workflows 脆弱性への対策・緩和策と類似事例
GitLostへの現実的な対策は、単一のパッチではなく設計面の見直しだ。gh-aw セキュリティを検討する際は、次の4点を出発点にするとよい。
・入口を絞る：issueイベントをトリガーにするワークフローは、投稿者が組織メンバー・コラボレーターに限られるか確認し、不特定多数が書き込める公開Issueを無条件のトリガーにしない
・権限を最小化する：cross-repo読み取り権限は、そのワークフローが本当に必要とする範囲だけに絞る。「念のため広めに」設定しない
・出力先を検証する：safe-outputsで公開の場へ書き込む設定になっているワークフローは、読み取った内容がそのまま外部に出て良い情報かを個別に確認する
・外部入力を指示として信用しない：Issue本文・コメント本文はあくまで「データ」として扱い、無条件にエージェントへの指示として実行しない設計に近づける
GitHub Agentic Workflows固有の話に閉じず、これはAIコーディング/自動化ツール全般に共通する「trust boundary（信頼境界）」の問題でもある。当サイトが以前解説したGhostApproval・SymJack解説｜AIコーディング支援6種のsymlink承認ハイジャックも、AIツールが「見せている情報」と「実際に実行する動作」の間に信頼境界のズレがある点でGitLostと同系統の事例だ。より一般的なプロンプトインジェクションの分類と防御策はプロンプトインジェクションとは？攻撃手口・実例・防御策をLLM開発者向けに徹底解説｜OWASP LLM01にまとめている。
| 事例 | 対象 | 攻撃経路 | 到達点 |
|---|---|---|---|
| GitLost | GitHub Agentic Workflows（gh-aw） | 公開Issue本文への指示混入 | プライベートリポジトリ内容の公開漏洩 |
| GhostApproval・SymJack | Claude Code / Cursor 等6種のAIコーディング支援 | 悪意あるリポジトリのsymlink | 承認プロンプトを偽装しての書き込みRCE |
| プロンプトインジェクション全般（OWASP LLM01） | LLMアプリ全般 | 外部コンテンツへの指示混入 | 権限内での意図しない動作 |
3事例に共通するのは、「AIエージェントに与えた権限」と「エージェントが実際にどの入力をどこまで信用して実行するか」の間にギャップがあることだ。GitLostの場合はそのギャップが「Issue本文＝指示」という前提に、GhostApproval・SymJackの場合は「承認ダイアログの表示＝実際の書き込み先」という前提に、それぞれ現れていた。AIエージェントへの権限付与が広がるほど、この種のtrust boundaryの検証がセキュリティレビューの中心課題になっていく。
まとめ
GitHub Agentic Workflows（gh-aw）は、GitHubが2026年2月にTechnical Previewとして公開したAIエージェント自動化基盤で、Markdown＋YAMLで書いたワークフローをGitHub Actionsへコンパイルする。その公開初年度のうちに、Noma Securityが「GitLost」というプロンプトインジェクションを実演し、認証情報もコード実行も不要で、公開Issueへの一文だけでプライベートリポジトリの内容を公開漏洩させられることを示した。CVE番号は付与されておらず、修正の完了日も記事執筆時点で確認できていない。gh-awを導入している組織は、本文の自システム確認コマンドでissueトリガー・cross-repo権限・safe-outputs設定の3点をまず洗い出すことをすすめる。AIエージェントに権限を与える設計全般に共通する話として、プロンプトインジェクションとは？攻撃手口・実例・防御策をLLM開発者向けに徹底解説｜OWASP LLM01とGhostApproval・SymJack解説｜AIコーディング支援6種のsymlink承認ハイジャックも併せて参照してほしい。
参照ソース
・GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos（Noma Security公式ブログ） — 攻撃手法・責任開示の一次情報
・github/gh-aw（公式リポジトリ・README） — 設計・現行の権限モデルの一次情報
・GitHub Agentic Workflows are now in technical preview（GitHub公式Changelog） — 機能公開時期の一次情報
・Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data（The Hacker News） — 第三者メディアの技術要約
