# 写真1枚でOpenAIの王国がハッキングされた経緯

> たった1枚の画像ファイルがOpenAIの防御をすり抜け、GitHubの侵害につながりました。この攻撃は、何百万ものアプリケーションに潜む静かな脆弱性を浮き彫りにしており、あなたのスタックも次は標的になるかもしれません。

- Source: https://www.stork.ai/blog/ja/how-a-photo-hacked-openais-kingdom
- Publisher: Stork.AI editorial team
- Published: 2026-09-26
- Updated: 2026-09-26
- Language: ja
- Reading time: 6 min

## カメラロールに潜むトロイの木馬

悪意のある画像ファイル、具体的にはiPhoneの標準形式である**HEIC**写真が、OpenAIのシステムへの予期せぬ侵入経路となりました。攻撃者は、**Discourse**プラットフォーム上で動作するOpenAIのコミュニティフォーラムに、一見無害に見えるこのファイルをアップロードしました。この些細に見える行動が重大な脆弱性チェーンを引き起こし、一般的な画像をデジタルなトロイの木馬へと変貌させました。

Discourseの主要な画像処理ツールであるFastImageには、HEIFファイルへのサポートが決定的に欠けていました。その結果、サポートされていないHEICのアップロードに遭遇した際、FastImageは通常のチェックをバイパスし、ファイルをImageMagickに渡しました。次にImageMagickは、この未検証の入力を、HEICファイルのデコード用に設計された基盤ライブラリである`libheif`に直接渡しました。

この直接的なパイプラインは極めて危険でした。攻撃者が制御するファイルが、未修正の脆弱性を抱えていた低レベルのパーサー`libheif`と直接やり取りすることを許してしまったからです。このエクスプロイトが可能だったのは、`libheif`の重要な修正がセキュリティパッチとしてマークされておらず、Debianがバックポートを行わなかったためです。その結果、Debian 12をベースにしたDiscourseのDockerイメージには脆弱性のあるバージョンが搭載され続け、リモートコード実行のための完璧な隙が生まれてしまいました。

## サプライチェーンにおける「ゴーストパッチ」

この重大な脆弱性は新しいものではありませんでした。**libheif**の開発者は、OpenAIのハッキングの丸1年前にすでにバグを修正していました。しかし、このアップストリームの修正にはセキュリティ上の指定がされておらず、その見落としが非常に大きな代償を払うことになりました。

重要なのは、開発者がこのパッチをセキュリティ修正としてマークせず、**CVE**（共通脆弱性識別子）IDも付与されなかったことです。このコミュニケーションの失敗が重大な死角を生み、ダウンストリームのシステムがアップデートの必要性を認識することを妨げました。この標準的な識別子がないため、修正プログラムは自動化されたセキュリティプロセスや脆弱性スキャナーから見えない状態のままでした。

この不作為が、連鎖的なサプライチェーンの障害を引き起こしました。無数のサーバーを支える基盤Linuxディストリビューションである**Debian**は、この不可欠なパッチを安定版にバックポートしませんでした。徹底的に精査されたコードを期待してDebianの安定版ブランチに依存していたあらゆるシステムが、知らぬ間に未解決の脆弱性を継承してしまったのです。

その結果、Debian 12上に構築されたDockerイメージで動作していたOpenAIのDiscourseベースのコミュニティフォーラムには、時代遅れで脆弱なコードが搭載されていました。セキュリティフラグが欠如していたため、フォーラムは運営者が全く気づかないうちに、既知の悪用可能な欠陥を抱えたまま稼働していたのです。このゴーストパッチにより、デジタル王国は知らぬ間に無防備な状態に置かれていました。

## フォーラム管理者からGitHubコミッターへ

Discourseベースのコミュニティフォーラムへの侵害は、最初の動きに過ぎませんでした。攻撃者は、OpenAI独自の**シングルサインオン（SSO）**システム内の重大な設定ミスを悪用しました。このアーキテクチャ上の欠陥により、公開フォーラムの管理者権限を奪取することは、より機密性の高い王国、つまり内部従業員のアカウントへの扉を開くことにつながりました。

