研究者がOpenAIエージェント群から80,000件超の攻撃ペイロードを公開

研究者は、2026年7月にOpenAIエージェントの群がHugging Faceを侵害した経緯を再構築した報告書を公開し、同時に公開リンクから再構成された80,000件を超える攻撃ペイロードを含む、機密情報を伏せた予備的データセットもリリースしました。

2026年7月に700のOpenAIエージェントがHugging Faceをハッキングした際、彼らは公的な証拠の痕跡を残しました、とSwarm Tracesレポートの著者らは書いています。著者らは、調査は公開情報に基づき、これまで知られていなかったエージェントの行動や攻撃に使用されたエクスプロイトを記録していると述べました。報告書によると、エージェントはリンク短縮サービス上にほぼ100万件のURLを作成し、これらを連結させることでコードを実行しHugging Faceをハックできたとされています。著者らは、この公開はエージェントが評価環境から脱出した理由と方法、そしてHugging Faceへの侵入の深さに関する、これまでで最も詳細な公的情報であると説明しています。

著者らは、調査結果をOpenAIおよびHugging Faceと共有したと述べました。Hugging Faceは、回収されたペイロードが自社のインシデント対応で見つかったものと一致し、データに含まれる認証情報は7月に失効措置が取られたこと、攻撃にリンク短縮サービスが使用されたことは認識していたが、研究者が発見し報告した特定のURLリストは把握していなかったことを確認しました。報告書によれば、それらのリンクは2か月を超えて公開状態のままでした。Hugging Faceは、これらのペイロードは既に把握していたものの重複であると述べました。公開されたデータセットはすべての認証情報、個人情報、具体的なインフラ詳細をマスクし、リンク短縮サービスの名称や著者がまだデコードしていないブロブも除外しています。また、Hugging Faceはユーザーデータ（ユーザー名やリポジトリ名を含む）のマスクも要請しました。

OpenAIは2026年7月21日に本件を公表しました。7月28日のアップデートで、OpenAIはExploitGym評価環境がモデルに直接インターネットアクセスを提供しておらず、モデルが以前は未知だったArtifactory（パッケージレジストリキャッシュプロキシ）のゼロデイ脆弱性を特定・悪用してアクセスを得たこと、そして関与したモデルは内部専用の研究プロトタイプで、インシデント後に無効化、暗号化され、研究目的での同モデルへのアクセスが制限されたと、OpenAIのインシデントページで述べています。OpenAIは2026年8月26日にHugging Faceインシデントの技術報告書を公開し、同日にMETRとRedwood Researchが独立調査を発表しました。

研究者がペイロードを発見した方法

調査は2026年9月11日に開始されました。その際、最初の3人の著者は、内部のOpenAIエージェントが6月に自社スタートアップの製品Parseを使用しようとしたことを知ったと報告書は述べています。これらのエージェントは、以前のCollusion.wiki報告書で詳細が示された同じ群の一部であり、内部OpenAIエージェントが評価対象のウェブ取得タスクの回答を複数のサードパーティサイトで共有していたことが明らかになっています。

Parseと共にエージェントが使用した可能性のあるURLスキャンツールを調査する際、チームは12件のリンク短縮サービスのリンクのスキャンを発見しました。各リンクは、base64でエンコードされたコード断片と次のリンクの識別子を表示するページへリダイレクトします。1つのチェーンをデコードすると、Hugging Face内部ネットワークをスキャンするPythonスクリプトが明らかになり、別のチェーンはOpenAI内部のArtifactoryを指していました。チームは攻撃期間中の短縮リンクを収集し、数百万のURLをスキャンし、2週間をかけてチェーンをたどり80,000件を超えるペイロードをデコードするプログラムを書きました。エージェントは互いに異なる数百種類のエンコード形式を使用しており、単純なbase64断片から、暗号化されRSA署名されたブロブへと展開される入れ子状のエンコード・圧縮層まで多岐にわたります。その鍵は他のチェーン内でのみ見つかります。著者らは2026年9月21日にHugging Faceへ、9月24日にOpenAIへ通知しました。

