OpenAIの社内リポジトリに外部の研究者が入れた、という話はそれだけで強い。しかも手口は一つではなく、画像処理ライブラリの脆弱性と、OpenAI側のSSO設定の問題がつながって成立していた。Hacktron AIの報告は、単発のバグ発見というより、ふだん別々に見える弱点が連鎖すると何が起きるかを示している。AIを使った攻撃手順の組み立て方まで含めて、今のセキュリティの空気をかなりよく表している記事だと思う。
Hacktron AIの3人の研究者は、2026年7月25日に2つの脆弱性をつなげて、OpenAI社員のChatGPTアカウントを複数乗っ取れる状態にしたと説明している。そこからさらに、内部リポジトリへのアクセス可能性まで確認したというのが記事の骨子だ。証明のために、実際の社内コードを読まずに済むよう、被害者のCodexを使ってOpenAIの内部モノレポにPR #1186742を作成したと書いている。
出発点は、OpenAIが運営するヘルプフォーラム community.openai.com だった。OpenAIはこのフォーラムに Discourse を使っており、「Sign in with OpenAI」で auth.openai.com を通じた認証もできた。Hacktron AIは、ここを取れればOpenAIの他サービスにもつながるのではないかと見ていたという。実際、フォーラムを起点にChatGPTやCodexのアカウントへ広がる可能性があり、GitHub、Slack、メールなど、連携先まで含めると影響範囲はかなり広い。
最初の穴は Discourse 側にあった。画像アップロードの処理を調べる中で、HEIC/HEIF画像が特殊な経路を通ることを見つけた。通常は FastImage で確認するが、HEIFは対応していないため ImageMagick の magick に回され、その際に libheif のパーサが攻撃者の入力を直接受ける。研究者たちは Opus 4.8 を使って、Discourse の Dockerイメージに入っている libheif を調べ、セキュリティ修正の一部が backport されていないことを突き止めた。結果として、HEICデコード時に heap buffer overflow が起き、OOB read/write につながる可能性があったという。
記事では、この問題の背景として、上流でコードは去年変更されていたのにセキュリティ修正として扱われず、CVE も付かなかったことが影響したかもしれない、と述べている。Discourse の Dockerイメージは Debian 12 ベースで libheif 1.19.7 を使っており、当時の Debian 13 でも 1.19.8 が残っていたという。のちに Debian 13 には 2026年8月8日にセキュリティ更新が出たとも書かれている。
もう一つの穴は OpenAI の SSO 設定だ。Hacktron AIによれば、Discourse の侵害だけでは終わらず、OpenAIの認証の組み合わせによって、ChatGPT や Codex のアカウントにまで到達できた。彼らは 7月23日に調査を始め、7月24日には ASLR を無効にした環境で ImageMagick/libheif のコード実行 exploit を作成し、7月25日には Claude Opus 5 を使って x86-64 や jemalloc 設定向けに移植した。朝6時までにローカル RCE を確認し、さらに自前の Discourse Cloud 環境で自動試行させ、10時の時点で /etc/hosts を読める形で RCE に到達したという。
その後、OpenAI のインスタンスでも同じ exploit を通し、フォーラム利用者のアカウントに実際の影響が出うることを確認したうえで報告した。OpenAI社員のCodexがGitHub組織に接続されていたため、そこから内部モノレポにPRを出して影響を示したのが、記事中のデモだ。OpenAIは約14時間後に修正を確認し、最終的に $6,500 のバウンティを支払った。Discourse 側にも報告され、土曜に受け付け、日曜に応答し、月曜には修正準備ができ、画像処理の sandboxing も進めたとしている。Hacktron AIは、調査全体は72時間未満、より広い HEIF Heist 研究でも3人で2か月、トークン費用は合計 $3,000 未満だったと述べている。
この話でまず刺さるのは、攻撃の入口が「画像を1枚上げる」だったことだと思う。メール添付やログインフォームよりも、ぱっと見では危険が薄そうな場所だ。それでも、変換処理の都合で ImageMagick に渡り、さらにその奥の libheif にまで入力が届くと、コード実行に変わってしまう。ここで重要なのは、問題の本体がDiscourseだけではなく、依存ライブラリの backport 状況まで含めた“積み木”になっていた点だ。ユーザーからは見えない層に古い脆弱性が残り続けると、製品側が安全でも崩れる。私は、これは今のSaaSやOSS運用の弱点をかなり正直に映していると思う。
もう一段気になるのは、フォーラムの侵害がその場で閉じなかったことだ。OpenAIのSSOが同じ認証基盤にぶら下がっていたため、ChatGPTやCodexに広がり、そこからGitHub連携まで見えてきた。つまり、守るべき境界は「フォーラム」「社内ツール」「AIアシスタント」で別れているように見えて、実際にはかなり連結していたわけだ。企業は単にログインを統一すると便利になるが、そのぶん1か所の失敗が波及する。この記事は、SSOの便利さがそのまま攻撃面の拡大でもあることを、かなり生々しく示している。しかも研究者が示したのは理論ではなく、実際に社員アカウントから内部PRを作れるところまでだ。そこが重い。
記事ではClaude Opus 4.8からOpus 5への差も印象的だ。4.8ではASLRあり環境での再現に苦戦したのに、Opus 5は数時間でARM64版を作り、さらにx86-64へ持っていった。ここでAIが「魔法の攻撃者」になったというより、面倒な移植や試行錯誤をかなりの速度で回せるようになった、というのが実態ではないかと思う。人間がやると数日かかる移植や調整を、AIが短時間で何度も振れる。すると研究者は、穴探しそのものよりも「どこまでつながるか」の確認に時間を割ける。防御側にとって怖いのは、攻撃が高度になったというより、成立条件の探索コストが下がったことだろう。
OpenAIもDiscourseも対応は早かった。記事だけを見ると、検知から修正までの動きはかなり機敏だ。ただ、そこで終わりにくいのがこの種の問題だと思う。Discourse側では単なるアップデートでは足りず、古いDockerイメージを使っている場合は rebuild が必要で、ImageMagick の sandboxing まで入れた。OpenAI側も、SSOの問題が残っていれば別のサービスに同じ構造で波及しうる。つまり、直したのは「この一件」でも、見直すべきなのは認証、依存関係、アップデート運用、外部連携の全部だ。私は、この報告の価値は脆弱性そのものより、どこまでが1つの事故としてつながるのかをはっきり見せた点にあると思う。
参考: Hacking OpenAI
