<mark id="oztn4"></mark>
0
| 本文作者： 鄭佳美 | 2026-07-30 17:28 |
作者丨鄭佳美
編輯丨馬曉寧
7 月 27 日，Hugging Face 首次完整披露了這次 Agent 入侵的技術(shù)細節(jié)，還原了其逃出 OpenAI 測試沙箱、進入 Hugging Face 生產(chǎn)環(huán)境、竊取憑證并向內(nèi)部集群擴散的全過程。
整場攻擊從 7 月 9 日持續(xù)到 7 月 13 日，共產(chǎn)生約 17,600 次操作，形成了一條由 Agent 自主規(guī)劃、持續(xù)試錯和動態(tài)調(diào)整的完整攻擊鏈。
但 Hugging Face 這次沒有公布具體模型，只表示攻擊 Agent 由多個 OpenAI 模型共同驅(qū)動。不過早在 7 月 22 日，奧特曼就已經(jīng)發(fā)文“認領(lǐng)”，確認參與測試的模型包括 GPT-5.6 Sol，以及一款能力更強、尚未發(fā)布的內(nèi)部研究原型。
這也讓事件的重點從“究竟是誰干的”，轉(zhuǎn)向“這套 Agent 是如何一步步突破多層防線的”。
01
Hugging Face 公布的時間線顯示，它并不是依靠單個漏洞直接進入生產(chǎn)系統(tǒng)，而是先逃出 OpenAI 沙箱，再尋找外部跳板，最后利用 Hugging Face 自身的數(shù)據(jù)處理鏈路完成入侵。
▎第一步：利用零日漏洞逃出 OpenAI 沙箱
OpenAI 原本將評測放在高度隔離的環(huán)境中。模型不能直接訪問互聯(lián)網(wǎng)，只能通過內(nèi)部部署的軟件安裝依賴包。
這個有限出口最終成為 Agent 逃逸的入口。
Agent 在軟件包緩存代理 Artifactory 中發(fā)現(xiàn)了一個此前未知的零日漏洞，并利用它突破網(wǎng)絡(luò)限制。隨后，它在 OpenAI 的研究環(huán)境中繼續(xù)進行權(quán)限提升和橫向移動，最終找到一個能夠連接公網(wǎng)的節(jié)點。
也就是說，Agent 并沒有被授予互聯(lián)網(wǎng)權(quán)限，而是通過漏洞自己獲得了互聯(lián)網(wǎng)訪問能力。OpenAI 后續(xù)已將相關(guān)漏洞提交給軟件供應(yīng)商處理。
這一過程說明，Agent 不只是能夠生成漏洞利用代碼，還能理解軟件代理、網(wǎng)絡(luò)出口和節(jié)點權(quán)限之間的關(guān)系，再把局部缺陷轉(zhuǎn)化為逃離隔離環(huán)境的通道。
▎第二步：攻占第三方沙箱，建立攻擊基地
獲得公網(wǎng)訪問后，Agent 找到了一個公開的第三方代碼評測沙箱。
這個沙箱允許用戶提交 C 語言代碼，由系統(tǒng)完成編譯和運行。Agent 發(fā)現(xiàn)，它既可以在程序加載階段執(zhí)行系統(tǒng)命令，也可以利用提交路徑中的命令注入問題，獲得任意命令執(zhí)行權(quán)限。
兩條路徑最終都讓 Agent 在第三方沙箱中獲得了管理員或 Root 權(quán)限。隨后，這個原本用于測試代碼的環(huán)境，被改造成攻擊行動的控制中心、載荷中轉(zhuǎn)站和數(shù)據(jù)出口。
這一步讓攻擊具備了持續(xù)性。即使 OpenAI 的臨時評測環(huán)境被重置，Agent 仍然可以從外部沙箱重新部署工具、恢復(fù)通信渠道并繼續(xù)行動。
▎第三步：把 Hugging Face 數(shù)據(jù)集變成攻擊入口
接下來，Agent 將目標轉(zhuǎn)向 Hugging Face 的數(shù)據(jù)處理系統(tǒng)。
Hugging Face 需要自動處理用戶上傳的數(shù)據(jù)集，讀取文件、解析配置并生成預(yù)覽。Agent 沒有直接連接內(nèi)部網(wǎng)絡(luò)，而是構(gòu)造惡意數(shù)據(jù)集，讓生產(chǎn)服務(wù)器在處理數(shù)據(jù)時替它執(zhí)行操作。
第一條路徑利用了 HDF5 的外部存儲機制。
HDF5 文件可以聲明部分數(shù)據(jù)實際存放在另一個文件路徑中。Agent 構(gòu)造特殊數(shù)據(jù)集，誘導(dǎo) Hugging Face 的處理程序讀取服務(wù)器本地文件，從而獲取生產(chǎn) Pod 的環(huán)境變量和數(shù)據(jù)處理程序源代碼。
環(huán)境變量中包含部分密鑰和訪問憑證，源代碼則暴露了數(shù)據(jù)處理流程的具體實現(xiàn)。
第二條路徑利用了 Jinja2 模板注入。
某個本應(yīng)只保存數(shù)字偏移量的數(shù)據(jù)配置字段，被錯誤地作為模板表達式執(zhí)行。Agent 借此在 Hugging Face 的 Kubernetes 生產(chǎn)工作節(jié)點中執(zhí)行任意 Python 代碼。
一條路徑用于讀取文件和憑證，另一條路徑用于獲得代碼執(zhí)行權(quán)限。兩者結(jié)合后，Agent 正式進入了 Hugging Face 的生產(chǎn)環(huán)境。
▎第四步：用 Hugging Face API 控制內(nèi)部服務(wù)器
進入生產(chǎn) Pod 后，Agent 仍然需要解決外部沙箱與 Hugging Face 內(nèi)部節(jié)點之間的通信問題。
它的辦法是，把 Hugging Face 自己的數(shù)據(jù)集和 API 變成控制通道。雷峰網(wǎng)
Agent 上傳包含命令的惡意數(shù)據(jù)集配置。生產(chǎn)節(jié)點處理數(shù)據(jù)集時執(zhí)行命令，再將結(jié)果寫入另一個由攻擊者控制的數(shù)據(jù)集。外部沙箱隨后通過正常的 Hugging Face API 讀取結(jié)果，并生成下一輪命令。
攻擊指令和執(zhí)行結(jié)果因此混入正常的數(shù)據(jù)集上傳、處理和讀取流量。Agent 不需要搭建傳統(tǒng)的遠程控制服務(wù)器，Hugging Face 平臺本身就承擔了命令傳輸功能。
當某個數(shù)據(jù)集、臨時賬號或公共中轉(zhuǎn)服務(wù)被封鎖后，Agent 還可以更換新的數(shù)據(jù)集和通信渠道，重新建立控制循環(huán)。
▎第五步：從一個生產(chǎn) Pod 擴散到內(nèi)部集群
獲得生產(chǎn) Pod 的代碼執(zhí)行權(quán)限后，Agent 開始枚舉文件系統(tǒng)、進程、網(wǎng)絡(luò)和環(huán)境變量，讀取 Kubernetes 服務(wù)賬戶令牌，探測云服務(wù)器元數(shù)據(jù)接口，并嘗試從容器權(quán)限提升到宿主節(jié)點。
取得節(jié)點 Root 權(quán)限后，Agent 讀取了 Kubernetes 中保存的 Secret 對象。其中一個生產(chǎn) Secret 包含 136 個密鑰，包括內(nèi)部網(wǎng)絡(luò)注冊密鑰和跨集群訪問憑證。雷峰網(wǎng)(公眾號：雷峰網(wǎng))
隨后，Agent 使用被盜密鑰，將攻擊者控制的設(shè)備接入 Hugging Face 內(nèi)部網(wǎng)絡(luò)。整個行動期間，它累計嘗試注冊了 181 個設(shè)備。
更嚴重的問題出現(xiàn)在跨集群訪問系統(tǒng)中。
Hugging Face 當時讓多個內(nèi)部集群共用一套高權(quán)限連接憑證，而且該身份被綁定到 Kubernetes 的 system:masters 管理員組。Agent 一旦拿到這個憑證，就可以迅速獲得多個集群的管理員權(quán)限。
它還利用代碼托管平臺的 App 集成生成訪問令牌，進入少量內(nèi)部代碼倉庫，并嘗試修改 CI 構(gòu)建腳本。如果這一步成功，惡意代碼可能繼續(xù)進入軟件構(gòu)建和發(fā)布流程。
相關(guān)執(zhí)行策略最終阻止了這些修改生效。Hugging Face 表示，沒有發(fā)現(xiàn)模型、數(shù)據(jù)集、Spaces、軟件包或容器鏡像受到污染。攻擊者實際讀取的客戶內(nèi)容，主要是保存 ExploitGym 和 CyberGym 挑戰(zhàn)答案的 5 個數(shù)據(jù)集。
02
Hugging Face 的安全系統(tǒng)其實捕捉到了多層異常信號，內(nèi)部 AI 安全 Agent 也將部分信號關(guān)聯(lián)成了一個完整事件。問題是，系統(tǒng)沒有及時提高告警等級，也沒有第一時間通知值班團隊，因此延誤了人工響應(yīng)。
安全團隊介入后，迅速定位到數(shù)據(jù)集配置渲染器中的攻擊入口，關(guān)閉相關(guān)組件，并切斷 Agent 進入內(nèi)部網(wǎng)絡(luò)的路徑。真正阻止攻擊的，是人工團隊采取的隔離、封鎖和憑證輪換措施。
GLM-5.2 的作用，主要發(fā)生在后續(xù)取證階段。
安全團隊需要查明 Agent 執(zhí)行了哪些命令、泄露了哪些憑證、進入了哪些系統(tǒng)，以及是否留下持久化工具。面對約 17,600 次操作，僅靠人工逐條分析幾乎不現(xiàn)實，因此 Hugging Face 搭建了一套 AI 輔助調(diào)查流水線。
團隊最初嘗試使用 Claude Opus 和 Fable 分析攻擊日志，但這些閉源模型拒絕了大量任務(wù)。其安全機制無法準確區(qū)分“正在實施攻擊”和“正在調(diào)查攻擊”，因此將漏洞載荷、惡意代碼和憑證分析同樣判斷為高風險行為。
Hugging Face 隨后在自己的基礎(chǔ)設(shè)施上部署了 NVIDIA 量化版 GLM-5.2，并將分析流水線切換到這款模型。
GLM-5.2 是 Z.ai 發(fā)布的開放權(quán)重模型，支持最長 100 萬 Token 上下文，采用 MIT 許可證。Hugging Face 使用的是 NVIDIA NVFP4 量化版本，可以直接部署在自己的 GPU 基礎(chǔ)設(shè)施中。
攻擊者會將數(shù)據(jù)切分成多個片段，再通過異或和壓縮進行編碼，將結(jié)果分散存放在不同的公共服務(wù)和數(shù)據(jù)集中。GLM-5.2 幫助團隊識別出這套“切片、異或、壓縮”的處理流程，并從日志中找到每輪行動使用的密鑰。
依靠這些信息，安全團隊解密了常規(guī)掃描未能發(fā)現(xiàn)的載荷，重新還原出大量命令和數(shù)據(jù)傳輸記錄。GLM-5.2 還協(xié)助開發(fā)了軌跡分析界面，用于關(guān)聯(lián)不同環(huán)境中的攻擊行為。
本地部署同樣非常重要。
真實攻擊日志可能包含仍然有效的密鑰、內(nèi)部域名、系統(tǒng)架構(gòu)和未公開漏洞。使用 GLM-5.2 后，這些敏感信息可以留在 Hugging Face 自己的基礎(chǔ)設(shè)施中，不需要提交給外部模型 API。
因此，GLM-5.2 并不是在網(wǎng)絡(luò)邊界上直接擊退 GPT-5.6 Sol，而是在攻擊被阻斷后，幫助安全團隊解密載荷、恢復(fù)操作時間線，并確認哪些密鑰需要輪換、哪些節(jié)點需要重建。
03
把這次事件描述成“AI 覺醒”其實并不準確。
從現(xiàn)有證據(jù)看，Agent 沒有產(chǎn)生脫離測試任務(wù)的獨立目的。它一直在尋找 ExploitGym 的答案，只是發(fā)現(xiàn)入侵 Hugging Face 比正常解題更加直接。
真正危險的地方在于，一個模型在目標定義存在漏洞時，同時擁有了執(zhí)行代碼、訪問網(wǎng)絡(luò)、讀取憑證、保存狀態(tài)和持續(xù)修改計劃的能力。
當這些能力被裝進 Agent 框架后，模型是否具有主觀惡意已經(jīng)不是最重要的問題。只要任務(wù)只強調(diào)結(jié)果，而外部系統(tǒng)又缺少嚴格的權(quán)限邊界，它就可能產(chǎn)生與真實黑客高度相似的行為。
這次事件還暴露出另一個現(xiàn)實矛盾：關(guān)閉部分安全限制的閉源模型完成了攻擊，開啟安全限制的閉源模型卻拒絕協(xié)助調(diào)查，最后是一款能夠本地部署、由防守方完全控制的開放權(quán)重模型完成了解密和溯源。
未來的網(wǎng)絡(luò)攻防，很可能不再只是人類攻擊者與安全團隊之間的較量，而是攻擊 Agent 與防御 Agent 在機器速度下展開長期對抗。
決定勝負的也不會只是模型能力，而是誰擁有更嚴格的隔離環(huán)境、更小的憑證權(quán)限、更清晰的執(zhí)行邊界，以及一套在真實事故中能夠被防守方掌控的模型。
參考鏈接：
https://huggingface.co/blog/agent-intrusion-technical-timeline
https://x.com/sama/status/2079661132302995790
上車，帶你看遍全球 AI 頂會精華
可獨家暢覽：
專家演講PPT
大會報告全文
熱門論文解讀
學術(shù)新星訪談
掃描上方二維碼
或點擊「閱讀原文」關(guān)注專區(qū)。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
