画像1枚からOpenAI社内モノレポへ、libheifのヒープ破壊とSSO不備が繋いだ72時間の侵入劇

TL;DR

セキュリティリサーチチームのHacktron AIは2026年9月18日、Discourseの画像デコーダとOpenAIの認証基盤を連鎖させ、OpenAI従業員のアカウントを経由して社内モノレポへ到達した侵入調査の詳細を公開した。
調査は2026年7月25日に責任ある開示（Responsible Disclosure）として行われたもので、最初の発見から社内モノレポへの到達までにかかった時間は72時間未満だった。

今回の攻撃は、単独では完結しない2つの脆弱性を組み合わせた多段のエクスプロイトチェーンだ。
外側のフォーラムで起きた画像処理のメモリ破壊が、中央のSSOを経由して、最深部にある社内GitHub組織の開発権限へと一気に貫通した。

HEIF画像1枚から社内モノレポへ至る攻撃連鎖

攻撃チェーンの全体像は次の図のとおりだ。

flowchart TD
  A["HEIC/HEIF画像をフォーラムへアップロード"] --> B["DiscourseがFastImage非対応のため<br/>ImageMagickのmagickコマンドへ委譲"]
  B --> C["libheifがHEICをデコード<br/>ヒープバッファオーバーフロー発生"]
  C --> D["ASLRを突破してフォーラムサーバー上でRCE達成"]
  D --> E["OpenAI SSOのアイデンティティ欠陥を悪用<br/>フォーラム利用者のセッションを横取り"]
  E --> F["OpenAI従業員のChatGPT / Codexアカウントを奪取"]
  F --> G["従業員のCodex連携を通じて社内GitHub組織へ到達"]
  G --> H["社内モノレポ openai/openai にPR #1186742を作成"]

連鎖の各段階が担った役割は次の表に分かれる。

段階	対象コンポーネント	攻撃の内容	獲得した権限
1. 入口	community.openai.com (Discourse)	HEIF画像のアップロード	画像処理プロセスの呼び出し
2. 脆弱性1	libheif 1.19.7 (Debian 12)	ヒープバッファオーバーフロー	メモリの境界外読み書き（OOB R/W）
3. コード実行	フォーラム基盤	Claude Opus 5によるシェル奪取	フォーラムサーバーのRCEと管理者権限
4. 脆弱性2	auth.openai.com (OpenAI SSO)	SSOアイデンティティ設定の不備	ログイン中ユーザーのセッション奪取
5. 権限昇格	従業員のChatGPT / Codex	従業員アカウントの横取り	社内GitHub組織への連携アクセス
6. 実証（PoC）	社内モノレポ openai/openai	Codexへプロンプトを送信しPR作成	社内リポジトリへの書き込み能力を証明

起点はOpenAIのヘルプフォーラムだったが、終着点は従業員個人の開発環境と社内リポジトリだった。

セキュリティ修正と明記されなかったlibheifのコミット

最初の侵入経路はDiscourseの画像アップロード機能だった。
Discourseは通常、アップロードされた画像の寸法やヘッダ検査に軽量なFastImageを使う。
しかしHEICやHEIF形式はFastImageが対応していないため、フォールバックとしてImageMagickのmagickコマンドを直接呼び出していた。

この設計によって、ImageMagickが内部で呼び出すC/C++製画像デコーダlibheifへ、外部から送られた画像データがそのまま流し込まれた。
以前当ブログで検証したRailsのCVE-2026-66066でも、Active Storageが画像処理をlibvipsへ委譲した隙を突かれてサーバー内の秘密情報が露出した。
Webアプリケーションフレームワーク本体が堅牢でも、画像処理ライブラリへフォールバックした瞬間に攻撃面が跳ね上がる構図は共通している。

さらに深刻だったのは、libheifの修正管理だった。
upstreamのリポジトリでは、該当箇所に対して前年にsimplify overlay overlap area computation（コミット85e21ad44）という修正が入っていた。
しかし、このコミットは通常のコード整理として扱われ、セキュリティ修正として明記されずCVEも採番されなかった。

脆弱性データベースへ登録されなかったため、Debianプロジェクトはこの修正がセキュリティ上重要だと把握できなかった。
結果として、Debian 12（Discourseの公式Dockerイメージが採用していたベース）にはパッチがバックポートされず、脆弱なlibheif 1.19.7が本番で稼働し続けていた。
SQLiteの偽CVE騒動とAdvisory Databaseの未審査問題で触れたように、世間では無意味なCVEの乱造が騒がれる一方で、本当に重大なメモリ破壊バグがサイレント修正の陰に隠れてディストリビューションに届かないというサプライチェーンの歪みが浮き彫りになった。

Claude Opus 5が3時間で埋めたASLRの壁

脆弱性が判明しても、実稼働中のDiscourse上で安定したリモートコード実行（RCE）を成立させるのは容易ではない。
Debian環境にはメモリ上のプログラム配置を毎回ランダム化するASLRが有効になっており、ヒープの構造もjemallocによって保護されていた。

Hacktron AIチームは脆弱性の探索とエクスプロイト開発にAnthropicのClaudeを活用した。
AIが勝手に目標を選んで攻撃したわけではない。
研究者がDocker環境を立ち上げ、攻撃対象や条件（ASLRの有無）を指定し、試行錯誤の実行ループを回した。
当初使っていたClaude Opus 4.8では、ASLRを無効化したローカル環境でRCEを動かすところまでは進んだが、ASLRが有効な実環境向けのエクスプロイト作成では何セッション試行しても失敗した。

