HEIC画像1枚からOpenAI社内リポジトリまで：72時間で2つの脆弱性をつなぐ
ヒープオーバーフローとSSO設定ミスによりOpenAIの内部リポジトリが侵害される
日本語
コピー
概要
2026年7月25日、私たちは2つの重大な脆弱性を連鎖させ、複数のOpenAI従業員のChatGPTアカウントを侵害した。これらのアカウントを入手したことで、OpenAIの内部リポジトリにアクセスできるようになり、理論上は他の多くのコネクタにもアクセス可能だった。
私たちが本当にアクセス権を取得したと考えるものを証明しつつ、機密情報に一切触れないようにするため、その従業員のCodexを使い、OpenAIの内部monorepoでPR #1186742 openai/openaiを開いた。
脆弱性の悪用チェーン
- libheif 画像デコーダ
- Debian セキュリティバックポートパッチの欠落
- ImageMagick がlibheifを使用
- Discourse の画像アップロード
- OpenAIフォーラム community.openai.com
- OpenAI SSO の認証欠陥
- ChatGPT / Codex アカウントへのアクセス
- GitHub の接続済み連携
- 内部リポジトリ OpenAI
2か月前まで、OpenAI自身のヘルプフォーラム（community.openai.com）にログインしたユーザーやOpenAI従業員は、ChatGPTとCodexのアカウントを乗っ取られる可能性があった。ユーザーはさまざまなサービスをCodexやChatGPTに接続できるため、私たちが理論上到達できる範囲は極めて広く、GitHub、Slack、メールなども含まれた。
脆弱性を最初に発見してからOpenAIのリポジトリに侵入するまで、所要時間は72時間未満だった。
私たちは初期の脆弱性を直ちにOpenAIとDiscourseに報告し、両社と協力してパッチを調整した。細部への真摯な対応と迅速な修正に感謝する。OpenAIはさらに6,500ドルの賞金を支払った。
完全な開示タイムラインはこちら。本記事の残りでは、この2つの脆弱性をどう発見したか、claudeモデルをどう使ったか、そしてこの経験から何を学んだかを詳しく説明する。
- 2026年7月25日 05:00–06:00 UTC 初期発見 HacktronAIチームは、
community.openai.comでホストされているDiscourse環境でリモートコード実行（RCE）と管理者権限を取得した。 - 2026年7月25日 08:00–10:00 UTC Bugcrowdへの提出 製品横断的な影響を確認した後、チーム内で責任ある開示プロセスについて調整し、BugcrowdのOpenAIバグバウンティプログラムを通じて報告を提出した。
- 2026年7月25日 13:30–15:30 UTC OpenAI従業員アカウントへのアクセスと概念実証 この脆弱性の実際の影響を示すため、OpenAIの内部monorepoで無害な概念実証のpull requestを作成した（リンクはOpenAIの要請により伏せている）。関連する発見を既存のBugcrowd報告に追記し、Twitter/XでOpenAIの知人に直接伝え、15:30 UTC頃にそれ以上のテストをすべて停止した。
- 2026年7月25日 22:49:45 UTC OpenAI側での修正確認 OpenAIが報告に返信し、問題が修正されたことを確認した。最初の提出から約14時間後だった。
- 2026年7月25日 HackerOne経由でDiscourseに報告 DiscourseのHackerOneプログラムを通じて報告を提出した。
- 2026年7月26日 Discourseが返信 Discourseは日曜日に報告へ返信した。
- 2026年7月27日 Discourseの修正準備完了 Discourseは月曜日には修正を用意し、多層防御として画像処理サンドボックスを追加した。
- 2026年7月28日 Discourseが公告を公開 DiscourseはGHSA-vhm9-85gw-x335を公開し、パッチと再構築手順を添えた。
- 2026年9月1日 OpenAIが6,500ドルの賞金を支払い解決済みとマーク OpenAIのコメント——この報奨の範囲を明確にすると、Discourseがホストするcommunity.openai.comに対するテストは、私たちのバグバウンティプログラムから明示的に除外されている。この報奨が評価したのはOpenAI側の発見であり、Discourseに対する行為ではない。
背景
数か月前、Hacktronの私たちのチームは最先端AI企業を調査し、セキュリティ脆弱性を探し始めた。チームはHarsh Jaiswalが率い、Mohan PedhapatiとRahul Mainiが参加した。この研究により、OpenAIのID基盤におけるSSO設定ミスと、OpenAIが使用するコミュニティフォーラムにおける libheif RCEを発見した。
その後、私たちは研究をHEIF Heistへと拡張した。これは数か月にわたる調査で、libheif がSlack、Meta、GitHub Enterprise、Ruby on Rails、そしてNext.js、Astro、GatsbyなどのNode.jsフレームワークへ広がる経路を追跡したものだ。広く使われているソフトウェアの多くがこの画像処理ライブラリに依存しており、その数の多さは驚くべきものだった。
ユーザーが制御できる画像を扱い、かつ .heic/.heif/.avif 形式を受け付けるアプリは、影響を受けている可能性が高い。何らかの支援が必要な場合は hello@hacktron.ai まで連絡してほしい。
community.openai.com を攻略する
summary_svg:last-child]:rotate-180 [&[open]>summary]:mb-3" open> 警告
パッチに関する注意： Discourse を自前で運用しているなら、すぐに再ビルドしてインストールし直してほしい。古い Docker イメージには脆弱な libheif 依存が含まれている可能性があり、画像アップロード経由でコード実行が可能になる。/var/discourse で git pull と ./launcher rebuild app を順に実行すること。Web インターフェースからの更新だけでは、下層のイメージが置き換わらないことがある。Discourse のホスト型顧客はすでにパッチ済み。詳細はセキュリティアドバイザリを参照。
OpenAI のフォーラムは Discourse 上で動いており、auth.openai.com による「Sign in with OpenAI」を許可している。OpenAI のサービスとインフラを十分に調査した結果、このフォーラムを掌握すれば、この認証フローを通じて OpenAI のより広範なサービスへの経路が開けると判断した。この仮説を検証するには、まず OpenAI の何らかのサービス（たとえば Discourse コミュニティフォーラム）でリモートコード実行を成立させる必要がある。
Discourse 本体はそれほど攻めやすいわけではない（過去に調査した）。そこで、その依存関係のどれかに目を付けることにした。
libheif のヒープバッファオーバーフロー
7 月 23 日、Discourse の画像アップロード処理の調査を始め、HEIC と HEIF ファイルが通常とは異なる経路を通ることに気づいた。Discourse は通常 FastImage で画像を検査するが、FastImage は HEIF に対応していないため、これらのファイルは ImageMagick の magick コマンドに渡されて変換される。2 これにより、下層の libheif パーサーが攻撃者の制御するファイルに直接さらされる。
Opus 4.8 のセッションを立ち上げ、Discourse の Docker イメージを接続して、インストール済みの libheif パッケージにセキュリティ上の問題がないか調べさせた。しばらくして、一部のセキュリティ修正が libheif パッケージにバックポートされていないことを突き止めた。これにより HEIC のデコード時にヒープバッファオーバーフローが発生し、OOB の読み書きプリミティブが得られる。
興味深いことに、この脆弱なコードは前年にアップストリームで書き換えられていたが、そのコミットはセキュリティ修正としてマークされておらず、CVE も付いていなかった。3 おそらくこれが、Debian 12 と 13 に該当するセキュリティバックポートがなかなか入らなかった理由だろう。Discourse の Docker イメージは Debian 12 をベースにしており、脆弱な libheif 1.19.7 が入っている。当時は Debian 13 でさえ脆弱な 1.19.8 を出したままだった。その後 Debian は 2026 年 8 月 8 日に Debian 13 向けのセキュリティ更新をリリースしている。4
7 月 24 日、Opus 4.8 を使って ASLR を無効にした状態で動作する ImageMagick/libheif のコード実行 exploit を作り上げた。続いていくつか独立したセッションを立ち上げ、Discourse のデフォルト設定を回避し、ASLR を有効にしたまま安定して exploit できるよう試みたが、うまくいかなかった。
Opus 5 のリリース
その夜、Anthropic が Claude Opus 5 をリリースした。5 新しいセッションを立ち上げると、まず 3 時間でローカルの Mac 上で動く ARM64 exploit を作り上げた。次に、この exploit を Discourse が使う x86-64 環境と jemalloc 設定に移植させた。
7 月 25 日午前 6 時までに、画像アップロード経由でローカル RCE が成立することを確認した。その後 Claude を自律的な /goal ループに入れ、自前の Discourse Cloud インスタンスに対して攻撃させ、rce.ee/ctf-forum 経由でプロキシして CTF のターゲットのように見せかけた。Opus はリモートインスタンス向けの exploit を書くことを拒否したからだ。
午前 10:00 に再度確認したところ、agent は Discourse Cloud 上で RCE を成立させ、/etc/hosts を読むことでアクセスを証明していた。生成された exploit スクリプトを使い、OpenAI のインスタンスでも RCE を得た。
フォーラムのアクティブメンバーなら操作を伴わずに ChatGPT/Codex アカウントを乗っ取れるという仮説を確認した後、すぐに OpenAI へ報告を送った。続いて OpenAI 従業員のアカウントを乗っ取り、その Codex が OpenAI の GitHub organization に接続されていることを確認した。影響を証明しつつ内部コードには一切アクセスしないため、その従業員の Codex アカウントに prompt を送り、OpenAI の内部 monorepo で我々のために PR を開かせた。その後、さらなるテストは停止した。
影響の証明を Bugcrowd の提出に追記し、OpenAI のセキュリティチームにも通知した。Discourse 向けにもレポートを用意し、HackerOne のプログラムに提出した。Discourse は土曜にレポートを受け取り、日曜に返信し、月曜には修正を完了した（対応の速さは称賛に値する）。さらにただちに ImageMagick のサンドボックス化にも着手した。
強調しておきたいのは、権限昇格に使ったこの脆弱性は Discourse 固有のものではないということだ。これは OpenAI SSO の問題であり、フォーラムの侵害を ChatGPT と Codex へのアクセスに変えてしまうのはまさにこの点にある。OpenAI SSO を使う OpenAI 自身または第三者のサービスは、ひとつでも侵害されれば同じアクセス権限につながる。Discourse はそれを示す一例にすぎない。
これらの脆弱性を発見するコスト
Discourse と OpenAI を攻撃するのに、agent は数日を要し、人間の作業時間は数時間で済んだ。Slack や Meta などを対象とした HEIF Heist の研究プロジェクト全体は、2 か月を費やし、token の総コストは 3,000 ドル未満、研究者 3 名で完遂した。exploit を新しい企業向けに適合させるのにかかるのは、通常 1〜2 日だ。
新しいモデルごとに能力が高まっていることは、本レポートの Discourse exploit が示している。ASLR を有効にした状態では、Opus 4.8 は複数の session をまたいでも実用的な exploit を作れなかった。Opus 5 のリリースから数時間後、同じ問題を渡したところ成功した。より大規模な作戦では、Opus 5 から GPT-5.6 Sol にかけてさらに明確な飛躍があった。このときは「対象に脆弱性がある」以外、対象システムについて何も知らない状態で利用を完遂する必要があった。
どの対象も、画像を 1 枚アップロードするところからテストを始めた。その後はメモリ破壊を安定したメモリリークや shell に変えていったが、正確な libheif のバージョン、libc のバージョン、デプロイ環境はたいてい分かっていない。AI はほぼ何も知らない状態から始め、1〜2 日で各社向けに使える exploit を作り変えた。Shopify を除き、こうした活動に気づいた企業をほかに知らない。数千枚の画像を送り、彼らの画像処理系が繰り返しクラッシュした後ですら、だ。
コード実行がサンドボックスや制限された環境に落ちた場合も、モデルは権限昇格、横展開、既存の防御の回避を支援した。完全に自律したハッキングではない。熟練した人間の誘導は依然として重要だが、小さなチームがこなせる作業量は大幅に増えた。
あとがき
ソフトウェアは長らく、複雑さがもたらす安全性の恩恵を受けてきた。コードも脆弱性そのものも公開されうるが、bug を安定した exploit に変えるには、希少な専門能力、多大な時間、対象環境の知識が依然として必要だった。既知のメモリ破壊脆弱性の悪用はコストが高く、zero-day の多くは最も価値の高い標的のために取っておかれる。
これは決して本当のセキュリティ境界ではなかったが、実際には、一般の企業をソフトウェア脆弱性の脅威から守っていた。AI はこの保護層を取り除きつつあり、本来希少だった専門能力をより多く計算資源に置き換えている。かつては潤沢なリソースを持つチームが数か月かけて成し遂げた仕事が、いまや数日に圧縮される。
セキュリティの前提は攻撃者の能力に追随しなければならない。現実的な脅威モデルは、誰が高度な攻撃を仕掛けられるかについての時代遅れの想定に頼るのではなく、現在の脆弱性悪用の経済性を織り込むべきだ 6。
Hacktron の使命は、悪意ある行為者より先に、広く信頼されているソフトウェアの脆弱性を発見し排除することで、インターネットの安全に貢献することにある。私たちはフロンティアラボや、インターネットにとって不可欠なその他のシステムに対するこの研究を続けている。あなたがそうしたシステムのセキュリティを担っているなら、ぜひ協力したい。
影響を受けるバージョンとパッチ
HEIF Heist は特定のバージョンを狙ったものではなく、複数のリリース系列（1.19.x、1.20.x、1.22.x、1.23.x など）にまたがる脆弱性の生態系全体を対象としている。最新の上流セキュリティパッチを適用していないデプロイはすべて影響を受けうる。
- 上流を更新する。 ディストリビューションのセキュリティチャネルまたは上流のリリースを通じて、最新のセキュリティパッチを含む
libheifとlibde265のパッケージをインストールする。2026 年 9 月 14 日時点で、最新の上流libheifセキュリティバージョンは v1.23.4 であり、v1.23.2 は後続のセキュリティ修正に置き換えられている。ディストリビューションがパッケージするバージョン番号は古い上流バージョンのままかもしれないが、バックポートされた修正が含まれているため、そのパッケージのセキュリティ勧告も確認すること。7 4 - 多層防御。 ISO ベースのメディアファイル形式の複雑さとデコーダ更新のペースを考えれば、将来メモリ安全上の欠陥が生じる可能性は高い。本番アーキテクチャでは、不要な場所で信頼できない HEIF/AVIF のデコードを無効にするか、画像処理パイプラインを堅牢化した一時サンドボックスで分離して実行すべきだ。ImageMagick のセキュリティポリシーは、受け入れる形式とリソース使用量の制限に対応している。8
謝辞
技術支援をいただいた Sudanshu Rajhbhar に、また草稿の校正、レビュー、および本稿を改善するフィードバックをいただいた Zayne Zhang、Fabian Faessler、Robert Chen、Jessica Ruan に感謝する。
参考資料
[1] xkcd #2347: Dependency ↩[2] Discourse: HEIC 画像のサポート ↩[3] libheif: オーバーレイの重なり領域の計算を簡素化 ↩[4] Debian DSA-6417-1: libheif セキュリティアップデート ↩1 ↩2[5] Anthropic: Claude Opus 5 の紹介 ↩[6] RAND: AI モデルの重みを保護するためのプレイブック ↩[7] libheif v1.23.4 セキュリティメンテナンスリリース ↩[8] ImageMagick セキュリティポリシー ↩
研究チームと一緒に取り組む
Hacktron には、トップクラスの CTF リサーチャー、経験豊富なレッドチームメンバー、攻防両面のセキュリティ研究者が集まっています。AI でセキュリティ研究を加速し、悪意ある攻撃者より先に、広く信頼されているソフトウェアの脆弱性を見つけて潰します。現在もフロンティアラボやその他のインターネット基盤システムを対象に研究を続けています。あなたがそうしたシステムのセキュリティを担っているなら、ぜひ一緒に取り組みたいと考えています。