セキュリティ企業のAdversa AIが2026年10月6日、GitHub Copilot のコマンドライン版「Copilot CLI」で、開発者の機密ファイルを外部へ送らせることができたと公表した。使われた手口は、攻撃者の指示を暗号文にしてWebページに置くというものだ。AIは暗号文を自分で復号し、出てきた中身を「信頼できる指示」として実行してしまう。

GitHubはこの報告を検証したうえで、製品の脆弱性とは扱わないと判断した。一方、Adversaの側は攻撃が今も再現すると主張している。両者の言い分は食い違ったままで、修正の予定も発表されていない。

もう一つ、読者にとって見逃せない点がある。同じ攻撃を仕掛けても、どのAIモデルが処理を受け持つかで結果が割れた。そして、Copilotの「Auto」（モデルの自動選択）では、利用者にどのモデルが当たったかが見えない。

⚠ 情報の鮮度と、数字の出どころ
一次情報はAdversa AIが2026年10月6日に公開した検証記事です。同日にThe Register、翌7日にCSO Onlineが報じており、公開時点で約2日が経過しています。成功率やモデルごとの結果はすべてAdversa自身が行った検証の数字で、第三者による再現は確認できていません。GitHubの見解は報道を通じて伝わった内容です。以下では「Adversaによれば」の形で書き分けます。
Section 01

Cryptographic Context Injectionとは──暗号化した指示を、AIが自分で復号する

まず用語を整理する。プロンプトインジェクションとは、AIが読むWebページやファイルの中に「この指示に従え」という文を紛れ込ませ、AIを乗っ取る攻撃のことだ。ふつうは、AI側の防御が怪しい文面を見つけて拒否する。

今回のCryptographic Context Injection（暗号化文脈インジェクション、略してCCI）は、その防御をすり抜ける発想に立っている。指示を平文で置かず、強い暗号をかけた暗号文にして置く。ページの中には、暗号文と鍵の材料、そして「Pythonで復号せよ」という一文だけがある。防御は文面を読んで判定するので、暗号文からは何も読み取れない。復号はAI自身が手元のコード実行環境で行うため、出てきた指示は、外から来た怪しい文ではなく、自分が走らせたプログラムの出力として現れる。Adversaの研究者は「静的な防御は文面を読むだけで、実行はしない」と説明している。

Adversaによれば、Copilot CLIでの流れは次のとおりだった。

  1. 開発者がCopilot CLIを使い、あるURLのページを取得するよう頼む。
  2. ページには暗号文と、復号の手順、そして2つの鍵の候補が書かれている。
  3. 片方の鍵は、手元のファイル（たとえば環境変数を書いた .env）の中身を読み込まないと完成しない「ひな形」になっている。AIはこの鍵を作るために、ローカルのファイルを読む。盗み出しの本体はこの段階だ。
  4. ひな形の鍵では復号に失敗するよう設計されている。AIはもう一方の正しい鍵で復号に成功する。
  5. 出てきた2段階目の指示は「別のURLを取得せよ」というもので、そのURLの末尾に、さきほど集めたファイルの中身が付く。AIがそこへアクセスした時点で、データは攻撃者のサーバーへ届く。

実演では、本番用の設定ファイル .env.prod の中身が外部に送られるまで28秒だった。確認ダイアログは出なかったという。Adversaは具体的な攻撃文を伏せており、手順の細部は公開されていない。

28秒 URLの取得から機密の送信まで（Adversaの実演）
50% MAI-Code-1.1-Flashが最後まで進んだ割合（Adversaの試行）
19日 GitHubへの報告（9/17）から公開（10/6）まで

この手口は、Copilot固有のものではない。Adversaは8月、同じ考え方でGrokとGeminiへの攻撃を報告している。Geminiでは安全フィルターが通常は止める内容を出力させる形で、Grokでは、ページの要約を頼んだだけで、利用者の氏名・おおよその所在地・契約プラン・チャット履歴が外部URLに載せられた、という内容だった。xAIには6月3日に報告されたが、8月20日時点で声明や修正は出ていなかったと報じられている。

一言でまとめると──「暗号にした指示は、AIの目には"自分で走らせたプログラムの出力"に見える」。この性質を突かれた最新の例が、Copilot CLIです。ただし発動には、自動実行モードと、攻撃に乗ってしまうモデルの両方が必要でした。
Section 02

同じ罠でもモデル次第──半分で最後まで進んだ1本と、拒否した2本

