OpenAIのハッキング

OpenAIのハッキング

2. ブログ
3. OpenAIのハッキング

ヒープオーバーフローとSSOの設定ミスにより、OpenAIの内部リポジトリを侵害

2026年9月13日 11分で読めます

はじめに

2026年7月25日、私たちは2つの重大な脆弱性を連鎖させることで、複数のOpenAI従業員のChatGPTアカウントを侵害しました。これらのアカウントを使用して、OpenAIの内部リポジトリ、そして潜在的には他の多くのコネクタにアクセスすることができました。

私たちが実際にアクセス権限を得たことを証明するため、機密情報を学習することなく、従業員のCodexを使用してOpenAIの内部モノレポ openai/openai にプルリクエスト #1186742 を開きました。

エクスプロイトチェーン

1. libheif 画像デコーダー
2. Debian セキュリティバックポートの欠如
3. ImageMagick libheifを使用
4. Discourse 画像アップロード
5. OpenAIフォーラム community.openai.com
6. OpenAI SSO 識別情報の不備
7. ChatGPT / Codex アカウントアクセス
8. GitHub 連携された統合
9. 内部リポジトリ OpenAI

エクスプロイトのタイムライン

1. 7月23日 バグを発見
   DiscourseのHEIFアップロードパスをImageMagick経由でlibheifまで追跡し、ヒープオーバーフローを発見しました。
2. 7月24日 初の動作するエクスプロイト
   Opus 4.8でASLRを無効にした状態でコード実行を成功させました。
3. 7月25日 · 06:00 UTC
   信頼性の高いローカルRCE
   Opus 5でASLRを有効にした状態で動作する画像アップロードエクスプロイトにしました。
4. 7月25日 · 10:00 UTC
   community.openai.com でRCE
   エクスプロイトは私たちのDiscourse Cloudインスタンスで動作し、その後OpenAIのフォーラムでも動作しました。
5. 7月25日 · 13:30–15:30 UTC
   アクセス証明のプルリクエストを開く
   従業員のCodexアカウントを使用して、OpenAIの内部モノレポに無害なプルリクエストを開き、その後テストを停止しました。

2ヶ月前まで、OpenAI自身のヘルプフォーラム（community.openai.com）にログインしたユーザーまたはOpenAIの従業員は、誰でもChatGPTおよびCodexアカウントを乗っ取られる可能性がありました。人々はCodexやChatGPTに様々なサービスを接続できるため、理論的にアクセスできる範囲はGitHub、Slack、メールなど、非常に広範囲に及びました。

最初の発見からOpenAIリポジトリへのアクセスまでの全タイムラインは、72時間以内に完了しました。

私たちは直ちにOpenAIとDiscourseに最初の脆弱性を報告し、パッチの調整で協力しました。彼らの細部への注意と迅速な問題解決に感謝します。OpenAIからは $6,500 のバウンティも支払われました。

開示プロセスの全タイムラインはここに記載しています。この記事の後半では、脆弱性の発見方法、claudeモデルの使用方法、そしてこの経験からの学びについて詳しく説明します。

背景

数ヶ月前、Harsh Jaiswalが率い、Mohan PedhapatiとRahul Mainiが参加するHacktronのチームは、最先端のAI企業を調査してセキュリティ脆弱性を発見し始めました。これにより、OpenAIのIDインフラストラクチャにおけるSSOの設定ミスと、OpenAIが使用するコミュニティフォーラムでの libheif RCEを発見しました。

その後、私たちはこの調査をHEIF Heistへと拡大しました。これは、Slack、Meta、GitHub Enterprise、Ruby on Rails、そしてNext.js、Astro、GatsbyのようなNode.jsフレームワーク全体で libheif を追跡する数ヶ月にわたる調査です。驚くべき量の広く使用されているソフトウェアが、この一つの画像処理ライブラリに依存しています。

［画像: xkcd 2347］

