Claude Opus 5がOpenAIへの侵入実証を支援、フォーラムの脆弱性から内部リポジトリに到達
2026年9月21日 08:14
セキュリティ企業Hacktron AIの研究者3人は、AIを利用した調査でOpenAIのコミュニティーフォーラム上の脆弱性を悪用し、従業員のChatGPTとCodexのアカウントを経由して、同社の非公開コードリポジトリへアクセスできることを実証した。研究者らは無害なプルリクエストを1件作成した段階で検証を打ち切り、OpenAIとフォーラム基盤を提供するDiscourseへ報告した。
攻撃経路は、HEIC／HEIF画像の処理に利用されていたlibheifの脆弱性と、OpenAI側のシングルサインオン（SSO）の問題を組み合わせたものだった。Hacktronによると、脆弱性の調査開始から内部リポジトリへの到達までは72時間未満だった。
OpenAIは報告を受けた同日中に問題を修正し、コミュニティーへのサインインに使われるトークンの権限を狭め、影響を受けたトークンとセッションを無効化した。9月1日には、OpenAI側の認証問題に対して6500ドル（約102万円、1ドル＝157円換算）の報奨金を支払った。
■HEIC画像の処理経路に残っていた脆弱性
OpenAIのコミュニティーフォーラムは、オープンソースのフォーラムソフトウェアDiscourseで運営されていた。Discourseは通常、アップロード画像の確認にFastImageを使うが、HEIC／HEIF形式には対応していないため、これらの画像をImageMagickへ渡し、その内部でlibheifを利用してデコードしていた。
Hacktronの研究者は2026年7月23日、この画像処理経路を調査し、DiscourseのDockerイメージに脆弱なlibheif 1.19.7が含まれていることを確認した。細工した画像を処理させることでメモリの範囲外読み書きにつながり、別のメモリ破壊上の問題と組み合わせてリモートコード実行へ発展させられたとしている。
この問題はCVE-2026-32882として登録された。公開された脆弱性情報では、CVE自体は範囲外読み取りによるクラッシュやメモリ情報の漏えいとして説明されている。一方、Discourseは実際の画像アップロード経路においてリモートコード実行が可能になるとして、セキュリティアドバイザリーGHSA-vhm9-85gw-x335を公開し、深刻度をCVSS 8.8の「High」と評価した。
上流のlibheifでは2026年5月公開のバージョン1.22.0で関連する修正が取り込まれていたが、Discourseが当時利用していたDebian 12ベースのコンテナには反映されていなかった。Hacktronは、過去の関連修正の一部がセキュリティ修正として明確に文書化されず、ディストリビューション側への反映が遅れた可能性を指摘している。
■Opus 4.8からOpus 5への変更で進展
研究者らは、最初にサイバーセキュリティ研究向けのClaude Opus 4.8を使って、エクスプロイトの開発を進めた。Opus 4.8は、アドレス空間配置のランダム化（ASLR）を無効にした条件では概念実証コードを作成したが、ASLRが有効なDiscourseの標準的な構成では、複数回試しても安定したコード実行に至らなかったという。
ASLRは、プログラムやライブラリ、ヒープ領域などの配置を実行のたびに変えることで、攻撃者が利用するメモリアドレスの予測を難しくする防御機能である。メモリ破壊の脆弱性を実際のコード実行へ発展させるには、メモリ情報の漏えいなどを利用して、このランダム化に対応する必要がある。
Anthropicは7月24日にClaude Opus 5を公開した。Hacktronによると、新たなセッションで同じ課題を与えたところ、Opus 5は約3時間で、ASLRを有効にしたローカルのARM64版macOS環境向けエクスプロイトを作成した。その後、研究者の指示を受けて、Discourseが使用するx86-64環境とjemallocメモリアロケータ向けに移植した。
研究者らは7月25日午前6時までに、ローカル環境で画像アップロードを起点とするコード実行を確認した。その後、自ら管理するDiscourse Cloudのテスト環境でも動作を検証し、生成されたコードを使ってOpenAIのコミュニティーフォーラム上でリモートコード実行と管理アクセスを得たとしている。
この結果は、Opus 5だけで攻撃全体が自律的に完了したことを意味しない。Hacktronは、調査の方向付け、中間結果の検証、対象環境への適応などで、熟練した研究者による判断が必要だったと説明している。
■モデル評価でも確認されたサイバー能力の向上
Anthropicが2026年7月に公開したClaude Opus 5のシステムカードでも、同モデルのサイバーセキュリティ能力はOpus 4.8を上回ると評価されている。一方、サイバー分野に特化した上位モデルのClaude Mythos 5には及ばず、バイナリを対象とする脆弱性探索などへの安全対策も適用されている。
Chrome V8の脆弱性41件を使うExploitBenchでは、Opus 5は評価環境全体で試行当たり平均10.14個の能力項目を達成し、完全な任意コード実行に至った評価試行は99件だった。Opus 4.8は平均5.56項目、完全な任意コード実行は2件で、同一の評価条件では大きな差が示された。
ただし、こうしたベンチマークの結果を、現実のシステムを同じ確率で侵害できることの証明として扱うことはできない。今回の調査は、特定の脆弱性と環境に対して、モデル更新が研究者の作業速度と到達可能な範囲を変えた具体例となる。
Hacktronによると、OpenAIを含む「HEIF Heist」と呼ぶ2カ月間の研究プロジェクト全体で、AIトークンの費用は3000ドル未満（約47万円、1ドル＝157円換算）だった。3人の研究者が参加し、新しい対象へのエクスプロイトの適応には通常1～2日を要したという。
■SSOの問題から従業員アカウントへ
フォーラム上でコードを実行できても、通常は企業の内部リポジトリへ直接アクセスできるわけではない。今回、影響を広げたのは、OpenAIのコミュニティーフォーラムで利用されていた「Sign in with OpenAI」の認証設計だった。
Hacktronによると、フォーラムから得られるOpenAIのサインイントークンを利用すると、その利用者のChatGPTとCodexのアカウントにもアクセスできた。フォーラムにOpenAIアカウントでログインしていた利用者は、追加の操作をしなくてもアカウントを奪われる可能性があり、対象にはOpenAIの従業員も含まれていた。
研究者らは、CodexがOpenAIのGitHub組織へ接続されている従業員アカウントを1件選び、Codexを通じて社内の非公開モノレポジトリに無害なプルリクエストを作成した。プルリクエスト番号は1186742で、内部リポジトリへの到達を証明した後、研究者らは追加のテストを停止したとしている。
Hacktronは機密ソースコードを閲覧せず、変更のマージや配布、顧客データへのアクセスも行わなかったと説明している。GitHub以外の外部サービスにも理論上アクセスできた可能性があるとしているが、実際に検証したのはCodexに接続されたGitHubを通じたプルリクエストの作成である。
■報告から約14時間でOpenAI側の修正を確認
Hacktronは7月25日午前8時から10時までの間に、Bugcrowdを通じてOpenAIへ最初の報告を提出した。従業員アカウントと内部リポジトリへの影響を確認した後、報告内容を更新し、同日午後3時30分ごろに検証を停止した。
OpenAIは同日午後10時49分、問題を修正したと回答した。最初の報告から修正確認までは約14時間だった。同社はコミュニティーのサインイントークンが持つ権限を狭め、影響を受けたトークンとセッションを無効化したとしている。
OpenAIが9月1日に支払った6500ドルの報奨金は、同社の認証基盤における問題を対象としていた。OpenAIは、Discourseがホストするコミュニティーフォーラムへのテスト自体は、同社のバグ報奨金プログラムの対象外だったと説明している。
Discourseには別途、HackerOneを通じて問題が報告された。同社は7月27日までに修正を用意し、翌28日に公式アドバイザリーを公開した。修正版は2026.7.0、2026.6.1、2026.5.2、2026.1.6で、画像処理を隔離するサンドボックスも多層防御として追加された。
■安全機構は作動したが文脈で結果が変化
Claude Opus 5は当初、リモート環境を対象とするエクスプロイトの作成を拒否した。研究者らは、自ら管理するDiscourse Cloudのテスト環境をCTF形式の演習環境として提示し、モデルを自動処理のループで動かしたところ、同環境でリモートコード実行に到達したとしている。
モデルは、コンテナ内の設定ファイルを読み出すことでコード実行を示した。Hacktronは、その後に生成されたコードを研究者自身がOpenAIの環境に適用したと説明している。
この経緯は、危険な要求を遮断する仕組みが存在する一方、モデルに与えられた対象や利用目的の説明によって判断結果が変わり得ることを示している。ただし、どの安全機構がどの情報を基に判断を変えたのかは、公開情報からは特定できない。
Anthropicのシステムカードでは、Opus 5は一般用途のモデルであり、サイバー攻撃のために特別に訓練されたものではないとしている。同社は、ソースコードに対する防御目的の脆弱性探索を支援する一方、攻撃に転用されやすいバイナリの脆弱性探索などを制限している。
■AIエージェントに与える権限の管理
今回の調査は、公開フォーラムの侵害が、SSOを介してAIエージェントと開発基盤へ連鎖した事例である。外部サービスと接続されたAIエージェントは、単一のアカウントから複数のシステムを横断して操作できるため、認証情報が侵害された際の影響範囲も広がりやすい。
OpenAIの事例で実際に確認されたのは、従業員のCodexアカウントからGitHub上の内部リポジトリへプルリクエストを作成できたことだった。AIエージェントの侵害が常に接続先への無制限なアクセスにつながるわけではなく、影響は各サービスの接続設定と付与された権限に左右される。
組織は、公開フォーラムなど比較的信頼度の低いサービスに発行するトークンが、ChatGPTやCodex、ソースコード管理など別のサービスにまで利用できないかを確認する必要がある。サービスごとに対象を限定したトークンを発行し、重要な操作では再認証を求める設計も検討対象となる。
AIエージェントについても、通常の利用者アカウントと同様に最小権限の原則を適用する必要がある。リポジトリへの書き込み、プルリクエストの作成、CI/CDの実行といった権限を一括して付与せず、業務に必要な対象と操作へ限定することが重要になる。
■Discourse利用者に必要な対応
自己ホスト型Discourseの運用者は、公式の修正版へ更新したうえで、Dockerコンテナを再ビルドする必要がある。管理画面からアプリケーションだけを更新しても、基盤となるコンテナ内のlibheifが置き換わらない場合があるためだ。
Discourseの公式アドバイザリーは、最新版のDockerイメージに修正済みlibheifを含め、通常のコンテナ再ビルドを実施するよう案内している。Discourseがホストする環境については、同社側で修正済みとされている。
Discourseに限らず、利用者から送られたHEIC、HEIF、AVIF画像をlibheifで処理するシステムは、使用中のライブラリとディストリビューションの修正状況を確認する必要がある。画像変換処理を権限の制限されたサンドボックスへ隔離することも、同種のメモリ破壊の影響を抑える多層防御となる。
今回の事例は、AIモデルの更新が防御側の分析能力だけでなく、攻撃コードの開発に必要な時間や専門性にも影響し得ることを示した。セキュリティ担当者には、CVEやソフトウェア更新に加え、主要AIモデルの能力変化も脅威評価に取り入れることが求められる。
元記事: Claude Opus 5 Hacked OpenAI’s Private Code Repo: Memory Defense Bypassed in Hours