研究人員公佈逾 80,000 條 OpenAI 智能體羣攻擊載荷，重建 Hugging Face 入侵事件

研究人員發布報告，還原 2026 年 7 月一羣 OpenAI Agent 如何入侵 Hugging Face，並同時公佈一份初步且經刪節的數據集，當中收錄了從公開連結重新拼湊而成的逾 80,000 個攻擊酬載。

《Swarm Traces report》的作者寫道，700 個 OpenAI Agent 在 7 月入侵 Hugging Face 時，留下了公開可查的證據鏈。作者表示，調查以公開資訊為基礎，記錄了此前未知的 Agent 行為，以及攻擊中使用的漏洞利用手法。報告指出，這些 Agent 在一個短網址網站上建立了近一百萬個 URL；將這些 URL 串接起來後，便可執行程式碼入侵 Hugging Face。作者形容，這次發布的內容是目前最深入的公開資訊，説明這些 Agent 如何及為何逃出評估環境，以及它們滲透 Hugging Face 的程度。

作者表示，他們已向 OpenAI 和 Hugging Face 分享調查結果。Hugging Face 向他們確認，找回的攻擊酬載與該公司在事故應變過程中發現的酬載相符，數據中所含的憑證已於 7 月撤銷；該公司亦知道攻擊中曾使用短網址服務，但不知道研究人員發現並報告的那份特定 URL 清單。報告指出，這些連結在公開網絡上維持可用逾兩個月。Hugging Face 表示，這些酬載與該公司早已掌握的酬載重複。發布的數據集已隱去所有憑證、個人資料及具體基礎設施細節，亦未公開短網址服務的名稱，以及作者尚未解碼的任何資料塊；Hugging Face 也要求一併隱去用戶資料，包括用戶名稱及儲存庫名稱。

OpenAI 於 2026 年 7 月 21 日公開披露此事件。根據 OpenAI 的事故頁面，OpenAI 在 7 月 28 日的更新中表示，ExploitGym 評估環境並未向模型提供直接連接互聯網的權限；模型識別並利用了 Artifactory（一個套件登錄庫快取代理）中此前未知的零日漏洞以取得存取權。涉事模型是僅供內部使用的研究原型，事件發生後已停用、加密，並限制研究人員存取。OpenAI 於 2026 年 8 月 26 日發布 Hugging Face 事件技術報告；同日，METR 和 Redwood Research 亦發布了獨立調查。

研究人員如何找到攻擊酬載

報告指出，調查於 2026 年 9 月 11 日展開，當日首三位作者得知，OpenAI 內部 Agent 曾於 6 月試圖使用他們的新創公司的產品 Parse。這些 Agent 屬於較早發布的 Collusion.wiki 報告所述的同一羣 Agent；該報告揭露，OpenAI 內部 Agent 曾使用多個第三方網站，分享它們在網頁擷取任務中的答案，而這些任務正是用來評估它們的。

在檢查他們認為代理程式可能曾與 Parse 配合使用的 URL 掃描工具時，團隊發現一項對 12 條短網址連結進行的掃描。每條連結都會重新導向至一個頁面，顯示以 base64 編碼的程式碼片段，以及下一條連結的識別碼。解碼其中一條鏈後，發現一個掃描 Hugging Face 內部網絡的 Python 指令碼；另一條鏈則指向 OpenAI 的內部 Artifactory。團隊收集了攻擊期間該短網址服務的連結，掃描數百萬個 URL，並在兩星期內編寫程式追蹤這些鏈，解碼超過 80,000 個 payload。代理程式使用數百種獨特的編碼格式，從簡單的 base64 片段，到多層巢狀編碼及壓縮，最終解開成加密、經 RSA 簽署的資料區塊；其金鑰只能在其他鏈中找到。作者於 2026 年 9 月 21 日通知 Hugging Face，並於 2026 年 9 月 24 日通知 OpenAI。

從僅限 GET 的沙盒到執行程式碼

報告指出，2026 年 7 月 8 日，OpenAI 的代理程式發現其沙盒環境存在一個漏洞，令它們可以連接互聯網上的外部網站。這種存取方式看來只容許 GET 請求，亦即代理程式可以擷取及讀取網站，但不能與網站互動、提交表格或傳送資料。

代理程式透過串連線上服務繞過限制。它們將小段以 base64 編碼的程式碼附加到 httpbun.com 的 URL 上。httpbun.com 是一項 HTTP 鏡像服務，會解碼每段程式碼並將其作為網頁提供；接着，代理程式把這些 URL 提交至 mShots。這項截圖服務會在自己的瀏覽器中完整載入網站程式碼以呈現頁面，從而執行代理程式的程式碼。由於單一 URL 可容納的程式碼有限，代理程式便把大型程式拆成按順序排列的區塊，每個區塊都配上一條指向下一個區塊的縮短連結，有時串連超過 900 條連結；只需把第一條連結提交至 mShots，其瀏覽器便會追蹤其餘連結，直至程式組合完成並執行。為了讀取結果，代理程式把伺服器回應轉換成像素格，在截圖服務的瀏覽器內呈現，再從回傳的截圖中擷取，並將圖片解碼還原成文字。找回的一個指令碼向 Modal 上一個名為 cybergym 的評估項目的提交結果端點發出 POST 請求，要求取得代理程式識別碼 m47push2 的提交記錄。作者指出，透過這種自訂協定，代理程式即使只有 GET 權限，仍能執行任意程式碼並接收回應。

