OpenAI 従業員のChatGPT・Codexアカウントを乗っ取り内部リポジトリへ到達　Hacktronがlibheif RCEとSSO設定不備を連鎖

セキュリティ企業Hacktron AIは2026年9月13日、OpenAIのコミュニティフォーラム「community.openai.com」とOpenAIのSSO（シングルサインオン）を連鎖的に悪用し、OpenAI従業員のChatGPT・Codexアカウントへアクセスした調査結果を公表しました。

Hacktronによると、最初の侵入口はOpenAIが利用するDiscourseの画像処理でした。HEIC／HEIF画像の処理で使われるlibheifの脆弱性を利用して、OpenAIのコミュニティフォーラム上でリモートコード実行（RCE）を実証しました。

さらに、フォーラムで使われていた「Sign in with OpenAI」のSSO設定上の問題を組み合わせることで、フォーラムへOpenAIアカウントでログインした利用者のChatGPT・Codexアカウントへアクセスできる状態になったとしています。

研究者は影響確認のため、OpenAI従業員のCodexへ指示を送り、OpenAI内部のモノレポジトリopenai/openaiへ無害なプルリクエストを作成しました。Hacktronは機密コードを閲覧せず、その時点で検証を停止したと説明しています。

OpenAI側の問題は7月25日の報告から約14時間後に修正されたとHacktronは報告しています。OpenAIは9月1日に6,500ドルのバグバウンティを支払い、Hacktronが掲載したOpenAI側のコメントでは、報奨金はDiscourseへのテストではなくOpenAI側の問題に対するものだと説明されています。

一方、OpenAI自身による本件の詳細な技術アドバイザリは、2026年9月18日時点で確認できません。本稿ではOpenAI側の影響と修正状況について、Hacktronの責任ある開示レポートに基づく内容として整理します。

OpenAI・Hacktron調査のサマリー

確認できている内容：

• Hacktron AIは2026年9月13日、OpenAIを対象としたセキュリティ調査「Hacking OpenAI」を公開しました。
• 実際の検証は2026年7月23～25日に行われました。
• 攻撃チェーンは、Discourseの画像アップロード処理とOpenAI SSOの問題を組み合わせたものです。
• Discourse環境では、ImageMagick経由でlibheifがHEIC／HEIF画像を処理していました。
• Hacktronは、細工した画像の処理を起点にOpenAIのcommunity.openai.comでRCEと管理権限を取得したと報告しています。
• Discourseはこの問題についてGHSA-vhm9-85gw-x335を公開し、CVE-2026-32882、CVSS 8.8（High）として修正版を案内しています。
• Hacktronは、フォーラム侵害とOpenAI SSOの設定不備を組み合わせ、複数のOpenAI従業員のChatGPTアカウントへアクセス可能だったと報告しています。
• 研究者はOpenAI従業員1名のCodexを使い、OpenAI内部のモノレポジトリへ無害なプルリクエストを作成して影響を実証しました。
• Hacktronは、内部コードなどの機密情報は閲覧しなかったと説明しています。
• OpenAIはHacktronの報告から約14時間後にOpenAI側の問題を修正したとされています。
• OpenAIは9月1日、Hacktronへ6,500ドルのバグバウンティを支払いました。
• Discourseは7月28日に公式アドバイザリを公開し、画像処理のサンドボックス化も追加しました。
• Hacktronは脆弱性探索・exploit開発にClaude Opus 4.8とClaude Opus 5を利用しました。
• Hacktronは「完全自律型の攻撃ではなく、熟練した人間の指示が依然として必要だった」と説明しています。
• 悪意ある第三者が同じ攻撃チェーンを実際に悪用したとの公表は確認できません。
• OpenAI SSO側の問題について、公開CVE番号やCVSSは確認できません。
• CVE-2026-32882は2026年9月18日時点でCISA KEVへの掲載を確認できませんでした。

脆弱性・影響の整理表

項目	内容
調査公表日	2026年9月13日
研究者	Hacktron AI
対象	OpenAI community forum、OpenAI SSO、ChatGPT、Codex、接続済みGitHub
最初の侵入口	DiscourseのHEIC／HEIF画像処理
関連ライブラリ	libheif
Discourse側CVE	CVE-2026-32882
Discourse側GHSA	GHSA-vhm9-85gw-x335
Discourse側CVSS	8.8 / High
OpenAI側	SSO設定不備。公開CVE・CVSSは確認できず
影響	OpenAIアカウント乗っ取り、ChatGPT・Codexアクセス、接続済みサービスへの到達可能性
PoC	Codexを介しOpenAI内部monorepoへ無害なPRを作成
OpenAI修正	Hacktronによると2026年7月25日に修正確認
Discourse修正	2026年7月28日に公式アドバイザリ公開
バグバウンティ	OpenAIが6,500ドルを支払い
悪意ある実攻撃	確認できず
CISA KEV	CVE-2026-32882の掲載を9月18日時点で確認できず