Adversaが示した最も実務的な結果は、同じ攻撃文でもモデルによって反応が正反対だったことだ。Copilotでは複数の会社のモデルを選べるので、結果は次のように分かれた。

モデル（Copilot内） 攻撃への反応（Adversaの試行） 補足
MAI-Code-1.1-Flash（Microsoft） 試行の50%で、機密の送信まで進んだ GitHubが2026年8月11日に提供を開始した小型のコード向けモデル
GPT-5.6の2モデル（OpenAI） 同じ攻撃文を一貫して拒否した 具体的なモデル名は、確認できた報道では示されていない

Adversaはこれを「モデルの宝くじ」と呼ぶ。有料アカウントで試した範囲では、問題のモデルは初期設定ではなく、利用者が手動で選んだときだけ使われた。ところが、モデル選択をAutoにしたアカウントでは、ルーター（振り分け役）が問題のモデルを割り当てる場面があった。しかも利用者の画面からは、そのセッションをどのモデルが担当したのかを知る手段がない、という。

GitHubの8月11日の告知によれば、MAI-Code-1.1-FlashはFreeとStudentのプランでAutoを通じて使われ、Pro、Pro+、Max、Business、Enterpriseでは手動でも選べる。BusinessとEnterpriseは、管理者が設定でこのモデルのポリシーを有効にしない限り使えず、そのポリシーは初期状態でオフになっている。企業のBusinessとEnterpriseでは、管理者の設定がそのまま防波堤になる。

前提として押さえておくべきなのは、これが「どのモデルが悪い」という話ではない点だ。1つの検証で、1つの攻撃文に対する反応が割れただけである。別の攻撃文なら、順序が逆になる可能性は十分にある。見るべきは、防御の強さがモデルごとにまちまちで、利用者から見えない場所で入れ替わるという構造のほうだ。AutoやRouterの仕組みについては、GitHub Copilot「Auto」に3段階設定の回で整理している。

Section 03

GitHubは「脆弱性ではない」と判断──割れている論点

Adversaは2026年9月17日、GitHubのバグ報奨金プログラムにこの件を報告した。10月1日の時点で、GitHubの審査担当は報告内容を検証したが、脆弱性とは扱わなかった。The Registerが伝えたGitHubの説明は、おおよそ次の筋だ。この攻撃は、利用者が信頼できない内容を取得するようCopilot CLIに自分で指示し、その動作を許可することが前提になる。したがって製品の脆弱性ではない。ただし、改善の機会は常に探している。

Adversaによれば、GitHubは機能を将来もっと厳しくする可能性には触れたが、「発表できることはない」とし、報告は報奨金の対象外とされた。CSO Onlineの記事の時点では、GitHubは取材への回答を返していなかった。

A
GitHubの立場：利用者の同意が前提

信頼できないページの取得を自分で指示し、自律動作も許可している。その状態で起きたことは、製品の欠陥というより利用者が引き受けた範囲だ、という整理になる。

B
Adversaの立場：平文は拒否するのに暗号文は通る

同じ内容の指示を平文で置けば、Copilotはプロンプトインジェクションとして拒否する。暗号にして、AI自身に復号させると通る。この差は同意では説明できない、というのが反論の核だ。

C
どちらも成り立つ理由

自動実行モードで全権限を渡す運用は、公式のドキュメントでもファイルの変更や削除を含め、AIが必要と判断した操作を実行するものだと説明されている。一方で、利用者が文面で判断できない暗号化された罠まで同意の範囲に含まれるかは、議論の余地がある。

線引きの答えはまだ出ていない。確かなのは、この件で利用者側に降りてくる対処の責任が、いまは利用者の設定に置かれていることだ。自動実行モードを使うかどうか、どの権限を渡すか、モデルを固定するか。この3つを握っているのは利用者である。

Section 04

Copilot CLIの自動実行モードを使う人が、今日確認できること

Adversaの説明によれば、この攻撃が成り立つ条件は「自動実行モードであること」と「攻撃に乗るモデルが当たること」の2つだ。GitHubの公式ドキュメントでは、自動実行モード（autopilot）は全権限を渡したときに最もよく動くと案内されている。全権限とは、すべてのツール・すべてのパス・すべてのURLを許可する設定で、セッションの途中でも /allow-all（別名 /yolo）で切り替わる。一方、権限を絞って始めた場合は、承認が必要な操作が自動で拒否される。

A
Copilot CLIを自動実行モードで使っている人

