セキュリティ企業Glowは9月29日、AIコーディングエージェントによって社内向けの画像がGitHub上で公開されていたとする調査「PixelLeak」を発表した。同社によると、300を超える組織に関係する1万3000点超の画像が見つかり、顧客の請求記録や未公開製品の画面なども含まれていた。

きっかけは、「修正前後の画面をレビュー担当者に見せる」という、開発現場では一般的な依頼だった。エージェントはコマンドラインから画像を添付する手段を見つけられず、別の公開リポジトリを画像置き場として利用したという。

ただし、GitHub CLIには9月1日から画像や動画を直接添付できる公式機能が追加されている。問題を防ぐには、現在利用できる安全な共有手段だけでなく、エージェントが過去に覚えた公開手順やスキルが残っていないかも確認する必要がある。

AD

レビュー用の画像はどこへ流れたのか

Glowが報告した規模は、1万3000点超の社内画像、300を超える組織、900超のコードリポジトリに及ぶ。画像の枚数、関係する組織の数、影響したリポジトリの数は、それぞれ別の集計である。

公表された事例には、社内の請求画面を修正した際に写り込んだ顧客記録や、資金管理・決済操作の画面などがある。静止画だけでなく、操作の流れを記録した画面録画も見つかったという。

開発者がUIの変更結果をスクリーンショットで確認すること自体は珍しくない。コードだけでは、ボタンの位置やレイアウトの崩れが正しく直ったか判断しにくいためだ。

通常は、変更内容の取り込みを依頼するプルリクエスト（PR）に画像を添付し、チーム内で確認する。非公開リポジトリで開発している場合、レビュー内容も原則として関係者だけが閲覧できる。

ところがGlowの説明によると、一部のAIエージェントはコマンドラインから画像を添付できないと判断し、画像を別の公開リポジトリへアップロードして、そのURLをPRに貼り付けていた。

元のコードが非公開のままでも、画像の保存先が公開されていれば、画像自体は外部から取得できる。顧客情報を表示した画面をスクリーンショットに使っていれば、修正結果だけでなく、その画面に表示されたデータまで公開される。

ここで報告されているのは、依頼を完了するためにAIエージェントが選んだ共有方法である。攻撃者が悪意ある指示を送り込んだといった経緯は、Glowの説明には登場しない。

一方で、個々の公開操作について開発者がどこまで確認・承認していたのか、公開された画像が第三者によって実際にどの程度取得されたのかまでは、公表資料から確認できない。

1万3000点超という数字はGlowが確認した公開画像の規模であり、悪用された画像や実際に被害が発生した件数を意味するものではない。

非公開PRでも、画像の保存先が公開なら誰でも見られる

Glowは、影響を受けた組織のおよそ3分の1で、画像共有ツール「gitshot」を利用する開発者が確認されたと報告している。

これは「漏出した画像の3分の1がgitshotによるもの」という意味ではなく、影響を受けた組織のうち約3分の1で利用が確認されたという数字である。

gitshotのREADMEには、既定のGitHub経由で画像が公開される仕組みが明記されている。

別の保存先を設定しておらず、GitHub CLIで認証済みの場合、初回利用時にユーザー個人のGitHubアカウントへ専用の公開リポジトリを作成し、画像をGitHub Releaseの添付ファイルとしてアップロードする。

これは画像を通常のソースファイルとしてリポジトリへ保存する方式とは異なる。そのため、公開リポジトリのファイル一覧だけを確認しても、アップロードされた画像をすべて把握できるとは限らない。

READMEには、既定の保存方法を使って認証情報や社内ダッシュボード、非公開データなどをアップロードしないよう警告も記載されている。

画像を共有する方法 画像の保存先 閲覧条件
GitHubの非公開リポジトリで使う公式添付 対象のIssueやPRなどに関連付けられた添付画像・動画 非公開リポジトリへ2023年5月以降に追加された添付は、原則としてログインとアクセス権が必要
gitshotの既定のGitHub経路 個人アカウントの公開リポジトリにあるGitHub Releaseの添付ファイル URLを知っていれば取得できる。非公開PRへリンクしても画像自体は公開されたまま

比較したのは、GitHubが非公開添付の認証を説明した発表と、gitshotの既定の保存方法である。

gitshotはCloudinaryやImgBBなど別の保存先も利用できるため、すべての設定で同じ公開方法になるわけではない。

重要なのは、PR本文を閲覧できる人と、画像そのものを取得できる人が必ずしも同じではないという点だ。

非公開PRに画像のURLを貼ったとしても、その画像自体が公開リポジトリに保存されていれば、PRのアクセス制限が画像に引き継がれるわけではない。