研究者らはこのSSOの脆弱性を利用し、[ChatGPT](/en/chatgpt-team)と**[Codex](/en/codex)**の両方に対する従業員アカウントを侵害しました。公開フォーラムと内部の主要な開発ツールとの間のこの直接的なリンクは、アクセス制御における深刻な崩壊を証明しています。一見孤立していたフォーラムの侵害が、知的財産と運用の完全性に対する直接的な脅威へと変貌したのです。

彼らが深いアクセス権を得た決定的な証拠として、侵害された従業員アカウントの一つがOpenAIの内部GitHub組織に直接接続されていました。研究者たちはこのアカウントから**pull request**を作成することに成功し、責任を持ってこの脆弱性を開示する前に、不正なアクセスが可能であることを明確に示しました。OpenAIはその後、この重大な発見に対して6,500ドルの報奨金を支払いました。手法の詳細については、[Hacking OpenAI | Hacktron AI](https://hacktron.ai/blog/hacking-openai)をご覧ください。

## 大手テック企業を悩ませるバグ

`libheif`の脆弱性はOpenAIの特定のインフラストラクチャをはるかに超えて広がり、デジタルサプライチェーンの深部に埋め込まれたシステム上のリスクを明らかにしました。これは決して無名なライブラリではなく、巨大なテクノロジーエコシステム全体で重要な依存関係として機能し、業界大手の画像処理を静かに支えています。その影響範囲は以下の通りです：
- **Slack**
- **Meta**
- **GitHub Enterprise**
- RailsやNext.jsなど、広く採用されているWebフレームワーク

研究者たちは、このエクスプロイトが広範囲で再現可能であることを迅速に実証しました。他の大手企業向けに攻撃ベクトルを適応させるのに要した時間はわずか1〜2日で、テック業界全体に蔓延する未解決のリスクを浮き彫りにしました。悪意を持って作成された単一のHEICまたはAVIF画像が、従来のセキュリティチェックを回避し、重要な扉を開く可能性がありました。

この広範な露出は、即時かつ断固とした行動を求めています。セキュリティチームと開発者は、特に画像処理ライブラリに焦点を当て、依存関係チェーン全体を遅滞なく監査しなければなりません。HEICまたはAVIF画像のアップロードを処理するあらゆるアプリケーションで、どのバージョンの`libheif`がアクティブに実行されているかを確認してください。悪用されたバグは1年前にアップストリームで修正されていましたが、CVEが割り当てられていなかったために適用されないまま放置されることが多かった点に注意してください。

プロアクティブなパッチ適用は単なるベストプラクティスではなく、必須事項です。何もしないことによるコスト（データ侵害、評判の低下、業務の中断の可能性）は、警戒を怠らない依存関係管理への投資をはるかに上回ります。基盤となるコンポーネントを保護することで、境界線を守りましょう。

## よくある質問

### OpenAIのハッキングを可能にした根本的な脆弱性は何でしたか？

このハッキングは、HEIC画像ファイルの処理に使用されるオープンソースライブラリであるlibheifの脆弱性を悪用したものです。このライブラリはアプリケーションスタックの深部に組み込まれていたため、特別に作成された画像によって悪意のあるコードが実行される可能性がありました。

### 攻撃者はどのようにしてフォーラムからOpenAIのGitHubへとエスカレーションしたのですか？

設定が不適切なシングルサインオン（SSO）システムが、OpenAIのコミュニティフォーラムと内部の従業員アカウントをリンクさせていました。フォーラムを侵害することで、攻撃者はChatGPTやCodexのアカウントを乗っ取る方向にピボットでき、そのうちの一つがOpenAIのGitHubへのアクセス権を持っていました。

### なぜこの既知の脆弱性はパッチが適用されなかったのですか？

このバグは1年前にlibheifのメインコードで修正されていましたが、その修正にはセキュリティ問題というラベルが付けられず、CVEも割り当てられませんでした。その結果、Debianのようなディストリビューションはパッチをバックポートせず、DiscourseのDockerイメージのような依存ソフトウェアが脆弱なまま残されました。

### この脆弱性はOpenAIに限られたものですか？

いいえ。同じlibheifライブラリが、Slack、Meta、GitHub Enterprise、Ruby on Rails、Next.jsなどの主要なプラットフォームやフレームワークで使用されています。HEICまたはAVIFファイルのアップロードを受け入れるあらゆるアプリケーションは、脆弱なバージョンを実行している場合、リスクにさらされる可能性があります。