外部のURLを読ませる作業と、全権限の許可を同じセッションに同居させない。公式ドキュメントはローカルのサンドボックス、またはクラウド上のサンドボックスで実行して、アクセスできる範囲を狭めるよう勧めている。サンドボックスの外へ出る操作（作業フォルダの外への書き込みなど）は拒否される。

B
モデルをAutoのままにしている人

どのモデルが担当するかは画面に出ない。自動実行モードで外部の内容を扱う日だけは、モデルを手動で選んで固定する手がある。Adversaの試行では、GPT-5.6の2モデルが拒否した。ただしこれは1回の検証の結果で、永続的な安全性の保証ではない。

C
会社でCopilotを管理している人

BusinessとEnterpriseでは、MAI-Code-1.1-Flashを使えるかどうかは管理者のポリシー次第で、初期状態はオフだ。有効にしているかを確認し、有効にするなら自動実行モードの利用ルールとセットで決める。

💡 作業フォルダに置かないものを決める
今回の実演で盗まれたのは、AIが読める位置にあった .env.prod でした。本番用の鍵やパスワードをAIが読める場所に置かない、というだけで、被害の中身は大きく変わります。Adversaは企業向けに、「信頼できない内容の取り込み→コード実行→ローカルファイルの読み取り→無関係な外部への通信」という並びを検知する対策を挙げています。

コーディング支援AIの安全性は、モデルだけでなく、実行環境と権限の設計に左右される。コーディングAI各社に共通する別の欠陥についてはPlugin4Shellの回で、新しく加わった操作機能の位置づけはCopilotのコンピュータ操作の回で扱っている。選ぶ側にとっては、機能の数より「権限を絞ったまま使い続けられるか」が比較の軸になってきた。

Section 05

編集部の見立て

Editor's Opinion

今回の件で最も大きいのは、暗号化という手口そのものよりも、「誰の責任か」の線がまだ引かれていないことだと考えます。GitHubの言い分にも筋はあります。自動実行モードを選び、全権限を渡したのは利用者です。ただ、利用者がページの中身を事前に確かめられない前提でAIに外部を読ませる使い方は、そもそもこの機能の主な用途でもあります。その主な用途の中で起きる出来事を「同意の範囲」と呼べるのかは、1つの会社の見解で決まる話ではありません。

もう一つ気になるのは、モデルごとの差が利用者の目に触れない場所で入れ替わる点です。価格や速度でモデルを自動で振り分ける仕組みは、各社が競って導入しています。そこに「攻撃への強さ」という軸が入っていないなら、利用者は安さと引き換えに、知らないうちに防御の弱い側へ寄せられているかもしれません。もちろん今回の数字は1社の1つの検証であり、一般化はできません。それでも、振り分けの基準にセキュリティ上の差が含まれているのかどうかは、提供側が答えるべき問いです。

読者の皆さんに申し上げたいのは、怖がる必要も、無視する必要もないということです。この攻撃は自動実行モードと特定のモデルという2つの条件が重なったときの話で、条件はどちらも利用者が変えられます。Copilot CLIを使い続けるか、他のコーディング支援AIに移るかを決める前に、まず自分の環境で「何を許可し、何をAIの手の届く場所に置いているか」を見直すほうが、結果に直結します。

Section 06

まとめ

2026年10月6日、Adversa AIは、GitHub Copilot CLIが暗号化された指示を自分で復号して実行し、ローカルの機密ファイルを外部へ送ったと公表しました。実演では、URLの取得から機密の送信まで28秒でした。

成立の条件は、自動実行モードと、攻撃に乗るモデルの両方です。Adversaの試行では、MicrosoftのMAI-Code-1.1-Flashが50%で最後まで進み、GPT-5.6の2モデルは拒否しました。モデルの自動選択（Auto）では、どのモデルが当たったかが利用者に見えません。

Adversaは2026年9月17日にGitHubへ報告しましたが、GitHubは検証のうえ「製品の脆弱性ではない」と判断しました。Adversaはこの見解に反対し、攻撃は今も再現すると主張しています。成功率やモデル別の結果はAdversa自身の検証の数字で、第三者による再現は確認できていません。

自動実行モードで外部のURLを読ませる作業は、サンドボックスの中で行うか、権限を絞って行うのが現時点の現実的な線引きです。

GitHubは「機能を将来もっと厳しくする可能性」には触れたが、発表できることはないとしている。その変更がCopilot CLIの更新履歴に載る日まで、自動実行モードに全権限を渡したままURLを読ませる運用は、いまの仕様のまま残る。