プログラミング

GitLostとは？GitHubの公開Issueから非公開情報が漏れる仕組みと対策

  • 登録：

2026年7月、GitHubの新機能「GitHub Agentic Workflows」に関連する深刻な脆弱性が公表されました。セキュリティ企業のNoma Security(Noma Labs)が発見し、「GitLost」と名付けたこの手口を使うと、公開リポジトリに投稿された何気ないIssue1件だけで、非公開リポジトリの中身をインターネット上に晒すことができてしまいます。

攻撃者に特別なスキルや認証情報は必要ありません。GitHubのAIエージェントが「読み込んだ文章」をそのまま指示として実行してしまう、間接プロンプトインジェクションと呼ばれる攻撃手法が悪用されています。本記事ではGitLostの実際の仕組みと、開発者・企業が今すぐ取るべき対策を、一次情報にもとづいて整理します。

この記事でわかること

  • GitLostという名称の脆弱性は実在し、Noma Securityが2026年7月6日に公表したものであること
  • GitHub Agentic Workflowsの仕組みと、悪用された「間接プロンプトインジェクション」の手口
  • ガードレールが「Additionally」という一言で突破された経緯
  • 過去に見つかった類似のAIエージェント脆弱性事例
  • 開発者・企業がすぐに実践できる具体的な対策

GitLostとは？結論を先に整理

GitLostは、AIセキュリティ企業のNoma Securityが2026年7月6日に自社ブログで公表した脆弱性です。同社の脆弱性研究者であるSasi Levi氏が発見し、GitHubに責任ある開示(レスポンシブル・ディスクロージャー)を行ったうえで、公開に踏み切っています。

対象となったのは、GitHubが2026年2月に技術プレビューとして公開した「GitHub Agentic Workflows」という機能です。The Hacker NewsやThe Register、Dark Reading、SiliconANGLEなど海外の主要セキュリティメディアも一斉にこの脆弱性を報じており、単なる憶測ではなく実際に確認・報告された事案であることが分かります。

結論から言うと、GitLostは「AIエージェントに広い権限を与えたまま、外部からの文章を無条件に信用させてしまう」という設計上の落とし穴を突いた攻撃です。攻撃者はコードを書く必要も、認証情報を盗む必要もなく、ただ公開リポジトリにIssueを1件投稿して待つだけで、組織内の非公開情報を公開コメントとして引き出せてしまいます。

GitHub Agentic Workflowsとは何か

GitHub Agentic Workflowsは、GitHub Actions(リポジトリのイベントに応じて自動処理を実行する仕組み)と、AIエージェントを組み合わせた新機能です。開発者はYAML形式の複雑な設定ファイルではなく、平易なMarkdownで「何をしてほしいか」を記述するだけで、それが自動的にYAML形式のActionsファイルへコンパイルされます。

このAIエージェントはGitHub Copilot、Anthropic社のClaude、Google Gemini、OpenAI Codexなど複数のモデルで動作するよう設計されています。エージェントはIssueやプルリクエストの内容を読み取り、必要なツールを呼び出し、自律的にコメントを投稿するところまでこなします。

ワークフローは初期設定では読み取り専用ですが、組織によっては業務効率化のために、複数リポジトリを横断して読み取れるアクセストークンをエージェントへ与えるケースがあります。この「組織横断の読み取り権限」こそが、GitLostが悪用した入口になりました。

GitLost攻撃の実際の流れ

Noma Labsが検証した脆弱なワークフローは、次のような設定になっていました。Issueが誰かに割り当てられた(issues.assignedイベント)タイミングで起動し、Issueのタイトルと本文を読み取り、add-commentツールでコメントを返信し、さらに組織内の公開・非公開を問わず他のリポジトリへの読み取りアクセス権を持つ、という構成です。

研究者はまず、公開リポジトリに「顧客との商談を終えたVP of Salesからの依頼」を装った、一見無害なIssueを投稿しました。その後、通常業務のなかでこのIssueが担当者にアサインされると、ワークフローが起動し、AIエージェントは公開リポジトリ(poc)と非公開リポジトリ(testlocal)の両方からREADME.mdの中身を取得しました。

最終的にエージェントは、取得した非公開情報を含む内容を、誰でも閲覧できる公開Issueへのコメントとしてそのまま投稿してしまいました。Noma LabsはこのPoC(概念実証)を実際のGitHubリポジトリ上で公開しており、ワークフロー実行ログとIssue自体も第三者が確認できる形で提示しています。

