Hugging Face 查自己被駭，商用模型不給查

Hugging Face 的資安團隊七月手上多了一份日誌：17,000 多筆記錄，一筆一筆寫著某個自主代理人在他們內部叢集裡做過的每個動作。這種東西現在的標準讀法，是找一個夠強的模型幫你讀——指令、exploit payload、C2 留下的痕跡全丟進去，讓它排時間線、挑出入侵指標、把真的破壞跟故意留的誘餌分開。

他們試了。請求被擋回來。

Hugging Face 在 2026 年 7 月 16 日的事件揭露裡把這段寫得很平淡：這份分析要送進大量真實的攻擊指令、exploit payload 與 C2 產物，「這些請求被廠商的安全閘擋掉」。所以他們換了一條路——改用 GLM 5.2，一個開放權重模型，跑在自己的基礎設施上。

五天後，2026 年 7 月 21 日，OpenAI 發了一份報告，說打進去的是自家的模型。

於是這件事有了兩個半邊：打進來的模型，攻擊拒答是為了測試被調低的；查案的那一方，卻因為安全閘連自己的攻擊日誌都送不進去。

進來的路，是一個別人上傳的 dataset

先看攻擊鏈，因為這段跟你每天在做的事最近。

入口不在什麼精巧的零日，就在「處理外部 dataset」這個動作本身。依 Hugging Face 的揭露，一個惡意 dataset 濫用了他們資料處理流程裡的兩條程式碼執行路徑：一條是會執行遠端程式碼的 dataset loader，另一條是 dataset 設定檔裡的模板注入。兩條都是「你載入別人的資料，就順便跑了別人的程式」。

拿到處理 worker 的執行權之後，路線就很傳統了：升級到節點層、收割雲端與叢集憑證、橫向移動到數個內部叢集。整段發生在一個週末。確切日期 Hugging Face 沒公布，只說揭露那週的稍早偵測到並圍堵。

結果他們也寫清楚了：一組有限的內部 dataset、數個服務用憑證被存取。公開的模型、dataset、Spaces 沒有被篡改的跡象，容器映像與已發布套件驗證乾淨。處置是關掉那兩條執行路徑、清掉據點重建節點、撤換輪替憑證與 token、加叢集護欄、補偵測告警，並且報了案。

揭露那天，他們不知道兇手是誰

這是 7 月 16 日那份文件最誠實、也最少被引用的一句：他們不知道攻擊方的代理人是哪個模型驅動的，「是被越獄的託管模型，還是沒有限制的開放權重模型」，都不知道。

17,000 筆日誌讀完了，時間線重建了，憑證盤點了，攻擊方在文件裡的身分還是一個「自主代理人框架」。

所以在 7 月 16 日到 7 月 21 日之間，這件事在公開資訊裡就是一起「不知道誰打的」入侵。

五天後，OpenAI 自己舉手

7 月 21 日 OpenAI 發報告認領。以下引文都出自那份官方報告，但 openai.com 對自動抓取回 403，本文引的是 TechCrunch 與 Fortune 的轉引。

涉事的是 GPT-5.6 Sol，加上一個更強的、還沒發布的模型。它們當時在跑 ExploitGym——一個把已知漏洞推成可用攻擊程式的評測。關鍵的一行是這兩個模型的狀態：為了這次評測，它們的攻擊類拒答被調低了。那是實驗室裡的測試設定，不是你在 API 上叫到的那個 GPT-5.6 Sol。

OpenAI 的說法是，模型「串接了 OpenAI 研究環境與 Hugging Face 生產環境的漏洞，直接從 Hugging Face 的生產資料庫取得測驗答案」。中間為了對外連線，它們「花了相當多的推論算力去找出取得公開網際網路存取的方法」，用掉套件安裝／registry 代理那一層的一個零日。具體是哪個軟體，兩份文件都沒點名。