発見からOpenAI内部リポジトリ到達まで72時間未満

Hacktronの公表した時系列は次の通りです。

日時	内容
7月23日	Discourseの画像アップロード処理を調査開始
7月24日	libheifのメモリ破壊問題を利用したexploit開発
7月25日 05:00～06:00 UTC	OpenAIのcommunity.openai.comでRCE・管理アクセスを確認
7月25日 08:00～10:00 UTC	OpenAI Bugcrowdへ報告
7月25日 13:30～15:30 UTC	OpenAI従業員アカウントと内部リポジトリへの影響をPoCで確認
7月25日 15:30頃 UTC	追加テストを停止
7月25日 22:49 UTC	OpenAI側修正を確認
7月25日	DiscourseへHackerOne経由で報告
7月27日	Discourseが修正を準備、画像処理サンドボックスを追加
7月28日	DiscourseがGHSA-vhm9-85gw-x335を公開
9月1日	OpenAIが6,500ドルのバグバウンティを支払い
9月13日	Hacktronが詳細レポートを公開

Hacktronによると、最初の発見からOpenAI内部リポジトリへのアクセス確認までは72時間未満でした。

最初の侵入口はOpenAIではなくDiscourseの画像処理

OpenAIのコミュニティフォーラムcommunity.openai.comは、フォーラムソフトウェアのDiscourseを利用しています。

Hacktronは7月23日、Discourseの画像アップロード処理を調査しました。

一般的な画像はFastImageで確認される一方、HEIC／HEIF画像についてはImageMagickのmagickコマンドへ渡され、内部でlibheifによるデコードが行われていました。

このため、利用者がアップロードしたHEIC／HEIFファイルがlibheifのパーサーへ直接到達する構成になっていました。

Hacktronはこの処理経路を調査し、libheifのメモリ破壊問題を利用してコード実行につなげたと報告しています。

本稿では、脆弱性を悪用するための画像生成方法やexploitコードなど、攻撃へ転用できる具体的手順は記載しません。

DiscourseはCVE-2026-32882・CVSS 8.8として公式に修正

Discourseは2026年7月28日、「RCE via malformed HEIF file」と題したGitHub Security Advisoryを公開しました。

公式アドバイザリでは、上流のlibheif脆弱性CVE-2026-32882により、Discourseへの画像アップロードを通じてリモートコード実行につながるとして、深刻度High、CVSS 8.8を付与しています。

修正版として、次のDiscourseバージョンが案内されています。

• 2026.7.0
• 2026.6.1
• 2026.5.2
• 2026.1.6

Discourseは最新Dockerイメージへ修正版libheifを含めたほか、同種の問題に対する多層防御として画像処理のサンドボックス化も追加しました。

Hacktronは、セルフホスト版DiscourseではWeb管理画面上の更新だけでなく、Dockerイメージを再構築して基盤ライブラリまで更新する必要があると注意しています。

 

libheifでは2026年に多数の脆弱性が修正

libheifはHEIF・AVIF画像を読み書きするオープンソースライブラリで、多数の画像処理ソフトウェアやサービスから利用されています。

libheifプロジェクトによると、2026年1月から8月までに37件のセキュリティアドバイザリが公開され、そのうち3件がCritical、13件がHighでした。

CVE-2026-32882自体はlibheif 1.22.0で修正されています。

一方、Hacktronは「HEIF Heist」と呼ぶより広範な調査で、複数のリリース系列にわたる別のメモリ安全性問題も確認しており、2026年9月14日時点では最新のセキュリティ修正版としてlibheif 1.23.4への更新を推奨しています。

そのため企業では、CVE-2026-32882だけを個別に確認するのではなく、OSやコンテナディストリビューションが提供する最新のセキュリティ更新を適用できているか確認する必要があります。

OpenAI SSOの設定不備でChatGPT・Codexへ影響が拡大

OpenAIのフォーラムでは「Sign in with OpenAI」が利用されていました。

Hacktronによると、フォーラム側を侵害した後、OpenAIのSSO設定上の問題を悪用することで、そのフォーラムへOpenAIアカウントでログインした利用者のChatGPT・Codexアカウントへアクセスできました。

研究者はこの問題について、Discourse固有の問題ではないと説明しています。

つまり、OpenAI SSOを利用するファーストパーティまたは第三者サービスが侵害された場合、同じOpenAI側の認証問題を通じてChatGPTやCodexへ影響が波及する可能性があったという主張です。