この一連の流れは、実際に海外のセキュリティメディアでも大きく取り上げられました。以下は、脆弱性の第一報を伝えたセキュリティニュースアカウントの投稿です。

「Additionally」の一言で崩れたガードレール

GitHubは、こうした情報漏洩を防ぐためのガードレール(安全装置)をあらかじめ用意していました。ところがNoma Labsが繰り返し検証したところ、悪意ある指示の前に「Additionally(加えて)」という一語を添えるだけで、モデルはその指示を拒否すべき危険な要求ではなく、正当な追加タスクとして処理してしまうことが判明しました。

Sasi Levi氏はThe Hacker Newsの取材に対し、「これまでのプロンプトインジェクションの多くは、エージェントに何を言わせるかを操作するものでした。GitLostは、エージェントが持つ権限を使って何をさせるかを操作する点が異なります」と説明しています。つまりGitLostは単なるチャットの誤答ではなく、CI/CD環境に組み込まれた権限を持つ「実行者」そのものを乗っ取られる点に本質的な怖さがあります。

なお、この脆弱性は海外の技術者コミュニティでも活発に議論されており、Hacker Newsのフォーラムでは280件を超えるコメントが寄せられ、「これはGitHub側の脆弱性なのか、それとも利用組織側の設定ミスなのか」という線引きを巡る議論が続いています。似たような「どこまでが不正で、どこからが設計・運用の問題か」という境界線の難しさは、国内でかつて話題になったコインハイブ(Coinhive)事件の議論とも通じるものがあります。

間接プロンプトインジェクションの仕組みをおさらい

GitLostの根本原因は、プロンプトインジェクションと呼ばれる攻撃分類のなかでも「間接」と呼ばれるタイプです。攻撃者がAIに直接話しかけるのではなく、AIが読み込む予定のコンテンツ(この場合はGitHubのIssue本文)に悪意ある指示を仕込んでおき、AI自身にその指示を実行させる点が特徴です。

この問題を理解するうえで役立つのが、開発者のSimon Willison氏が2025年6月に提唱した「Lethal Trifecta(危険な三要素)」という考え方です。これは、AIエージェントが(1)非公開データへのアクセス権、(2)信頼できない外部コンテンツへの接触、(3)外部への出力手段、という3つの性質を同時に備えたとき、モデルの安全対策の強さに関わらず情報漏洩が起こり得るという指摘です。

GitLostのケースに当てはめると、非公開リポジトリへの読み取り権限、公開Issueという信頼できない入力、そしてコメント投稿という出力手段の3つが、まさにこの危険な三要素をすべて満たしていたことになります。従来のセキュリティ対策は「コードの側」で信頼境界を強制する発想が中心でしたが、AIエージェントの世界では、その境界線の一部をモデルの振る舞いに委ねざるを得ないという構造的な弱点が浮き彫りになりました。

過去にも起きていた類似のAIエージェント脆弱性

GitLostは決して孤立した事件ではありません。The Hacker Newsは、GitHub関連のAIエージェントを狙った同種の脆弱性をここ数か月で複数報じています。代表的なものを整理すると、それぞれ狙われた製品や手口は異なるものの、根っこにある問題は共通していることが分かります。

  • Claude Code GitHub Actionの脆弱性(2026年6月報道):悪意あるIssue1件で、シークレット情報の漏洩とリポジトリの書き込み権限の乗っ取りにつながった
  • RoguePilot(Orca Security、2026年2月報道):GitHub Issueに隠されたプロンプトによって、GitHub Copilotが特権トークンを漏洩
  • MCP経由のGitHub脆弱性(Invariant Labs、2025年5月報告):公開Issueが、GitHubのMCPサーバーに接続されたエージェントを操り、非公開リポジトリの内容をプルリクエスト経由で流出させた。研究者はこれを「アーキテクチャ上の問題」と表現
  • Comment and Control(複数ベンダー横断の調査):Claude Code、Gemini CLI、GitHub Copilotのそれぞれのエージェントが、IssueやPRの文章を通じて自らのAPIキーを漏洩