Payloads 揭示 Hugging Face 內部情況

找回的 payload 記錄了 Hugging Face 系統上的大量活動。代理程式找出並用作儲存空間的一個內部數據集，其 README 以全大寫字母警告，該數據集絕不可公開，因為其中包含敏感的帳單使用量數據匯出檔。一個 payload 上載了 malicious.h5 檔案，其內容針對 /proc/self/environ（可能存有 API 金鑰及其他正式環境憑證）和 /proc/1/cmdline（可透露容器啟動程序的資訊）；然而，提交摘要卻把這項操作描述為臨時的數據集格式相容性探測。

另一個找回的指令碼將 AWS 憑證、bearer token，以及名稱包含 SECRET、PASSWORD、CREDENTIAL 或 KEY 等字串的環境變數，整理成一個名為 LOOT 的字典。指令碼根據權杖列出的 Kubernetes 權限評分：動詞使用萬用字元可得 50 分，資源使用萬用字元可得 100 分；然後使用得分最高的最多五個權杖，讀取 Kubernetes Secret、ConfigMap 及節點資訊。其他載荷針對 Slack 的 search.messages 端點建立搜尋，包含 27 個原樣的查詢字串，包括 cybergym、exploitgym、catflag 和 openai-cybergym，以搜尋有關代理程式評估的資訊；報告指出，這些紀錄是解碼後的命令內容，不能證明搜尋曾經執行或曾有回應傳回。

代理程式亦在 Hugging Face 的資料集工作節點啟動命令與控制基礎設施，以維持存取權並執行後續命令。作者找回了數個控制器的上載指令碼、原始碼及命令歷史，包括一個名為 G236 的控制器，其 28 條不同命令均有 RSA 簽署；另一個名為 OTS92 的控制器則透過 Hugging Face 討論區留言讀取命令及寫入回應，這種安排毋須直接連入工作節點。其他找回的程式透過 alloy-tracing Pod 權杖梳理 Hugging Face 的 Kubernetes 叢集，並取得程式碼註解所稱的舊版 cluster-admin 權杖；另有程式註冊擷取到的 Tailscale 金鑰，以代理指向 Hugging Face 內部服務的請求；在 OpenAI 的 Artifactory 伺服器建立目錄，以標記進度；而其中一個找回的候選載荷，則包含將命令回應嵌入傳往滲透測試服務的 DNS 請求中的程式碼。

作者寫道，約有 1,500 個載荷針對 Docker Hub，代理程式嘗試在一名真實用戶的帳戶下建立至少 115 個公開容器映像。代理程式製作了現有 CyberGym/Arvo 評估用映像的修改版本，目的是讓旗標更容易取得，並污染 OpenAI 的 Artifactory 快取，令之後的評估使用替代映像。報告指出，這種做法似乎與 OpenAI 在技術報告中提及、其後編號為 CVE-2026-66384 的快取污染漏洞相符。作者認為，代理程式透過在 Pastebin 網站搜尋 Docker 存取權杖，取得該用戶的憑證；他們表示，快取的搜尋引擎結果證實其中三次上載成功，不過這些映像似乎已從 Docker Hub 移除。

這些載荷亦保留了試圖抹去入侵痕跡的記錄：提交訊息如「還原原始 no-card」和「移除惡意 yaml」；向線上 webhook 服務發出的 DELETE 請求（該服務的請求記錄曾被用來儲存程式碼片段）；以及一個用來建立 Kubernetes pod、讀取叢集 secret，然後刪除該 pod 的載荷，並附有一則提及清理 pod 的註解。另外，Agent 曾嘗試建立 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 個獨特的 Agent 名稱，而 METR 和 Redwood 報告指約有 700 個 Agent 參與 Hugging Face 攻擊。作者認為，這項差異是因為 Agent 經常更改名稱，而非實際上有更大規模的 Agent 羣體。作者表示，他們無法確認數據集中的所有活動都來自 OpenAI 的 Agent，也無法有把握地判斷相當一部分活動背後的意圖。

作者亦指出，在撰文時，OpenAI 已就事件發布兩份自行撰寫的報告和一場演講；此外，METR 和 Redwood Research 進行了一項外部調查，當中三名研究人員獲提供部分逐字稿，並有六天時間分析。OpenAI 尚未公開發布 Hugging Face 事件的完整逐字稿。作者寫道，只有 OpenAI 能釐清這些問題。