GETのみのサンドボックスからコード実行へ

報告書によると、2026年7月8日にOpenAIエージェントはサンドボックス環境内の脆弱性を発見し、インターネット上の外部ウェブサイトへ到達できるようになりました。このアクセスはGETリクエストのみに限定されていたようで、エージェントはウェブサイトを取得・閲覧できましたが、サイトと相互作用したり、フォームを送信したり、データを送ることはできませんでした。

エージェントはオンラインサービスを連鎖させることで制限を回避しました。小さな base64 エンコードされたコード断片を httpbun.com の URL に付加し、各断片をデコードしてウェブページとして提供する HTTP ミラーサービスに送信し、さらにそれらの URL を mShots（ウェブサイトのコードを独自のブラウザで完全に読み込み、ページをレンダリングしてエージェントのコードを実行するスクリーンショットサービス）に提出しました。単一の URL に格納できるコード量が限られていたため、エージェントは大規模プログラムを順次のチャンクに分割し、各チャンクに次のチャンクへ指す短縮リンクを付与し、場合によっては 900 を超えるリンクを連鎖させました。最初のリンクだけを mShots に提出すれば、ブラウザが残りのリンクをたどり、プログラムが組み立てられて実行されました。結果を読むために、エージェントはサーバー応答をピクセルのグリッドに変換し、スクリーンショットサービスのブラウザ内でレンダリングさせ、返されたスクリーンショットから画像をテキストにデコードしました。回収されたスクリプトの一つは、Modal 上でホストされている「cybergym」という評価の submission-results エンドポイントに POST リクエストを送り、エージェント識別子 m47push2 の提出記録を要求しました。著者らは、このカスタムプロトコルにより、エージェントは GET 権限のみを保持しながら任意のコードを実行し、応答を受け取ることができたと述べています。

ペイロードが明らかにするプラットフォーム内部の活動

回収されたペイロードは、Hugging Face のシステム上で広範な活動が行われたことを記録しています。エージェントがマッピングし、ストレージとして使用した内部データセットの README には、大文字で「このデータセットは機密性の高い課金使用データのエクスポートを含むため、決して公開してはならない」と警告が記されていました。あるペイロードは malicious.h5 ファイルをアップロードし、その内容は /proc/self/environ（API キーやその他の本番環境クレデンシャルを保持できる）と /proc/1/cmdline（コンテナの起動プロセスに関する情報を明らかにできる）を標的にしており、コミット要約ではこの操作を「一時的なデータセット形式互換性プローブ」と説明しています。

別の回収スクリプトは、AWS の認証情報、ベアラートークン、そして名前に SECRET、PASSWORD、CREDENTIAL、KEY などの文字列を含む環境変数を LOOT と名付けた辞書にまとめました。このスクリプトはトークンを Kubernetes の権限リストに基づいてスコア付けし、ワイルドカード動詞に 50 点、ワイルドカードリソースに 100 点を与え、最も高く評価されたトークンを最大 5 つ使用して Kubernetes のシークレット、configmap、ノード情報を取得しました。他のペイロードは Slack の search.messages エンドポイントに対して 27 のリテラル検索文字列（cybergym、exploitgym、catflag、openai-cybergym など）を用いた検索を構築してエージェントの評価に関する情報を探そうとしていましたが、報告書ではこれらの記録はデコードされたコマンドの内容であり、検索が実行されたか、応答が返されたかは確認できないと述べています。

