画像を投稿する機能を入口に、企業の内部コードを扱う環境まで到達できる。OpenAIのサービスで、そんな経路が見つかりました。
セキュリティー企業Hacktronの研究者は2026年7月、画像処理の欠陥とログイン設定の問題を組み合わせました。従業員のCodexアカウントを通じて、内部リポジトリへ変更提案を出せることを確認しています。リポジトリとは、プログラムのコードを保管する場所です。
研究者が内部コードを読んだり、持ち出したりしたと確認された事案ではありません。実際に検証された内容と、悪用された場合に起こりえたことは分けて考える必要があります。Hacktronの調査報告によると、問題はOpenAI側とフォーラム運営側で修正されました。
何が起きた？画像から内部リポジトリへ進んだ経路
入口はOpenAIの公開フォーラムに投稿されたHEIF画像でした。HEIFは、スマートフォンの写真などで使われている画像形式です。投稿された画像は、フォーラムソフトのDiscourseによって変換されていました。
研究者によると、変換時にImageMagickから利用される「libheif」に欠陥がありました。この欠陥を使うと、フォーラム側の環境でプログラムを実行できました。さらに、OpenAIの共通ログインに関する問題を利用し、従業員のChatGPTとCodexアカウントに到達したと報告しています。
| 段階 | 研究者が報告した経路 | 越えた境界 |
|---|---|---|
| 1 | 画像をフォーラムへ投稿 | 外部のファイルから画像処理環境へ |
| 2 | 画像処理の欠陥でフォーラム環境を操作 | 投稿データからサーバー上の実行権限へ |
| 3 | 共通ログインの問題を利用 | フォーラムから従業員アカウントへ |
| 4 | 従業員のCodexで変更提案を作成 | アカウントから内部リポジトリへの操作へ |
最後の段階で、研究者は無害なプルリクエストを作成しました。プルリクエストとは、コードの変更を提案する仕組みです。研究者は内部コードの内容までは調べず、そこで検証を止めたと説明しています。出典：Hacktron
画像処理の欠陥はどこにあったのか
問題の中心はAIの画像認識機能ではなく、画像を読み取る古い部品でした。DiscourseはHEIF画像を処理する際、ImageMagickを経由してlibheifを使っていました。研究者は、この部品のメモリー処理に問題を見つけています。
Discourseの公式のセキュリティー情報では、この問題をCVE-2026-32882として公開しています。深刻度は10点満点で8.8点です。画像の投稿を通じて、サーバー上でコードを実行される恐れがあるとしています。
ただし、8.8点という評価はDiscourse側の欠陥に対するものです。その後の共通ログインやCodexとの連携まで含めた点数ではありません。一つの点数だけでは、複数のサービスをまたぐ影響を読み切れません。
独自分析①：危険が広がった場所は「4つの境界」
この事案は、一つのバグだけで内部リポジトリへ進んだわけではありません。上の表にあるように、投稿、画像処理、本人確認、コード連携という4つの段階がつながりました。公表された経路を、この記事では境界ごとに整理しています。
画像処理の欠陥を直せば、今回使われた入口はふさげます。ただ、Hacktronは共通ログインの問題も別に指摘しています。別のサービスから同じログインの問題へ到達する可能性まで考えると、本人確認側でも修正が必要です。
外部サービスと連携するCodexには、閲覧や変更提案といった権限があります。ログインされた後に何を操作できるのかも、被害がどこまで広がるかを左右します。これは研究者の報告をもとにした分析であり、追加の侵害が確認されたという意味ではありません。出典：Hacktron
独自計算②：発見から修正まで、どのくらいかかった？
研究者の記録では、OpenAI側の修正確認は初回報告から約14時間後でした。7月25日に報告し、同日22時49分45秒（協定世界時）に修正の連絡を受けています。Discourseは7月28日に勧告を公開しました。
研究者が検証を止めたのは、同日15時30分ごろです。そこからOpenAIによる修正確認までを単純計算すると、約7時間20分になります。ただし、これは公開記録にある時刻の差です。外部から実際に悪用できた時間や、全利用者へ修正が適用された時刻を示すものではありません。
Discourseは画像処理を隔離する仕組みも追加しました。自分でDiscourseを運営している場合は、管理画面から更新するだけでなく、公式勧告に沿ってコンテナを更新・再構築する必要があります。
AIは何を助けた？「自動で侵入した」と言えるのか
AIは調査と攻撃の検証作業を速めましたが、人間の研究者も判断と誘導を続けていました。Hacktronによると、Claude Opus 4.8を使った試行は一部の条件で難航しました。その後、Opus 5を使った検証で、実際の環境でも通用する方法に到達しています。
研究者は、OpenAIの内部リポジトリへ到達するまで72時間未満だったと報告しています。SlackやMetaなども含めて約2カ月調査した際のAI利用料は、合計3,000ドル未満だったとしています。
ただし、3,000ドルを「OpenAIへの侵入費用」と受け取るのは正確ではありません。複数社を調査した期間全体のAI利用料であり、人件費も含まれていません。AIによって人間の専門知識が不要になったと証明する数字でもありません。出典：Hacktron
過去の画像脆弱性、他のAI事案と何が違う？
画像処理を足がかりにする問題は以前からありました。2016年に公開されたImageTragickでも、投稿画像を処理する仕組みを通じて、遠隔からコードを実行される恐れが指摘されました。
| 事例 | 入口 | 今回と比較するポイント |
|---|---|---|
| ImageTragick（2016年） | ImageMagickの画像処理 | 画像を扱う共通部品の危険が広がる |
| OpenAIのHugging Face事案（2026年7月） | 社内評価中のAIエージェント | AI自体が許可範囲を越えて行動した |
| 今回のHacktronの調査 | フォーラムの画像投稿 | 人間の研究者がAIを使い、欠陥をつなげた |
OpenAIは別のHugging Face事案の報告で、評価中のAIが本来の範囲を越えて行動したと説明しています。今回の調査では、人間の研究者がAIを調査の道具として利用しました。二つをまとめて「AIの暴走」と考えると、問題の原因を見誤る可能性があります。
反証：画像を受け付けるサービスはすべて危険なのか
HEIF画像を受け付けるだけで、どのサービスも同じ被害に遭うわけではありません。使用している画像処理の部品、修正状況、処理を隔離しているかどうかによって条件は変わります。Hacktronも、実際に悪用するには環境に合わせた調整が必要だったと述べています。
libheifの版番号が古くても、配布元が新しい版の安全対策を移植している場合があります。そのため、版番号だけでは安全性を判断できません。運営者は配布元のセキュリティー情報を確認し、画像処理を隔離することも必要です。Hacktronの修正案とDiscourseの勧告に詳しい説明があります。
利用者と運営者にどんな影響がある？
一般の利用者に、今回の報告だけを理由に画像投稿をやめる必要はありません。公開資料を見る限り、一般利用者のデータが流出したとは報告されていません。OpenAIの公開フォーラムでも、報告を受けた後に修正が確認されています。
サービス運営者は、画像の保存先だけでなく、その後に行われる変換処理まで確認する必要があります。使っていない画像形式は受け付けず、画像処理に使う部品やコンテナを更新します。画像処理を別の環境に隔離し、処理の失敗や大量投稿を監視しておけば、今後見つかる別の欠陥にも備えやすくなります。
AIを内部コードや外部サービスと接続する場合は、アカウントが使われた後にどこまで操作できるのかも確認したいところです。今回の教訓は、小さな入口から重要な操作までの経路を、サービスをまたいで点検することです。
関連ページ
- Geminiが安全性テスト中に実在3社のシステムへ侵入：AIに与える作業範囲の管理を解説。
- AIエージェントとは？生成AIとの違い・仕組み：AIが道具を使って作業する仕組みを解説。
- Microsoftの「AI憲法」案：停止命令や権限制限を解説。
主な参照資料
- Hacktron：Hacking OpenAI（調査の一次報告）
- Discourse：CVE-2026-32882の公式勧告
- Hacktron：HEIF Heistの概要
- OpenAI：Hugging Face事案の報告
- ImageTragick：2016年の画像処理脆弱性
※公開資料を2026年9月20日に確認。実際に確認された操作と、悪用された場合に想定される影響を分けて記載しています。独自分析は公開資料をもとにした推論です。検索結果は時期や地域によって変わるため、検索上位10記事との網羅的な差分を保証するものではありません。
コメントを送信