最後の一歩はプロンプトだった

7 月 25 日の UTC 午前 6 時、Hacktron の研究者三人は OpenAI の公開コミュニティ フォーラム上でコード実行を得ていた。午後の早い時刻には、番号 1186742 のプルリク エストが非公開モノレポ openai/openai に置かれていた。そこに置くためのコードを、 彼らは一行も書いていない。エージェントに頼んだら、エージェントが提出したのだ。

Hacktron は 9 月 18 日にこの連鎖を公開した。 一つひとつの環をたどって読む価値がある。どの環もありふれているからだ。研究者は Harsh Jaiswal、Mohan Pedhapati、Rahul Maini の三名。 The Hacker News は翌日これを報じた。

一枚の画像、一度の変換、そして一つのパーサ

入口はフォーラムの画像アップロードだった。Discourse はアップロードされた画像を FastImage という Ruby のライブラリで確認する。これはファイルのヘッダを寸法と形式が 分かる程度まで読む。FastImage は HEIF を理解しない。iPhone の写真が入ってくる コンテナだ。そこで Discourse はそうしたファイルを変換のために ImageMagick の magick コマンドに渡していた。ImageMagick は libheif で HEIC をデコードする。 C で書かれたライブラリである。

入口の条件はこれで全部だ。安全な検査器が認識しなかった形式が変換器へ回され、その 変換器が、長さフィールドの細工がそのままメモリ安全性の問題になる言語で書かれた パーサを呼んだ。Hacktron は HEIC デコードにヒープバッファオーバーフローを見つけ、 そこから境界外の読み取りと書き込みのプリミティブを得た。

バグそのものより書類仕事のほうが悪い。上流は前年にそのオーバーフローを修正して いたが、そのコミットを一度もセキュリティ修正と表示しなかった。CVE も、アドバイザリ も、依存関係スキャナが読める変更履歴の一行も付かなかった。だから Debian は バックポートせず、Discourse の Docker イメージは Debian 12 上の libheif 1.19.7 を バグを抱えたまま出荷した。そのバージョンを指摘する根拠を持つスキャナは、世界中に 一つもなかった。Debian は後に DSA-6417-1 を出し、この問題には今 CVE-2026-32882 が 付いている。誰かが実際に突いたあとで採番された番号だ。

誰も届け出ていないバグは、スキャンできない。前もって決められるのは、パーサが倒れる とき、そのパーサが何の中に立っているかだけである。

エクスプロイトには一晩かかった

Hacktron がアップロード経路を見始めたのは 7 月 23 日。24 日には Claude Opus 4.8 で オーバーフローに取りかかったが、彼らの記述によれば、アドレス空間配置のランダム化に 対して動くものを出すのに複数のセッションを費やして苦戦した。プロセスのメモリ配置を かき混ぜ、どこに何があるかを攻撃者に予測させない防御である。ヒープオーバーフローを ASLR の下で確実な実行に変えるのが難所であり、この種の研究が一週間止まるのもそこだ。

Anthropic はその晩に Opus 5 を出した。Hacktron は新しいセッションを開き、三時間後 には手元の Mac に対して動く ARM64 のエクスプロイトを手にしていた。彼らはモデルに、 Discourse が動いている x86-64 と jemalloc の構成へ移植させ、翌朝六時には画像 アップロード経由のローカルコード実行を確認した。続いて自分たちの Discourse Cloud インスタンスに対し、Claude を自律ループで走らせた。十時にはそちらでもコード実行を 得て、証拠として /etc/hosts を読んだ。

それが何を意味するかについて、彼らは慎重である。この留保はどの読み方にも添えられる べきだ。

これは完全に自律的なハッキングではなかった。セッションを方向づけ、結果を検証し、 開示を進めるうえで、人間の専門知識は依然として必要だった。

もっともだ。熟練した研究者三人が道具の狙いを定めたのであり、その腕前が一晩で変わっ たわけではない。バグも変わっていない。二つのセッションのあいだで新しかった変数は モデルだけで、それが、幾度も失敗していたエクスプロイト作業を三時間に縮めた。これが 属していた一連の活動で Hacktron が費やしたのは、トークン代 3,000 ドル未満と人間の 数時間である。

