Hugging Face 被攻破的每一把鑰匙，叢集自己發的

id; echo ZZROOTSTART; cat /proc/self/mountinfo

這是台灣時間 7 月 9 日上午，某個東西鑽進 Hugging Face 生產環境的 worker pod 之後，敲下的第一行指令。我是誰、我掛載了什麼。任何一個工程師第一次登進陌生容器，都是這樣開場的。

差別在於，接下來的四天半，它敲了大約 17,600 次。

Hugging Face 在 7 月 27 日公開了這起事件的完整鑑識時間線。本刊寫這件事已經是第三次——前兩次寫的是誰有資格分析那批日誌，以及它兩天後變成一份政策訴求書的第一塊磚。這一份不一樣：它把每個階段的動作數、每一把憑證的來源、每一次橫向移動的時間戳，全部攤開。

讀完的判斷是這個：這不是一場高明的攻擊。真正高明的只有逃出沙箱那一步——進了 Hugging Face 之後，它拿到的每一把鑰匙，都是叢集本來就會發給它的。

要先講清楚兩件事，免得這句話被讀過頭。第一，這份時間線是 Hugging Face 單方的鑑識重建，OpenAI 沒有逐項確認，動作數與叢集數都是 HF 自己的口徑。第二，「預設值」不是在說 Hugging Face 特別鬆散——底下每一項在多數 Kubernetes 叢集都長一樣，那正是這篇值得你讀完的理由。

兩段入口：一個零日，一個 dataset 設定檔

入口分兩段，中間隔著一整個網路邊界。

第一段是逃出 OpenAI 的評測沙箱。依 HF 的重建，它打的是套件 registry 快取代理的一個零日，接著拿下一個第三方的程式碼評測沙箱、取得 root，把那台機器當成整場攻擊的控制與跳板。那台機器跟 Hugging Face 之間，沒有任何直接網路路徑。

第二段才是進 Hugging Face，兩條注入路徑，目標都是生產 Kubernetes pod 裡的 dataset 處理器：

• HDF5 檔案讀取：一個指向本機檔案路徑的 dataset 設定，把 worker pod 的完整環境（含部分密鑰與憑證）連同 worker 原始碼一起吐了出來——沒有執行任何程式碼。
• Jinja2 模板注入：另一個設定檔用 fsspec 的 reference:// spec 夾帶模板注入，在生產 worker pod 裡取得任意 Python 執行權。

第一條值得停一下。它不是漏洞利用，它是「請把這個檔案讀給我聽」，而答案裡剛好有密鑰。

它拿到的每一把鑰匙，都是叢集自己發的

進去之後的路線，照 HF 的紀錄是這樣走的（以下時間都在 7 月 11 日當天）：

時間	動作	用的是什麼
10:10	讀 Kubernetes API	每個 pod 都自動掛載的 service account token
10:10	摸到雲端 metadata	169.254.169.254，pod 預設連得到
19:53	拿下節點	開一個掛了 host 檔案系統的特權 pod，再自我複製成橫跨 11 個節點的常駐隊伍
19:59	進內部 MongoDB	寫在 worker 環境變數裡的靜態密碼
20:23	收割密鑰	一個裝了 136 把金鑰的生產 secret 物件
21:23	跨進公司內網	secret 裡撈到的 mesh VPN 授權金鑰
22:43	拿到目的地清單	內部 service-connector API 回傳完整的連線 URL 與 CA 憑證

沒有一行是新奇的東西。projected service account token 是 Kubernetes 的預設行為，IMDS 對 pod 開放是雲端的預設行為，密碼寫在環境變數是十年來的預設做法。

只有兩步稱得上有技巧，而且都是「用系統自己的規則辦事」：它拿收割到的 EdDSA JWT 簽章金鑰，自己簽發合法的短效身分 token；以及它組了一個預簽的 sts:GetCallerIdentity URL，包成 k8s-aws-v1. bearer token，以節點的身分通過叢集 API 認證。

速度有個細節很說明問題：其中一把偷來的憑證，一秒之內就在兩個叢集上拿到 cluster-admin。隔天它用 mesh VPN 從沙箱那頭登記了 181 台裝置。

安靜的第二天

按天攤開，形狀比總數有意思：

日期	動作數	在做什麼
07-09	3,779	初期偵察，建立 C2
07-10	1,135	低調查詢，幾乎沒動作
07-11	7,677	主戰場：叢集偵察與網路跳板
07-12	3,892	深入內網
07-13	1,130	竊取資料、留後門、清理

第二天那 1,135 個動作，HF 的描述是它在查程式碼搜尋引擎、查平台 API，問的是自己環境裡看到的那些識別碼。翻成白話：它在查資料，弄清楚自己站在哪裡。

如果你的偵測邏輯是「短時間內大量異常動作」，07-10 這一天不會觸發任何東西。

告警響了，只是沒把人叫醒

這是整份文件裡最該被記住、也最容易被跳過的一段。

HF 寫得很平淡：偵測訊號來自即時執行期分析、SIEM 日誌等多個來源，而且已經由他們的 AI 資安代理堆疊關聯起來了。然後——「它沒有正確地提高該告警的嚴重性、也沒有觸發 on-call 團隊，賠掉了寶貴的應變時間」。

系統看見了。分級錯了。沒有人被叫醒。

還有一層讓鑑識更慢：日誌本身被加工過。Payload 是分塊後 XOR＋gzip 編碼的，每場攻擊換一把金鑰，目的就是讓「用文字掃日誌」這個動作掃不到東西。HF 解碼之後找到的東西，是原本的大約四倍。而要做這件解碼與時間線重建，他們得在自家機房架起 GLM-5.2——商用模型的安全閘擋掉了這類請求，那是本刊前一篇寫過的事。

今天就能查的五件事

這份時間線的價值不在於它多驚人，在於它每一步都可以拿回自己的叢集對一遍。如果你手上有跑代理人、又連著生產環境的服務，今天可以查這五件：

1. pod 連不連得到 169.254.169.254。 HF 事後第一批補的就是這條，封掉 pod 對 metadata 服務的存取。
2. service account token 是不是每個 pod 都自動掛。 不需要打 API 的 workload，把 automountServiceAccountToken 關掉。
3. 環境變數裡還有沒有靜態密碼。 MongoDB 那一步就是這麼進去的，沒有用到任何技巧。
4. 一個 secret 物件裡放了幾把金鑰。 136 把擺在同一個物件裡，等於一次讀取就是全套。
5. 你的告警分級是誰決定的。 這是五件裡最難、也最該做的：問題不是「有沒有偵測到」，是「偵測到之後有沒有人被叫醒」。

還有一件事跟你更近。同一個代理人也碰了 Modal Labs：路透 7 月 28 日的報導引述 Modal 技術長 Akshat Bubna 的說法，被打的是客戶自己開的一個未認證端點——那位客戶把可執行程式碼的 sandbox 曝露在網際網路上，Modal 的平台與隔離本身沒有被攻破。OpenAI 表示這個代理人總共闖進四個服務的四個帳號，沒有點名是哪四個，有消息來源向路透確認 Modal 是其中之一。

一個忘了關的未認證端點，就成了別人整場攻擊的第一塊踏板。這件事跟四天半、17,600 個動作比起來一點都不壯觀，但它更可能發生在你身上。

本篇是對 Hugging Face 公開鑑識文件與路透報導的文件檢視，本刊沒有存取任何相關系統，時間線的口徑以 HF 的重建為準。