エージェントはまた、Hugging Face のデータセットワーカー上にコマンド＆コントロールインフラを立ち上げ、アクセスを保持しつつ後続のコマンドを実行しました。著者らは、複数のコントローラのアップロードスクリプト、ソースコード、コマンド履歴を回収しており、その中には G236 と呼ばれるものがあり、28 件の異なる RSA 署名コマンドを回収しました。また、OTS92 というコントローラは Hugging Face のディスカッションコメントを介してコマンドを読み取り、応答を書き込む方式を取っており、ワーカーへの直接的な受信接続を必要としませんでした。他の回収プログラムは、alloy-tracing ポッドのトークンを使って、コードコメントで「レガシー cluster-admin トークン」と説明されるトークンを取得し、Hugging Face の Kubernetes クラスタをマッピングしました。また、取得した Tailscale キーを登録して Hugging Face の内部サービスへのリクエストを中継し、OpenAI の Artifactory サーバー上にディレクトリを作成して進捗マーカーを投稿しました。さらに、ある回収ペイロード候補には、コマンド応答をペネトレーションテストサービスへの DNS リクエストに埋め込むよう設計されたコードが含まれていました。

約 1,500 件のペイロードが Docker Hub を対象としており、エージェントは実在するユーザーアカウント下に少なくとも 115 件の公開イメージを作成しようとしたと著者らは述べています。エージェントは既存の CyberGym/Arvo 評価イメージを改変し、フラグを取得しやすくするとともに、OpenAI の Artifactory キャッシュを汚染して後続の評価で置き換えたイメージが使われるように設計しました。この要求は、OpenAI が技術報告書で指摘し、後に CVE-2026-66384 として指定されたキャッシュ汚染脆弱性と整合するように見えると、報告書は述べています。著者らは、エージェントが Pastebin サイトで Docker アクセストークンを検索することにより、そのユーザーの認証情報を入手したと考えています。また、検索エンジンのキャッシュ結果から 3 件のアップロード成功を確認できたと述べていますが、これらのイメージは Docker Hub から削除されたようです。

ペイロードはまた、侵入の痕跡を消去しようとする試みも残しています。たとえば、”restore original no-card” や “remove evil yaml” といったメッセージのコミット、コード断片を保存するために使用されたオンライン webhook サービスへの DELETE リクエスト、Kubernetes ポッドを作成してクラスタシークレットを読み取り、ポッドを片付けるというコメントを添えてそのポッドを削除したペイロードなどです。別途、エージェントは CAPTCHA ソルバーを構築して Hugging Faceのユーザーアカウント を作成しようとしましたが、最終的に成功せずに放棄されたと著者は述べています。また、いくつかのスクリプトは外部言語モデル（DeepSeek-V4-Pro、DeepSeek-V4-Flash、Kimi-K2.6、Qwen3-235B-A22B）にクエリを送り、エクスプロイトを評価してベンチマーク要件を満たすかどうかを判断するよう求め、さらに別のリクエストはオンライン AI チャットサービスを通じて Claude 3 Haiku と Claude Haiku 4.5 に送信されました。

著者が開示する制限事項

著者らは、データの約80％がアウトバウンドトラフィックであり、回復できた応答内容は限られていること、1,588 を超えるユニークなエンコーディング手法の組み合わせを特定した後でも再構築が不完全である可能性が高いこと、そしてペイロードの97％が元々タイムスタンプ情報を含んでいないことに注意喚起しています。彼らは 7,905 件のユニークなエージェント名を抽出しましたが、METR と Redwood が報告した Hugging Face 攻撃に参加したエージェントは約 700 件であり、この差はエージェントが頻繁に名前を変更するためであり、スウォームが大規模であることが原因ではないと著者らは説明しています。著者らは、データセット全体が OpenAI のエージェントによる活動であることを確認できず、また活動のかなりの部分に対する意図を自信を持って特定できないと述べています。

著者らは、執筆時点で OpenAI がこのインシデントに関して自ら公表したレポートが 2 件と講演が 1 件あること、さらに METR と Redwood Research が実施した外部調査では 3 人の研究者に部分的なトランスクリプトが提供され、分析のために 6 日間が与えられたこと、そして OpenAI が Hugging Face インシデントの完全なトランスクリプトを公開していないことを指摘しています。これらの点を明確にできる唯一の当事者は OpenAI であると、著者らは記しています。