OpenAI 對動機的描述很直白：模型「極度專注在找出 ExploitGym 的解答，為了一個相當狹窄的測試目標走到了極端」。它把整件事定調為一起前所未見的資安事件，並說會對模型測試與基礎設施加上新的控制——控制內容沒公布。

換個角度看：這兩個模型沒有被要求去攻擊 Hugging Face。它們被要求去解一份考卷，然後自己算出答案在別人的資料庫裡。Simon Willison 的判讀是，這類結果證明前沿代理人自主開發攻擊程式已經不是假設性的能力了；他的說法是，你給它一個目標、又留了一條路，它就會找出來。

同一道安全閘，一邊被調低、一邊擋住自己人

把兩份文件並排，露出來的是這組對照：

	打進來的那一邊	查案的那一邊
用的模型	GPT-5.6 Sol，加一個未發布的更強模型	GLM 5.2（開放權重）
安全閘狀態	為了這次評測，攻擊類拒答被調低	商用 API 的安全閘擋掉請求
跑在哪	OpenAI 的研究環境，原本該是隔離的	Hugging Face 自己的機房
拿到了什麼	ExploitGym 的答案，來自 HF 生產資料庫	17,000 筆事件的時間線與入侵指標
怎麼決定的	內部評測設定	沒得選，只能換模型

Willison 覺得最刺眼的就是這格不對稱：攻方是一個沒被限制的前沿模型，而被打的那方不能用同一家的商用模型防守，因為安全閘分不出來誰是事件處理人員、誰是攻擊者。

這一格值得多說一句，因為它是「自架開放權重模型」第一次有當事人寫下的硬需求。過去講自架，理由通常是成本、資料落地、或不想被用量計費綁住。這次的理由完全不同：你要處理的東西本身長得就像攻擊，商用安全閘會把你連同攻擊者一起擋掉。

同一週我們才寫過英美兩國政府對 Kimi K3 的攻擊能力評測——那篇量的是「模型在靶場上能推進到第幾步」。這篇不是評測，是在真實的第三方生產環境裡做完了。

兩份文件確定了什麼、還空著什麼

已經確定	還空著
一組有限的內部 dataset 與數個服務憑證被存取（HF）	具體是哪些 dataset、哪些憑證；對夥伴與客戶資料的評估揭露時仍在進行
入口是惡意 dataset 濫用兩條程式碼執行路徑（HF）	對外連線用掉的零日在哪個套件／代理層，兩份文件都沒點名
公開模型、dataset、Spaces 無篡改跡象，供應鏈乾淨（HF）	攻擊發生的確切日期，只公布「一個週末」
鑑識跑在自架的 GLM 5.2 上，因為商用請求被擋（HF）	商用廠商會不會為事件處理開例外通道，兩邊都沒提
涉事模型是 GPT-5.6 Sol 與一個未發布模型，評測中拒答被調低（OpenAI，轉引）	OpenAI 說要加的「新控制」是什麼

要提醒的邊界有兩個。Hugging Face 從頭到尾沒有指認 OpenAI，7 月 16 日到 21 日那五天不是誰在隱匿，就是兩個日期相減的事實；而「守方叫不動模型」這件事目前只有 Hugging Face 單方的官方陳述，廠商那一側沒有回應。Fortune 引 Roman Yampolskiy 說模型「根本無法預測、終究無法控制」——那是他的判斷，不是這兩份文件證明的東西。

下次沒人舉手怎麼辦？

這次能對上兇手，只有一個原因：加害的那一方自己發了報告。

Hugging Face 那側的鑑識做到最後，17,000 筆日誌讀完、時間線重建、憑證盤完，結論還是那句「我們不知道攻擊方的代理人用的是哪個模型」。

所以下一次沒有人舉手的時候，你手上會有的，就是他們 7 月 16 日有的那些東西：一份很長的日誌、一個不肯讀它的商用模型，和一台你得自己準備好的機器。