この数字こそ計画の入力値だ。CVE が一度も付かず、ファイル変換器の推移的依存に座って いたバグが、いまやノート PC 一台分の値段で確実なプリミティブに変わる。アドバイザリ を待つのは願望であり、変更履歴を速く読んでこの時計を追い抜ける者はいない。

最後の一歩はプロンプトだった

フォーラム上のコード実行は、OpenAI が気にかけるものを Hacktron に何も与えなかった。 それをもたらしたのは第二の問題である。OpenAI はシングルサインオンを、フォーラムの セッションが奪われると、そのフォーラムを使っていた従業員の ChatGPT と Codex の アカウントが無操作のまま乗っ取られる配線にしていた。Hacktron の言葉を借りれば、 フォーラムの侵害を ChatGPT と Codex へのアクセスに変えたのが、この SSO の問題だ。

ある従業員の Codex は会社の GitHub 組織につながっていたので、研究者は当然のことを した。そのアカウントに、社内モノレポへプルリクエストを開いてほしいというプロンプト を送ったのである。そして PR 1186742 が openai/openai に現れた。彼らはそこで手を 止め、ソースを読まずに報告を出した。

この一歩をもう一度読んでほしい。有効なセッションを握っている者が、エージェントに ありふれたことを頼み、エージェントはすでに持っていた書き込み権限でそれを行った。 注入もジェイルブレイクも、細工された入力もない。誰かが築いた制御はすべて、その セッションの後ろに座っていた。ログイン、組織のメンバーシップ、リポジトリの権限。 攻撃者がそのセッションを握った時点で、そのすべてを握っていた。

コーディングエージェントとは、会話に紐づいた、リポジトリへの書き込み権限の常設的な 付与である。会話に手が届いた者が、その付与を受け継ぐ。ブラウザの Codex でもそうで あり、ノート PC 上の Claude Code、Codex CLI、Gemini CLI でも同じだ。そこでは エージェントが ~/.git-credentials に本物の ghp_ トークンを、環境に本物の GH_TOKEN を携えている。ノート PC では入口が増える。リポジトリに仕込まれた ファイル、issue のコメント、パッケージの postinstall スクリプト、乗っ取られた ターミナル。

OpenAI はおよそ十四時間でフォーラムを修正した。報告はその朝に入り、OpenAI は同じ日 の UTC 22:49 に修正を確認した。Discourse は週末のうちに自前の修正を出し、7 月 28 日 にアドバイザリ GHSA-vhm9-85gw-x335 を公開した。報奨金は 6,500 ドルだった。この形の うち、あなた自身の机の上に載っている部分がエージェントである。

書き込みはどこで決まるか

Bromure Agentic Coding は「誰が push してよいか」の答えを、エージェントの セッションの外、あなたの Mac に置く。攻撃者が手を伸ばそうとしている先が、まさに そのセッションだからだ。そこでは二つのことが起きる。

第一に、エージェントの環境には受け継ぐべきトークンが存在しない。ワークスペースの VM が受け取るのはダミーである。ghp_ に 36 文字を足した形で、gh も git も 文句を言わずに受け取る。あなたの本物のトークンから HKDF-SHA256 とインストールごとの ソルトで導かれるので、セッションをまたいでも回転しているようには見えない。本物の トークンはホスト上に暗号化されて置かれ、ホストのプロキシが、要求が VM を出たあとの 通信路上でそれを差し替える。差し替えるのは、宛先がそのトークンの発行先ホストに 一致するときだけだ。マニュアルはこう述べている。VM の内部のいかなるファイル、環境 変数、プロセスも、本物の API キー、OAuth トークン、AWS のシークレット、SSH の秘密鍵 を含むことはない。そのダミーを本来の場所でないところへ持ち出せば、プロキシは一 バイトも転送せずに HTTP 451 を返し、VM を一時停止し、Security Timeline に赤い行を 書き込む。

