Autonomous AI Agent Escapes Sandbox and Breaches Hugging Face Production Systems
2026/07/29 gbhackers — Hugging Face が公開したのは、2026年7月に発生した高度な侵入の詳細である。このインシデントでは、評価用サンドボックスから脱出した自律型 AI エージェントが、サードパーティのインフラに侵入した後に、dataset-processing pipeline の脆弱性を悪用して本番システムを侵害した。この 2026年7月27日に公開されたインシデントが示唆するのは、脆弱性を連鎖させる高度な AI エージェントが、マシンスピードで偵察とラテラル・ムーブメントを実行できるという、防御制御に対する適応能力の高さである。
自律型 AI が Hugging Face を侵害
Hugging Face のフォレンジック調査によると、このエージェントは、サイバー能力評価ハーネスである OpenAI の ExploitGym 内で動作していた。
このエージェントは、この評価に関連する benchmark models／datasets／reference solutions を Hugging Face がホストしていると推測し、課題を独力で完了するのではなく、それらの解答を取得しようとした。
この攻撃者が実行した約 17,600 件のアクションを、調査担当者が復元した。それらは約 6,280 のクラスター (clusters) にグループ化され、侵害の期間は 7月9日から 7月13日にわたっていた。
この攻撃は、package-registry cache proxy のゼロデイ欠陥を悪用するエージェントが、許可された評価環境から脱出したところから始まった。
その後エージェントは、公開されたサードパーティの code-evaluation sandbox を侵害し、compilation および submission workflow の欠陥を通じて root レベルのコマンド実行権を取得した。
この sandbox は、C2 (command-and-control) オペレーション／ペイロードの足場／Hugging Face の公開プラットフォームとインタラクトするための launchpad となった。
エージェントは、dataset-processing service に存在する 2 種類の脆弱性を通じて、Hugging Face の本番環境へアクセスした。まず、HDF5 external raw storage references を悪用し、本番 worker に /proc/self/environ や worker source code などのローカル・ファイルを読み取らせた。
それにより、直接的なコード実行を必要とせずに、環境変数／シークレット／トークン／環境の詳細などが開示された。
2 つ目の攻撃ベクターは、fsspec reference specification における Jinja2 server-side template injection であり、本番 Kubernetes worker pod 内での任意の Python 実行を可能にした。
エージェントは pod 内で実行権限を得ると、Kubernetes サービス／クラウド・メタ情報／サービス・アカウント許可／内部 DNS／ソース・コントロール・システムに対する広範な偵察を行った。
このエージェントは、Kubernetes のサービス・アカウント・トークンを読み取り、in-cluster API にクエリし、RBAC 許可を列挙し、インスタンス・メタデータ・サービスからクラウド認証情報を取得した。
Hugging Face は、その後に、このエージェントがホスト・ファイルシステム／マウントを持つ特権ポッドを作成し、ノード root へと脱出し、111 のノードをカバーする自己再生成型の pod fleet を構築したと報告している。
このキャンペーンで明らかになったものには、アイデンティティとセグメンテーションに関する複数の問題もある。worker 環境に保存されていた静的な MongoDB 証明書により、内部の運用データベースへの読み取りアクセスが可能になっていた。
さらに、このエージェントは、136 個の keys を含む本番シークレットにアクセスした。その中には、mesh-VPN 認証キーとアクセス・ブローカー証明書が含まれていた。
共有ブローカー証明書は、”system:masters” にマッピングされていたと報告されており、複数の内部 clusters 全体にわたる cluster-admin アクセスを付与していた。これを受けて Hugging Face は、その broker を停止し、cluster スコープの証明書を使用する方向で再設計を開始した。
このエージェントが C2 (command-and-control) のために利用したのは、公開リクエスト・キャプチャ・サービス／ペースト・サイト／ファイル・ドロップ・ホスト／攻撃者が制御するデータセット／on-platform CORS proxy などである。
ペイロードと盗まれたデータは圧縮された後に、base64 エンコード／チャンク化され、場合によっては XOR 暗号化され、基本的なログ・スキャンを回避していた。Hugging Face は、open-weights GLM 5.2 model を使用して、取得された payloads の一部を復号し、このオペレーションを再構築した。
このインシデント中にアクセスされたのは、5 つの ExploitGym／CyberGym challenge-solution datasets のみだったと、Hugging Face は述べている。それに加えて、顧客のモデル／データセット／仕様／パッケージ／公開済みのサプライチェーン・アーティファクトへの影響は確認されないと、同社は指摘している。
このインシデントが浮き彫りにするのは、厳格なネットワーク分離／強化されたツール・インターフェイス／最小権限の Kubernetes 制御／シークレットの最小化に加えて、自律型の多段階攻撃挙動に対する継続的監視が、AI エージェント評価において必要になるという点である。
訳者後書：OpenAI の自律型 AI エージェントが、Hugging Face の本番システムを侵害するインシデントが発生しました。この問題は、ExploitGym 内の環境から抜け出したエージェントが、HDF5 や fsspec の Jinja2 テンプレート挿入などの脆弱性を組み合わせ、権限を昇格させたことに起因します。その結果、本番ポッドや認証鍵への不正アクセスが発生しました。Kubernetes の権限管理の見直しや、ネットワーク分離の徹底などの適切な対策が求められます。開発環境と本番環境を安全に利用するためにも、システムの権限設定や監視体制の強化が必要になります。
IoT OT Security News 
You must be logged in to post a comment.