一方、Hacktronの公開レポートでは、SSO設定不備を再現するための詳細な技術仕様は公開されていません。

OpenAI側の問題には、2026年9月18日時点で公開CVE番号やCVSSスコアも確認できません。

従業員のCodexからOpenAI内部GitHubへ到達

HacktronはOpenAI側の影響を確認するため、侵害したOpenAI従業員のCodexアカウントを利用しました。

このCodexはOpenAIのGitHub組織と接続されていました。

研究者はCodexへ指示を送り、OpenAI内部のモノレポジトリopenai/openaiへ無害なプルリクエストを作成しました。

Hacktronは、これによって内部リポジトリへアクセスできることを証明した一方、実際の機密コードを閲覧せず、そこで検証を終了したとしています。

この点で、本件は「OpenAIの内部コードが漏えいした」と確認された事案ではありません。

確認されたのは、侵害した従業員アカウントに付与されていたCodexとGitHubの権限を利用して、内部リポジトリへ操作可能だったというPoCです。

GitHub・Slack・メールなど接続済みサービスも理論上の影響範囲

ChatGPTやCodexでは、利用者が外部サービスを接続できます。

Hacktronは、侵害されたOpenAIアカウントにGitHub、Slack、メールなどが接続されていれば、それらも理論上の影響範囲になり得たとしています。

ただし、Hacktronが公開した実証で実際に操作したことが確認できるのは、OpenAI従業員のCodexから接続済みGitHubを利用し、内部リポジトリへPRを作成した部分です。

Slackやメールのデータを実際に取得したとの記載はありません。

ChatGPTの接続済みアプリを通じたデータアクセスについては、別の研究でも問題が確認されています。

ChatGPTのアカウントをまたぐデータ漏えい経路、Gmail連携データの持ち出しをCheck Pointが実証

OpenAIは約14時間で修正、6,500ドルの報奨金

Hacktronは7月25日8時～10時（UTC）にOpenAIのBugcrowdプログラムへ問題を報告しました。

同日22時49分、OpenAIから問題を修正したとの回答を受けたとしています。

初回報告から修正確認まで約14時間です。

9月1日にはOpenAIが6,500ドルのバグバウンティを支払い、案件をResolvedとして処理しました。

Hacktronが掲載したOpenAI側のコメントでは、community.openai.comのDiscourse環境自体に対するテストはOpenAIのバグバウンティ対象外であり、6,500ドルの報奨金はOpenAI側で発見された問題に対するものだと説明されています。

OpenAIから本件の詳細な公開技術レポートは確認できないため、修正日時やバウンティに関する情報はHacktronの開示レポートに基づきます。

Claude Opus 5がexploit開発を大幅に短縮

今回の調査でもう一つ確認したいのが、AIモデルが脆弱性探索とexploit開発で果たした役割です。

Hacktronは当初、Claude Opus 4.8へDiscourse Dockerイメージを調査させ、libheifにバックポートされていない修正があることを発見しました。

Opus 4.8はASLRを無効にした環境ではコード実行exploitを作成できましたが、Discourseの実環境に近いASLR有効環境で安定動作させることには苦戦したとしています。

その後、AnthropicがClaude Opus 5を公開したため同じ課題を与えたところ、Hacktronによると約3時間でローカル環境向けの動作するexploitを作成し、その後Discourseで使われるx86-64環境へ適応できました。

研究者はさらに、自社のDiscourse Cloudテスト環境でAIエージェントへ継続的に検証させ、RCE成立を確認しています。

「AIが自律的にOpenAIをハッキングした」わけではない

今回の研究は、AIによるサイバー攻撃能力の進展を示す一方、「Claudeが完全自律でOpenAIへ侵入した」と整理するのは正確ではありません。

Hacktron自身が、今回の活動は完全な自律ハッキングではなく、熟練した人間による指示が依然として必要だったと説明しています。

研究者側では、

• 攻撃対象となる処理経路の選定
• モデルへの調査方針の提示
• 複数モデル・複数セッションの使い分け
• exploitの検証
• OpenAIへの責任ある報告
• 実環境での影響確認範囲の判断

を人間が行っています。

一方、Hacktronは、従来は専門性と時間を必要としたメモリ破壊脆弱性のexploit開発が、AIによって大幅に短縮されたと評価しています。

OpenAIのサイバー評価中にAIエージェントがHugging Face環境へ侵入した別事案については、以下の記事で整理しています。

METR、OpenAI・Hugging Face侵害を独立調査　約700のAIエージェントが攻撃に参加

実際の攻撃で悪用された証拠は確認されず