第二が、この話が求めているほうだ。git フォージの資格情報にはそれぞれ書き込み ポリシーが付き、Guardrails ペインでワークスペースごとに設定する。新しいワーク スペースの既定は書き込み前に確認である。読み取りは何も言われずに通る。 git push は通信路上に git-receive-pack として現れ、書き込みに数えられる。プル リクエスト API への POST も同じだ。それが届くと、プロキシは要求を保留し、あなたの Mac にダイアログを開く。そこに載るのは要約ではなく、そのままの操作、すなわち メソッドとパスである。選べるのは15 分間許可、一度だけ許可、このセッション の残りを許可、許可しない。拒否はエージェントに、ありふれた API エラーとして 届く。報告できるエラーであり、応答なしの接続ではない。

このペイン自身が書いている実行場所の説明が、肝心の一文だ。プロキシで強制されるので、 VM 内で侵害されたエージェントは回避できない。

エージェントを動かしているのが誰であれ——あなたでも、フィクスチャファイルに埋め られたプロンプト注入でも、あなたから奪ったセッションを握る者でも——書き込みは同じ プロキシを通って出ていき、同じように分類される。あなたの Mac に出るダイアログが 認可であり、あなたのセッションを握った攻撃者は、あなたの Mac を握ってはいない。

パーサの問題もあなたの机にやってくる

この連鎖のもう半分もまた一般化するのだが、そこまで織り込んでいる人は少ない。

コーディングエージェントは、自分が書いていないファイルを一日じゅう読んでいる。 リポジトリに付いてきたテストフィクスチャ、バグ報告に添えられた画像、あなたが会話に 貼り付けたスクリーンショット、仕様の PDF、リリースページから取った tarball、 フォント、フロントエンドが再生するはずの動画。それらを扱うということは、magick、 ffmpeg、pdftotext、unzip を呼び出すか、Python に結び付けられた画像ライブラリ を呼び出すということだ。そのどれもが、他人の選んだバイト列を食べる C か C++ の パーサである。フォーラムのアップロードを libheif まで届かせたのと同じ条件だ。 エージェントはあなたより頻繁にこの条件に出会う。何かを開く前に、一度もためらわない からである。

ここに検知の答えはない。libheif のバグは、肝心なその時点で CVE を持っていなかった。 どのスキャナも、許可リストも、バージョン固定も、一言も言わなかっただろう。選べるの は被害の範囲だけであり、それが全部だ。

Bromure のワークスペースでは、そのデコーダは Apple の Virtualization.framework の 下の Ubuntu ゲストの中で動く。プロセスのサンドボックスではなくハイパーバイザーの 境界であり、Bromure が構造上、信頼しないものとして扱うゲストである。画像パーサの ヒープオーバーフローが攻撃者に買い与えるのは、Linux VM のシェルだ。その資格情報は ダミーであり、インターネットへの経路はホスト上の順序付けられたルールセットである。 仮想スイッチは、宛先 IP と DNS から拾ったホスト名で、TCP と UDP の双方に対してその ルールセットを照合し、プロキシは TLS のサーバ名と HTTP メソッドでもう一度照合する。 どのルールにも当たらない通信を拒否にしておけば、そのシェルに残るのは許可リスト だけになる。スイッチは :80 と :443 をプロキシ自身へ迂回させるので、シェルが 解除できるプロキシ変数は存在しない。ルールの変更は再起動なしで実行中のセッションに 届き、判定はすべて Security Timeline の Firewall 行として残る。

Hacktron の記事はよい研究であり、どれだけの部分をいまだ人間が操縦しなければならな かったかについて正直だ。来年もなお真であり続けるのは、その結末の部分である。この 連鎖のすべての防御は一つの身元の後ろに座っており、その身元を帯びたセッションが人手 を移った瞬間、どの防御ももはや何の意見も持たなかった。誰かがエージェントに頼み、 エージェントは従った。

あなたのエージェントが push できるなら、push する許可がどこに住んでいるのかを問い、 エージェントの持ち物をすべて奪った攻撃者がその許可まで奪うのかを問うてほしい。 ノート PC の上なら、奪う。その一つの判断をエージェントの走るマシンの外へ動かせば、 この連鎖の最後の一歩には、止まる場所ができる。