「GitHubに保存した」「非公開PRに貼った」というだけでは、画像の公開範囲を判断できない。

AD

GitHub CLIには9月1日から公式の添付機能がある

GitHub CLIでは2026年9月1日、画像や動画を直接添付する機能が一般提供された。

Glowが影響組織への通知を開始した9月9日、PixelLeakを公表した9月29日より前に、GitHub.comではコマンドラインから画像を直接添付できる公式の方法が利用できるようになっていた。

GitHubはCLI 2.99.0の発表で、画像や動画をアップロードできる--attachオプションを追加した。

PRやIssueの作成・編集、コメントへの投稿などで利用でき、ローカルにある画像をGitHubへ直接アップロードできる。

2026年9月の日付 確認できる出来事 発表主体
9月1日 GitHub CLI 2.99.0で画像・動画の直接添付機能を一般提供 GitHub
9月9日 特定した組織への通知を開始 Glow
9月29日 PixelLeakの調査結果を公表 Glow

このため、Glowの報告に登場する「CLIから画像を添付できなかった」という制約を、現在のGitHub.comにもそのまま当てはめるのは適切ではない。

ただし、PixelLeakで確認された環境がどのバージョンのGitHub CLIを使っていたのか、9月1日以降も同じ方法による公開が続いていたのかまでは、公表資料から分からない。

公式機能が提供された日付だけを見て、問題がその時点で解消したと考えることもできない。

また、--attachには利用条件がある。画像をアップロードするには対象リポジトリへの書き込み権限が必要で、今回のリリースではGitHub Enterprise Serverは対応対象に含まれていない。

GitHub.comで最新のCLIを利用できる環境と、自社運用のGitHub Enterprise Serverを使う環境では、利用できる手段が異なる。

ただし、公式の添付機能を利用できないことが、公開リポジトリへ社内画像をアップロードしてよい理由になるわけではない。

一度覚えた危険な手順を、AIエージェントが繰り返す

Glowが紹介したあるソフトウェア企業の事例では、7月初旬からスクリーンショットの公開アップロードが始まり、1週間以内に十数のAIエージェントがその方法を「スキル」として保存していたという。

その後、1000点を超える画像や画面録画に加え、まだ公開されていない機能の説明まで投稿された。

ここでいうスキルとは、AIエージェントが作業時に参照する手順やルールである。

一度「この方法ならレビュー担当者に画像を見せられる」と学習した手順が残れば、その共有方法が安全かどうかを改めて確認せず、次の作業でも繰り返す可能性がある。

これはGlowが紹介した匿名の1社についての事例であり、影響した300超の組織すべてで同じことが起きていたわけではない。

Glowは別途、Minesweeperの画面変更を依頼する実験も行い、AIエージェントがレビュー担当者に画像を表示することを優先して、公開リポジトリを作成する様子を示している。

この実験を実際の被害企業すべての行動と同一視することはできない。それでも、一度作られた危険な共有手順がエージェントの設定やスキルとして残れば、GitHub側に新しい安全な機能が追加された後も使われ続ける可能性がある。

AD

ソースコードだけを調べても、画像の漏出は見つからない

監査する範囲も、画像が保存される場所に合わせて広げる必要がある。

Glowは、企業のGitHub Organizationだけでなく、社員や退職者の個人アカウント、GitHub Releaseの添付ファイル、Gistなども確認するよう勧めている。

特に今回の事例では、93%で画像が企業のOrganizationではなく、従業員個人のアカウント側に保存されていたという。

また、一般的なコードスキャンは文字列を対象とするため、スクリーンショット内に表示された顧客名や口座情報、社内画面などをそのまま検出できるとは限らない。

「どこへ公開されたか」を調べる作業と、「画像の中に何が写っているか」を確認する作業は分けて考える必要がある。

Glowが予防策として挙げているのは、AIエージェントが参照するスキルやルールの点検に加え、公開リポジトリの作成、個人アカウントへの送信、Gistへの投稿などを実行前に止める、または人間の承認を求める仕組みである。

GitHub CLIを最新版へ更新し、公式の添付機能を使えるようにすることも対策の一つになる。

ただし、それだけではすでに公開された画像は削除されず、エージェントに保存された古いアップロード手順も自動的には書き換わらない。

企業が確認すべきなのは、「レビュー画面に画像が表示されたか」だけではない。

その画像がどのアカウントの、どの保存先へアップロードされ、誰がアクセスできる状態になったのかまで確認する必要がある。

AIエージェントによる画像共有を安全に利用するには、添付先のアクセス権と、エージェントが実際に使っている共有手順の両方を点検することが重要になる。