アプリケーションがユーザー制御の画像ファイルを処理し、.heic/.heif/.avif画像を受け入れる場合、影響を受けている可能性が非常に高いです。支援が必要な場合は、hello@hacktron.aiまでご連絡ください。

警告

パッチ通知: Discourseをセルフホストしている場合は、今すぐインストールを再構築してください。古いDockerイメージには、画像アップロードを介したコード実行を許可する脆弱な libheif 依存関係が含まれている可能性があります。/var/discourse から git pull の後に ./launcher rebuild app を実行してください。Webインターフェースの更新だけでは、基盤となる画像は置き換えられない場合があります。Discourseホストの顧客は既にパッチが適用されています。セキュリティアドバイザリを参照してください。

OpenAIはフォーラムにDiscourseを使用しており、auth.openai.com を介した「OpenAIでサインイン」を許可しています。OpenAIのサービスとインフラストラクチャを十分に理解した後、フォーラムを侵害することが、このIDフローを通じてより広範なOpenAIサービスへのパスを作成する可能性があると信じる理由がありました。その仮説をテストするために、まずOpenAIのDiscourseコミュニティフォーラムのようなサービスでリモートコード実行（RCE）を獲得する必要がありました。

Discourseアプリ自体は実際には簡単なターゲットではありません（過去に調査したことがあります）が、依存関係を攻撃できると考えました。

libheifにおけるヒープバッファオーバーフロー

7月23日、Discourseの画像アップロードパイプラインのレビューを開始し、HEICおよびHEIFファイルが通常とは異なるパスをたどることを発見しました。Discourseは通常、画像チェックにFastImageを使用していましたが、FastImageはHEIFをサポートしていなかったため、それらのファイルをImageMagickの magick コマンドに渡して変換していました。2 これにより、基盤となる libheif パーサーが攻撃者が制御するファイルに直接さらされることになりました。

Discourse DockerイメージでOpus 4.8セッションを開始し、インストールされている libheif パッケージのセキュリティ問題の検査を依頼しました。しばらくして、一部のセキュリティ修正がlibheifパッケージにバックポートされていないことが判明しました。これにより、HEICデコード中にOOB R/Wプリミティブにつながるヒープバッファオーバーフローが可能になりました。

興味深いことに、脆弱なコードは前年にアップストリームで変更されていましたが、そのコミットはセキュリティ修正として文書化されておらず、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 コード実行エクスプロイトを開発しました。その後、ASLRが有効になっているDiscourseのデフォルト設定に対して信頼性を高めるために、いくつかの別々のセッションを起動しましたが、これはうまくいきませんでした。

Opus 5リリース

その夜、AnthropicはClaude Opus 5をリリースしました。5 新しいセッションを開始したところ、まず3時間以内にローカルMac用の動作するARM64エクスプロイトが生成されました。その後、x86-64環境とDiscourseが使用する jemalloc 設定にエクスプロイトを移植するように依頼しました。

7月25日午前6時までに、画像アップロードを介したローカルRCEを確認しました。その後、Claudeを自律的な /goal ループに入れ、私たちのDiscourse Cloudインスタンスに対して実行しました。これは、Opusがリモートインスタンスへのエクスプロイト書き込みを拒否したため、CTFターゲットに見せかけるために rce.ee/ctf-forum を介してプロキシされました。

午前10時に再度確認したところ、エージェントはDiscourse CloudでRCEを達成し、/etc/hosts を読み取ることでアクセスを実証しました。生成されたエクスプロイトスクリプトを使用して、OpenAIのインスタンスでRCEを獲得することに成功しました。

フォーラムのアクティブメンバーからのChatGPT/Codexアカウントのインタラクションなし乗っ取りの仮説が確認された後、直ちにOpenAIにレポートを送信しました。その後、OpenAI従業員のアカウントを乗っ取り、そのCodexはOpenAIのGithub組織に接続されていました。内部コードに実際にアクセスすることなく影響を実証するために、この従業員のCodexアカウントに、OpenAIの内部モノレポでプルリクエストを開くようにプロンプトを送信しました。その後、さらなるテストを停止しました。