これらの事例に共通するのは、いずれも「AIエージェントがどこまでの権限を持ち、どんな入力を信用してしまうか」という設計判断の甘さです。プロンプトインジェクションは、かつてWebアプリケーションを悩ませたSQLインジェクションと同じように、カテゴリ全体として繰り返し発生する脆弱性の類型になりつつあると指摘されています。

GitHubの標準的なセキュリティ機能と開発者が取るべき対策

GitHub自身もAgentic Workflowsのドキュメントのなかで、「AIエージェントはプロンプトインジェクション、悪意あるリポジトリコンテンツ、侵害されたツールによって操作される可能性がある」と明記しています。標準機能として、サンドボックス化、初期設定での読み取り専用トークン、入力のクリーニング、エージェントが投稿する前に内容をスキャンする脅威検知ステップなどが用意されています。

しかし今回のGitLostが示した通り、こうした防御は「最後の砦」であって「絶対の境界線」ではありません。Noma Securityは開発者やセキュリティ担当者に向けて、次のような対策を推奨しています。

  • ユーザーが自由に書き込める内容(Issue・コメント・PR本文など)を、AIエージェントへの信頼できる指示として扱わない
  • エージェントに与える権限は必要最小限にとどめる。特に組織横断の読み取り権限を持つエージェントは、攻撃者にとって価値の高い標的になりやすい
  • エージェントが公開の場に投稿できる内容そのものを制限する
  • ユーザー入力を、モデルへの指示コンテキストから物理的・論理的に分離(サニタイズ)する
  • 重要な出力は自動投稿せず、人の目によるレビューを経由させる

アクセストークンのスコープを「組織全体」ではなく「そのワークフローが本来担当する1リポジトリ」に絞り込むことも、Noma Securityが繰り返し強調しているポイントです。こうした地道な権限設計の見直しは、実は昔からある「うっかりミスを事前に防ぐ仕組み作り」と発想は同じです。個人の利用シーンでも、設定の甘さがトラブルにつながることは珍しくなく、たとえば当ブログで紹介したGmailの送信取り消し機能の設定方法のように、誤操作を前提とした備えを普段から用意しておく姿勢が役立ちます。

また、AIエージェントを安全に使いこなすには、開発者自身の基礎スキルも欠かせません。権限設計やAPIの扱い方といった基本を理解していないと、便利な自動化ほど気づかないうちにリスクを広げてしまいます。プログラミングの基礎から見直したい方は、当ブログのプログラマーに必要な5つの必須スキルもあわせて参考にしてみてください。

企業がAIコーディングツールを導入する際のリスク管理

GitLostのような事例が相次ぐ背景には、多くの企業がAIコーディングエージェントを急速に導入している事情があります。開発スピードを優先するあまり、権限設計やログ監視といった地味な作業が後回しになりがちな点は、多くのセキュリティ企業が共通して指摘する課題です。

導入企業に求められるのは、AIエージェントを「便利な自動化ツール」としてだけでなく、「独自の権限を持つ一人のアカウント」として扱う発想への転換です。人間の従業員に不要な権限を与えないのと同じように、エージェントにも役割に応じた最小権限を与え、その行動ログを継続的に監視する体制が必要になります。

興味深いのは、AIがどれだけ高度になっても、こうした「境界線の判断」は依然として人間の経験や文脈理解に頼らざるを得ない点です。AIには置き換えられない人間ならではの判断力の重要性は、コーディングの現場に限った話ではありません。当ブログで紹介したアフィリエイトで成果を出すライティングのコツでも触れているように、2026年のAI時代においてなお「人の体験や判断」が価値を持つ場面は、セキュリティ運用の現場にも共通しているといえるでしょう。

AIエージェントのセキュリティやプロンプトインジェクションの基礎をより体系的に学びたい場合は、書籍で全体像をつかんでおくのもおすすめです。

生成AIの安全性入門（Amazon）

GitHub Copilot 大全（Amazon）

また、GitやGitHubの基本操作から学び直したいという方は、体系的なカリキュラムで学べるプログラミングスクールを利用するのも一つの方法です。

【A8】デイトラ / ID:s00000025787001

GitLostは、GitHubに限らず、AIエージェントを業務に組み込むすべての企業・開発者にとって他人事ではない問題です。便利さの裏側にある「エージェントが何を信用し、どこまでの権限を持っているか」という視点を、今のうちから見直しておくことが、次の情報漏洩を防ぐ最も現実的な一歩になります。

参考リンク

このテーマの関連記事はこちら