転機となったのは、調査を行っていた日の晩に行われたClaude Opus 5のリリースだった。
チームがOpus 5へ切り替えて同じ課題を指示したところ、3時間でARM64（Mac）向けの動作エクスプロイトが出力された。
続いてDiscourseが動くx86-64およびjemallocのメモリ配置へ移植させ、翌朝6時（UTC）にはローカルのDockerコンテナ上で画像アップロード経由のRCEを再現した。

さらにチームは、Claudeを自律実行ループ（/goalループ）に組み込み、リモートのテスト環境に対する攻撃を検証させた。
Opusはリモートホストに対する攻撃スクリプトの作成を拒否するガードレールを持つため、チームはCTFの練習環境に見せかけるプロキシ（rce.ee/ctf-forum）を通して検証を回した。
その結果、午前10時にはリモートのDiscourseサーバー上で/etc/hostsを読み出し、完全なRCEを自律的に成立させた。

当ブログで紹介したWordPress 7.0.3のXSS2Shellでも、pwn.aiのマルチエージェントがDOMクロバリングから管理者権限昇格までの多段チェーンを自律的に再現していた。
AIエージェントによる脆弱性調査は、もはや単発のコード監査にとどまらず、メモリ破壊から保護機構の回避、遠隔実行までの連鎖を一気に組み上げる段階へ突入している。

フォーラム侵害をChatGPT乗っ取りへ広げたOpenAI SSOの不備

Discourseは公開フォーラムであり、通常は社内の開発ネットワークと切り離されている。
フォーラム基盤のRCEを取っただけでは、OpenAIの社内リポジトリには届かない構造だった。

この2つを繋いだのが、OpenAIのシングルサインオン（SSO）だった。
フォーラムには「Sign in with OpenAI」ボタンが設置されており、認証基盤であるauth.openai.comと連携していた。
フォーラムサーバーを完全に掌握した攻撃者は、ログインしてきた利用者の認証トークン処理に介入できる。
Hacktron AIが突いたOpenAI側のSSOアイデンティティ欠陥により、攻撃者はフォーラム利用者のセッションを悪用して、そのユーザーのChatGPTおよびCodexのセッション権限まで横取りできた。

重要なのは、これがDiscourse固有の欠陥ではない点だ。
OpenAIの認証基盤が、外部連携サービスが侵害されたケースを想定した分離（ゼロトラスト境界）を維持できていなかった。
OpenAI SSOを利用している連携先が1つでも突破されると、ユーザーのアカウント全体が危険に晒される設計になっていた。

データを盗まずCodexにPRを切らせたPoCと14時間の緊急修正

アカウントの奪取に成功したチームが直面したのは、実害の証明（Proof of Concept）をどう安全に行うかという倫理的課題だった。
奪取したアカウントの中にはOpenAIの現役従業員が含まれており、その従業員のCodexは社内のGitHub組織へアクセスできるよう設定されていた。

社内リポジトリを不用意にクローンしたりコードを読み出したりすれば、機密情報の漏洩事故になってしまう。
そこでチームは、従業員のCodexに対してプロンプトを送り、社内モノレポ（openai/openai）に対してプルリクエスト（PR #1186742）を新規作成させた。
社内コードを一切読まず、外から空の変更を1行コミットしてPRを立てるだけで、リポジトリへの書き込み権限が奪われている事実を完全に証明した。

一連の対応タイムラインは下表のとおり、非常に迅速に進んだ。

日時（UTC）	主体	出来事
2026年7月25日 05:00–06:00	Hacktron AI	フォーラムサーバー上でRCEを達成
2026年7月25日 08:00–10:00	Hacktron AI	Bugcrowd経由でOpenAIのバグバウンティへ初期報告
2026年7月25日 13:30–15:30	Hacktron AI	従業員Codex経由でPR #1186742を作成。OpenAI関係者へ連絡し検証停止
2026年7月25日 22:49	OpenAI	SSO側の問題を修正完了（報告から約14時間）
2026年7月25日	Hacktron AI	HackerOne経由でDiscourseへ脆弱性を報告
2026年7月27日	Discourse	ImageMagickのサンドボックス化を含む修正パッチを完成
2026年7月28日	Discourse	セキュリティアドバイザリ（GHSA-vhm9-85gw-x335）を公開
2026年8月8日	Debian	DSA-6417-1を公開し、Debian 13向けにlibheifをパッチ
2026年9月1日	OpenAI	$6,500の報奨金を付与し、チケットを解決済みに変更
2026年9月18日	Hacktron AI	調査内容の技術解説をブログとXで一般公開

OpenAIは報告から約14時間でSSO側の問題を修正した。
バグバウンティの審査において、Discourseサーバーへの攻撃自体は対象外とされたものの、OpenAI側のSSO脆弱性とその深刻度が評価され、$6,500の報奨金が支払われた。

また、Discourse側も週末を挟んだ報告に対して即座に反応し、週明け月曜には修正パッチを用意した。
単にlibheifを更新するだけでなく、今後の未知のデコーダ脆弱性に備えてImageMagickの実行環境自体をサンドボックス化（分離コンテナ化）する多層防御（Defense in Depth）を導入した。

Hacktron AIはこの調査を機に「HEIF Heist」というプロジェクトを立ち上げ、Slack、Zoom、Meta、Ruby on Rails、Next.js、Astroなど、画像処理ライブラリに依存する主要基盤の調査を拡大している。
複雑なメディアフォーマットの処理系は、今後も徹底的なプロセス隔離と最小権限の徹底が求められる。