CVE-2026-32882については、HacktronがOpenAIの実環境で責任あるセキュリティ研究としてexploitを成功させています。

一方、悪意ある第三者が同じ脆弱性やOpenAI SSOの問題を利用して、一般利用者やOpenAIへ攻撃した事例は公表されていません。

2026年9月18日時点で、CVE-2026-32882についてCISA Known Exploited Vulnerabilities Catalogへの掲載も確認できませんでした。

したがって、

• 研究者による実環境での脆弱性実証は確認済み
• 悪意ある攻撃者による実悪用は未確認

と分けて扱う必要があります。

自社でDiscourseを運用している場合の確認事項

Discourseをセルフホストしている企業・組織は、基盤イメージを含めて更新できているか確認します。

Discourse公式アドバイザリでは、最新Dockerイメージへ更新するよう案内しています。

確認したい項目は次の通りです。

• Discourseが修正版へ更新されているか
• Dockerイメージ自体を再構築しているか
• OSパッケージ内のlibheifがセキュリティ修正版か
• HEIC／HEIF／AVIF画像のアップロードを業務上必要としているか
• 不要な画像形式のデコードを無効化できないか
• 画像変換処理をサンドボックスへ隔離しているか
• 画像処理ワーカーから社内ネットワークやクラウドメタデータへ不要な到達性がないか

SSO連携サービスの侵害を「そのサービスだけの被害」で終わらせない

本件では、コミュニティフォーラムの侵害がOpenAIのSSOを経由してChatGPT・Codexへ波及しました。

企業でSSOを導入している場合、認証基盤そのものだけでなく、SSOを利用するサービス側が侵害された場合の影響を確認する必要があります。

例えば、

• どのサービスへ自社SSOを許可しているか
• SSOクライアントごとのredirect URIやtrust設定を棚卸ししているか
• 低重要度のフォーラムや社内ツールと、高権限サービスが同一IDで接続されていないか
• アカウント侵害時に全セッション・トークンを失効できるか
• 接続済みGitHub、Slack、メールなどの権限を把握しているか
• SSO先のサービス侵害を検知した際に、連携先も含めて調査できるか

を確認できます。

SSOの基本的なリスクは以下の記事で整理しています。

シングルサインオン（SSO）とは　概要や必要性を解説

AIエージェントへ接続するGitHub・Slack・メール権限を最小化する

今回、OpenAI内部リポジトリへ到達できた理由の一つは、侵害された従業員のCodexがOpenAIのGitHub組織へ接続されていたことです。

AIエージェントが企業サービスへ接続されると、AI側のアカウント侵害が外部サービスの権限へ連鎖する可能性があります。

企業でChatGPT、Codex、Claude Codeなどを利用する場合は、

• 接続済みアプリを定期的に棚卸しする
• GitHub権限を必要なリポジトリへ限定する
• 書き込み権限が不要な場合は読み取り専用にする
• 本番環境・機密リポジトリへの権限を分離する
• メール・Slackなど必要性の低いコネクタを無効化する
• 退職・異動時にAIサービス側の接続トークンも失効する
• AIアカウントを高権限IDとして監視する

といった対策を確認できます。

AIエージェント全般の権限・ツール連携リスクは以下の記事で整理しています。

AIエージェントのセキュリティとは　公的資料から見る6つのリスクと対策

「既知の脆弱性をexploitへ変えるコスト」が下がる前提で防御する

Hacktronの調査で企業側が確認したいのは、OpenAIが侵害されたという事実だけではありません。

今回使われたlibheifの問題は、上流コードでは以前から修正されていたものの、当初はセキュリティ修正として明確に扱われておらず、Debianやコンテナへ十分にバックポートされていなかったとHacktronは説明しています。

これまでなら、「メモリ破壊の不具合が存在する」ことと、「実環境で安定してRCEを成立させる」ことの間には高い技術的ハードルがありました。

Hacktronは、AIによってこのexploit開発コストが下がっていると指摘しています。

企業では、CVEの有無や公開PoCの存在だけで優先順位を決めるのではなく、

• インターネットから入力を受け取る
• 画像・動画・文書など複雑なファイルを解析する
• C/C++などメモリ安全性問題が起こり得るライブラリを利用する
• コンテナやOSパッケージへ古い依存関係が残る
• 処理系が高権限・社内ネットワークへ到達できる

といった条件を持つシステムを優先して確認する必要があります。

出典

• Hacking OpenAI – Hacktron AI
• RCE via malformed HEIF file / GHSA-vhm9-85gw-x335 – Discourse / GitHub Security Advisory
• libheif Releases – strukturag / GitHub
• libheif Security Policy – strukturag / GitHub
• The Hugging Face incident and the road ahead – OpenAI