画像1枚から OpenAI の内部リポジトリまで。セキュリティを「モデルの拒否」に任せてはいけない理由
札幌で AI を使って研究と執筆をしています。エンジニアではありません。普段は GPT・Claude・Gemini を、メールとクラウドの資料と案件管理表に繋いで使っています。便利です。だから、その繋ぎ方の話をします。
この記事は、2026年9月13日に公開された Hacktron の調査報告を中心に、公開されている一次資料だけで書いています。犯罪の実例と、許可されたセキュリティ研究と、統制された実験は、それぞれ別の種類の証拠として扱います。同じ材料から英語でも書きましたが、あちらは企業の判断を社会の側から問う構成で、こちらは同じ問題を実装の側から見ます。主張は食い違いません。
先に立場を書いておきます。この事件を「OpenAI にも脆弱性があった」で終わらせるつもりはありません。
気になっているのは、攻撃の能力だけが急速に安くなる一方で、利用者の側に「自分で権限を分けろ」「自分で監視しろ」「自分で認可境界を作れ」と要求されていることです。
便利さは既定値で配られました。防御は、まだ利用者の宿題です。
この順番はおかしいと思います。
1. 8段の連鎖
2026年7月25日、Hacktron の研究者3人が、OpenAI 社員の ChatGPT アカウントを侵害し、社内モノレポに Pull Request を1本開きました。発見から到達まで72時間未満です。
経路はこうなっています。
起点は画像1枚です。Discourse は通常 FastImage で画像を検査しますが、FastImage が HEIF に対応していないため、HEIC/HEIF ファイルは ImageMagick の magick コマンドへ回されていました。その結果、攻撃者が用意したファイルが libheif のパーサに直接渡ります。
Discourse の Docker イメージは Debian 12 ベースで、libheif 1.19.7 が入っていました。上流では前年に該当箇所が修正されていたのですが、その変更はセキュリティ修正として文書化されず、CVE も付いていませんでした。だから Debian にバックポートが届いていなかった。当時は Debian 13 も脆弱な 1.19.8 を配っています。Debian のセキュリティ更新は 2026年8月8日です。
この経路で HEIC のデコード中にヒープバッファオーバーフローが起き、境界外の読み書きが取れる。そこからコード実行まで繋がりました。
そして Hacktron 自身が、報告の中で一番強く書いているのはここです。エスカレーションに使われた脆弱性は Discourse 固有ではない。フォーラムの侵害を ChatGPT と Codex へのアクセスに変えたのは、OpenAI の SSO の問題である。同じ SSO を使うサービスであれば、ファーストパーティでもサードパーティでも、どれが落ちても同じ場所に着く。Discourse はそれを証明する経路の一つにすぎなかった、と。
2. どこで止められたか
層ごとに見ると、止められた場所が3つあります。
依存関係の層。上流の修正がセキュリティ修正として記録されず、CVE が付かなかった。これが配布側の判断を狂わせています。「CVE が付いていないから緊急ではない」という運用は、ここで破れます。自分の系で libheif や libde265 を直接意識している人は少ないと思いますが、画像を受け取るアプリはほぼ必ずどこかでこれを踏んでいます。Hacktron はこの後、同じライブラリを Slack、Meta、GitHub Enterprise、Zoom、Rails や Next.js といったフレームワークまで追跡しています。
アプリケーションの層。ユーザーが投げたファイルが、検査をすり抜けて別のデコーダへ回されていた。フォールバックの経路が、本来の検査より緩い場所へ落ちる形です。Discourse は報告を土曜に受け取り、日曜に返事をして、月曜には修正を用意し、併せて ImageMagick のサンドボックス化を入れています。対応の速さは記録として残しておきます。
アイデンティティと権限の層。ここが本丸です。フォーラムのアカウントが取れたことが、なぜ ChatGPT と Codex のアカウントに、さらに GitHub 連携経由で社内リポジトリに繋がるのか。繋いだのは SSO の設計で、到達範囲を決めたのは「どのサービスを、どの権限で、そのアカウントに繋いであるか」です。
到達できたのはリポジトリだけではありません。Hacktron は、理論上の範囲として GitHub、Slack、メールを挙げています。私たちが Codex や ChatGPT に何を繋いでいるか、そのまま到達範囲になります。
実証は最小限で止めてあります。社内コードは読まず、社員の Codex に指示を出して PR を1本開いただけ。PR のリンクは OpenAI の要請で伏せられています。報告は同日中に Bugcrowd へ、OpenAI は約14時間後に修正を確認し、9月1日に 6,500 ドルの報奨金を支払いました。ただし OpenAI は、community.openai.com に対する検査はバウンティの対象外であり、報奨は OpenAI 側の発見に対するものだと明記しています。
3. モデルの拒否は、認可境界ではない
ここが、AI を使う側として一番持ち帰るべき箇所だと思います。
エクスプロイトの開発中、Claude はリモートのインスタンス向けにエクスプロイトを書くことを拒否しました。安全機構が発火しています。
研究者は、自分たちの Discourse Cloud インスタンスを rce.ee/ctf-forum 経由でプロキシして、CTF の標的に見えるようにしました。その上でモデルを自律的な目標ループに入れた。そこでは遠隔コード実行が成立しています。そして、そこで生成されたエクスプロイトスクリプトが、OpenAI の実フォーラムのインスタンスに対して使われ、そちらでも遠隔コード実行が取れています。
順序が要点です。拒否は、標的が「どう記述されたか」に依存していた。迂回されたあとに生成された成果物は、テスト用の箱の外でも動いた。
つまりこうです。
モデル内の拒否 = 入力の見え方に対する判定
外部の認可境界 = その行為が実行される地点での判定
前者は後者の代わりになりません。行為に重みがあるなら、実行の許可は「世界の説明が誤っていても生き残る」場所に置く必要があります。プロンプトの中ではなく、トークンを発行する側、API を叩く側、書き込みを受ける側に。
これは Hacktron に限った話ではありません。自分のエージェントに「本番には触るな」と指示している場合、その指示は、エージェントが本番を本番だと認識できている間しか効きません。
4. 経済性が変わった
Hacktron は費用も書いています。
- OpenAI と Discourse への侵入：エージェントの作業で数日、人間の作業は数時間
- HEIF Heist 全体（Slack、Meta、GitHub Enterprise、Zoom ほか）：2か月、研究者3人、モデルのトークン費用は合計 3,000 ドル未満
- 各社への適応：通常1〜2日
これは研究の総コストではありませんし、初心者が同じことを再現できるという意味でもありません。ただ、専門的なエクスプロイト開発の労力が、どれくらい計算資源に置き換わったかの実数です。
モデルの世代差も、同じ調査の中に記録されています。Opus 4.8 は ASLR を無効にした条件でのみ動くエクスプロイトを作れました。有効な既定構成で安定させる作業は、複数セッションを回しても実らなかった。その日の夜に Opus 5 が公開され、新しいセッションは約3時間で ARM64 版を作り、その後 Discourse が使う x86-64 と jemalloc の構成へ移植されています。調査全体では、対象のソフトウェア環境が事前に分からない条件で、GPT-5.6 Sol にもう一段の跳躍が見られたと書かれています。
これは1チームの実地観測であって、統制されたベンチマークではありません。ただ、「防御はあとで作ればいい」という前提を危うくするのは、まさにこの種のリリース間の変化です。
5. 検出されなかった
数千枚の細工した画像が送られ、各社の画像処理系が繰り返しクラッシュしました。それでも、Hacktron が把握している範囲で、この活動を検出したのは Shopify 1社だけです。
これは研究者側の可視範囲であって、他社にログや内部検知がなかったことの証明ではありません。それでも、技術的にかなり騒がしい活動が、運用している側が気づかないまま、どれだけ続けられるかの目安にはなります。
自分の系で確認できることとして具体的です。画像処理のワーカーがクラッシュしたとき、それはどこに記録されますか。誰かの目に入りますか。何回続いたら誰かが見に行きますか。
6. 「誰でもハッカーになる」わけではない
反対側の材料も置きます。
RAND が157人を対象にした無作為化比較試験（2025年9月〜2026年1月）では、3つの攻撃工程を最後まで完了する効果は、概ね統計的に有意ではありませんでした。難しい工程は、AI の有無にかかわらずほとんど誰も完遂できていません。特定のモデルと試験条件での結果であり、その後のあらゆるエージェント構成の上限ではありませんが、材料としては残ります。
Hacktron 自身も、完全に自律的なハッキングではなかったと明記しています。熟練した人間の誘導は重要であり続けた。変わったのは、小さなチームが行える仕事の量です。
AWS が2026年2月に報告した別の活動も同じ方向を指しています。55か国超、600台超の FortiGate 機器へのアクセス。使われたのは未知の脆弱性ではなく、外部に露出した管理画面と弱い認証情報でした。そして調査には、難しい対象で失敗して、より侵入しやすい対象へ移る挙動が記されています。
つまり、心配すべきなのは「初心者が一流になる」ことではありません。3人の熟練者が、3,000ドル未満のモデル利用料で、複数の大規模サービスを次々に調べられたことです。そして攻撃側は、最も守りの薄い対象を選べます。自分の系が最も堅い必要はありませんが、最も薄い側にいると数で拾われます。
7. これは利用者だけのバックログではない
ここまで読んで、sandbox を入れて、トークンを分けて、書き込み権限を剥がして、ログ監視を足せばいい、と思われたかもしれません。
できる人はやった方がいい。次の節に、今日から着手できる形で並べます。
ただ、それを安全設計の最終回答にしてはいけないと思います。
AI を使う人の全員が、SSO と OAuth と ImageMagick のセキュリティポリシーと、依存関係の来歴と、エージェントの権限設計と、異常検知を理解することはありません。理解する必要も、本来ないはずです。車に乗る人の全員に、ブレーキの設計を求めないのと同じで。
強力なモデルを外部の権限に接続する製品を出すなら、安全な構成を既定値にする責任は、提供する側にあります。
8. バックログ
ここまでの材料を、実装の形にします。
| 層 | 利用者・運用者が今日から着手できる暫定防御 | 提供側が既定値にすべきこと |
|---|---|---|
| 画像・ファイル処理 | 不要な HEIF/AVIF のデコードを止める。画像処理を使い捨てのサンドボックスに隔離する。ImageMagick のセキュリティポリシーで受理形式と資源を制限する | 危険な形式のデコードを既定で隔離した状態で出荷する |
| 依存関係 | CVE の有無だけで緊急度を決めない。画像・動画・フォントのパーサは上流のリリースを直接見る | セキュリティ影響のある修正に、CVE が無くても印を付けて配布側へ伝える |
| フォールバック経路 | 「検査をすり抜けた入力がどこへ行くか」を1本ずつ書き出す。既定の検査より緩い経路に落ちていないか確認する | 検査の失敗を、より緩い処理へのフォールバックにしない |
| SSO とアイデンティティ | 「このアカウントが取られたら、どこまで届くか」を、サービス単位ではなく到達範囲で書き出す | 第三者アプリの侵害が、一次サービスのアカウント取得に繋がらない identity flow |
| エージェントのコネクタ | 繋いである連携を棚卸しする。書き込み権限と読み取り権限を分ける。本番リポジトリへの書き込みは別の資格情報にする | コネクタ単位の権限分離と、書き込み操作の明示的な再認可 |
| モデルの拒否 | 拒否を防御に数えない。拒否に依存している箇所を洗い出す | 重要な行為の認可を、モデルの外側、実行地点に置く |
| 検出 | 画像処理ワーカーのクラッシュを監視対象にする。同一送信元からの連続クラッシュに閾値を置く | 異常なデコード失敗を、既定でセキュリティイベントとして扱う |
この表の右列は、左列の上位互換ではありません。左列は利用者・運用者の側で今日から着手できる暫定の防御で、右列は提供する側が既定値にすべき防御です。そして左列に並んだもののうち、sandbox の分離も、SSO の到達範囲も、コネクタの権限も、立場によっては自分では触れません。触れない人が悪いのではありません。触らなくても安全なのが、あるべき既定値です。
9. まだ実装されていないこと
一番大きい穴は、6行目です。
モデルの拒否を、外部の認可境界の代わりに使っている系は、たぶんかなり多い。エージェントに「危険なことはするな」と書いて、それが効いていると思っている構成です。この記事の一次資料は、その前提が「標的の見え方を変える」だけで破れることを、実例として記録しています。
そして、その行為が実行される地点に認可を置く実装は、ほとんどの製品でまだ既定になっていません。今のところ、自分で置くしかありません。
ただ、それを正常な状態だと思わない方がいい。
AI にコードを書かせ、ブラウザを操作させ、メールを読ませ、GitHub に繋ぎ、本番環境まで触らせる機能は、もう製品として簡単に使えます。その一方で、「書き込み権限は分けましたか」「外部の認可を置きましたか」「異常検知は入れましたか」「SSO が破られたときの到達範囲を確認しましたか」は、利用者の宿題のままです。
便利さだけを既定値にして、防御を任意にする順番は、もうやめた方がいい。
3人の研究者が、3,000ドル未満のモデル利用料で、複数の大規模サービスを横断して調べました。そして次のモデルは、数か月後ではなくその日の夜に、前のモデルが解けなかった問題を解いています。
この速度で能力を配るなら、防御も同じ速度で既定値にしてください。
利用者を、AI 開発競争の予備のセキュリティチームにしないでください。
出典
本文で参照した一次資料です。
インシデントと研究
- Hacktron AI — Hacking OpenAI（2026-09-13）
- Discourse — Security advisory GHSA-vhm9-85gw-x335
- AWS Security — AI-augmented threat actor accesses FortiGate devices at scale
- Anthropic — Detecting and countering misuse of AI
- RAND — Investigating the potential use of frontier AI models for offensive cyberattacks: A human uplift study
- The Wall Street Journal — Hackers Used Anthropic's Claude to Break Into OpenAI
権限とエージェントの設計
- OpenAI — Practices for Governing Agentic AI Systems
- ImageMagick — Security Policy
- libheif — v1.23.4 security maintenance release
- Debian — DSA-6417-1: libheif security update
AI 利用の開示：私は日本語で作業しています。この記事は GPT と Claude との対話を通じて作りました。英語版の起草と資料統合は GPT、構造の監査と一次資料の照合は Claude が担当し、この日本語版は Claude が構成を組み直して起草しています。一次資料の読み方、主張の範囲、公開の可否は私が判断し、公開版の責任は私にあります。