セキュリティ企業Hacktronの研究者3人が2026年9月18日、7月に実施したOpenAIへの侵入テストの詳細を公開しました。OpenAIのコミュニティフォーラムに画像をアップロードするところから始まり、72時間以内に社員のChatGPT/Codexアカウントを乗っ取って、社内のモノレポにプルリクエストを作るところまで到達しています。報告から約14時間でOpenAIが修正しており、すでに塞がれた話です。それでも読む価値があるのは、人手では詰まっていた工程をAIが数時間で抜けた記録が、時刻付きで残っているからです。
9段構えの連鎖
経路は、画像デコーダ libheif、Debianのバックポート漏れ、ImageMagick、Discourseの画像アップロード、community.openai.com、OpenAIのSSO、ChatGPT/Codexアカウント、連携済みのGitHub、社内リポジトリ、と9段で説明されています。
起点は libheif 1.19.7(Debian 12の既定パッケージ)のヒープバッファオーバーフローです。修正自体は前年に上流で入っていましたが、CVEが振られなかったためにDebian側へバックポートされていませんでした。Discourseは、HEIC/HEIF形式をFastImageで扱えないぶんをImageMagickの magick コマンドに渡す作りになっており、結果として投稿された画像がそのまま libheif に届いていました。
そこから先が今回の要点です。フォーラムのアカウントを取られると、コミュニティ用のサインオントークンの権限範囲が広すぎたために、ChatGPTとCodexのアカウントまで到達できました。ある社員のCodexは業務のGitHubに接続されていたため、研究者はCodexに指示して openai/openai に無害なプルリクエスト1件を作らせ、そこで検証を止めています。コード自体は読んでいないと明記しています。OpenAIはその後「コミュニティのサインオントークンの権限を狭め、影響を受けたトークンとセッションを失効させた」と説明しています。
AIが縮めたのは「時間」
Hacktronによれば、Opus 4.8では複数のセッションを重ねてもASLR(アドレス空間配置のランダム化。メモリ上の配置を毎回変える防御)が有効な状態で動く攻撃コードを作れませんでした。公開されたばかりのOpus 5に同じ問題を渡したところ、3時間以内に成功したと書いています。そのうえで「かつては潤沢なリソースを持つチームと数か月を要した作業が、いまは数日に圧縮できる」と述べ、ソフトウェアが長く頼ってきた「複雑さによる守り」が弱くなったと整理しています。
ただし全自動ではありません。どの部品を狙うかの判断も、フォーラムから社員アカウントへ移る設計も、人が担っています。AIが変えたのは発想ではなく、既知の弱点を実際に動くものへ仕上げるまでの所要時間だと読むのが正確です。攻撃側だけの話でもありません。当サイトで取り上げた数百体のAIエージェントによるPaperCut攻撃が攻撃側の実例だとすれば、今回は防御側が同じ道具で同じ速度を出せることを示した記録です。
日本の読者にとっての読みどころ
この連鎖は、OpenAI固有の事情にほとんど依存していません。同じ形の構成は国内にも広く存在します。
とくに3点目は日本企業でも珍しくありません。コミュニティフォーラムやヘルプセンターを外部SaaSに置き、社内と同じIDでログインできるようにしている構成です。今回、OpenAIのバグバウンティはDiscourseに対するテストを対象外としていました。「自社の資産ではないから範囲外」という線引きが、そのまま実際の入口になったかたちです。自社の対象範囲も、攻撃者から見た到達経路と一致しているか確かめる価値があります。
4点目も見落としやすいところです。CodexやClaudeのようなコーディングエージェントに一度GitHubを接続すると、その接続は本人の操作がなくても生き続けます。アカウントを取られた瞬間に、連携先が同じ権限で使われると考えておくべきでしょう。
次に動くなら、順番はこうなります。まずユーザー投稿のファイルを変換している箇所を洗い出し、サンドボックス化されているかを確認する。次にSSOで発行しているトークンの権限範囲を、外部SaaS向けから優先して見直す。そのうえで、AIエージェントに接続済みの連携を棚卸しし、特権アカウントと同じ管理下に置く。いずれも今日から着手でき、今回の連鎖のどこかを確実に切れます。