［画像: OpenAIの内部モノレポへのアクセスを示す、編集されたプルリクエスト］

影響証明をBugCrowdの提出情報に更新し、OpenAIセキュリティに警告しました。Discourseにもレポートを作成し、彼らのHackerOneプログラムに報告しました。Discourseは土曜日にレポートを受け取り、日曜日に返信し、月曜日には修正を完了しました（迅速さに拍手）。彼らはまた、ImageMagickのサンドボックス化を直ちに開始しました。

エスカレーションの脆弱性はDiscourse固有のものではないことを強調したいと思います。これはOpenAI SSOの問題であり、フォーラムの侵害をChatGPTとCodexへのアクセスに変えました。OpenAI SSOを使用する任意のファーストパーティまたはサードパーティのOpenAIサービスが侵害された場合、同じアクセスにつながる可能性があります。Discourseは単にそれを証明する一つの方法でした。

これらの脆弱性を発見するためのコスト

DiscourseとOpenAIのハッキングは、エージェントにとっては数日、人間にとってはわずか数時間で済みました。Slack、Metaなどに対象を広げたHEIF Heistという研究プロジェクト全体は2ヶ月かかり、トークン費用は合計3,000ドル未満で、3人の研究者によって実施されました。各新しい企業へのエクスプロイトの適応は、通常1〜2日で完了しました。

新しいモデルごとに能力が向上していることを観察しました。これは、本レポートで提示されたDiscourseエクスプロイトからも明らかです。Opus 4.8は、ASLRが有効な状態で動作するエクスプロイトを生成するのに数セッションを要しました。Opus 5のリリースから数時間以内に、同じ問題を与えたところ、成功しました。より広範なキャンペーン全体で、Opus 5からGPT-5.6 Solへの明確なジャンプが見られました。この時点では、ターゲットシステムについて何も知らない状態で脆弱性を悪用する必要がありました。

各ターゲットについて、テストは画像アップロードから始まりました。そこから、メモリ破損を信頼性の高いメモリリークまたはシェルに変換しました。通常、正確な libheif バージョン、libcバージョン、またはデプロイメント環境を知ることなく行われました。AIはほぼ盲目の状態で開始し、1〜2日以内に各企業のエクスプロイトを適応させました。Shopifyを除き、数千枚の画像が送信され、画像プロセッサが繰り返しクラッシュした後でも、活動を検出した企業は認識していません。

コード実行がサンドボックスまたは制限された環境内に着地した場合、モデルは特権昇格、ラテラルムーブメント、および既存の防御のバイパスにも役立ちました。これは完全に自律的なハッキングではありませんでしたが、熟練した人間のガイダンスは依然として重要でしたが、小規模チームが実行できる作業量は劇的に増加しました。

エピローグ

ソフトウェアは長らく、複雑さによるセキュリティという一種の恩恵を受けてきました。コードや脆弱性自体は公開されていても、バグを信頼性の高いエクスプロイトに変えるには、依然として稀な専門知識、多大な時間、そしてターゲット環境の知識が必要でした。既知のメモリ破損脆弱性は運用コストが高く、ゼロデイは主に最も価値の高いターゲットのために予約されていました。

これは決して本当のセキュリティ境界ではありませんでしたが、実際には一般企業をソフトウェア脆弱性から保護していました。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に感謝します。

参考文献

この研究のチームと協力してください。

Hacktronは、トップCTF研究者、経験豊富なレッドチーマー、攻撃的セキュリティ研究者を集めています。私たちはAIを活用してセキュリティ研究を加速し、悪意のあるアクターよりも先に広く信頼されているソフトウェアの脆弱性を発見・排除しています。私たちは、最先端の研究室やその他のインターネットクリティカルシステム全体でこの研究を続けています。それらのいずれかのセキュリティを担当している方は、ぜひご協力ください。

前の投稿 OpenAIモデルがどのように暴走してHugging Faceをハッキングしたか
次の投稿 あなたは最新の投稿にいます！