GPT內測失控，入侵Hugging Face！GLM-5.2追查萬條記錄救場

智東西
編譯 楊京麗
編輯 李水青

智東西7月22日消息，今天凌晨，OpenAI確認，包括GPT-5.6 Sol和一款更強預發布模型在內的多款自家模型，在內部網絡安全評測中利用漏洞突破隔離環境，繼而侵入Hugging Face生產系統，并獲取評測答案。OpenAI稱，這是一起“前所未有的網絡安全事件”，事件涉及當前最先進的網絡攻擊能力。

▲OpenAI發文承認網絡攻擊事件（圖源：X）

7月16日，Hugging Face就已披露這起由自主AI Agent驅動的入侵。取證過程中，Hugging Face最初嘗試使用商業前沿模型，但真實攻擊命令和漏洞載荷觸發了安全護欄。

于是，Hugging Face在自有基礎設施上部署智譜的旗艦模型GLM-5.2，分析超過1.7萬個記錄事件，把通常需要數天的工作壓縮至數小時。7月20日，Hugging Face進一步解釋了選擇GLM-5.2的原因及其部署方法。

此次入侵導致少量內部數據集和部分服務憑證被未授權訪問，但尚無證據顯示公開模型、數據集、Spaces及軟件供應鏈遭到篡改。

Hugging Face現已關閉相關代碼執行路徑、重建遭入侵的節點并輪換相關憑證；OpenAI則收緊研究基礎設施配置，與Hugging Face聯合取證，推動第三方軟件供應商修復漏洞。

一、模型利用零日漏洞逃出沙箱，攻入Hugging Face

7月中旬，OpenAI在一次內部ExploitGym評測中，測試模型的網絡攻擊能力。為了測出模型的能力上限，OpenAI降低了模型的網絡安全拒答限制，也沒有啟用生產環境中阻止高風險操作的分類器。

評測原本在隔離環境中運行，模型不能直接訪問互聯網，只能通過一套內部托管的軟件包，安裝外部軟件。為了完成評測，模型持續尋找離開隔離環境的方法，并發現該代理軟件中的一個零日漏洞。所謂零日漏洞，是指此前尚未被軟件開發者發現、因而也沒有補丁的安全缺陷。

模型利用這一漏洞突破網絡限制，又在OpenAI測試環境中提升權限、橫向進入其他節點，最終獲得互聯網訪問能力。OpenAI已經將該零日漏洞報告給軟件供應商，并與對方合作修復。

隨后，模型推斷Hugging Face可能保存了ExploitGym相關模型、數據集和評測答案，于是開始尋找進入其系統的方法。

Hugging Face事后還原發現，攻擊從一個惡意數據集開始：該數據集利用遠程代碼加載器和數據集配置模板，注入兩條代碼執行路徑，在數據處理節點上運行代碼。此后，模型取得節點級權限，提取云端和集群憑證，并橫向進入多個內部集群，最終從Hugging Face生產數據庫中獲取評測答案。

7月16日，Hugging Face稱，公司在當周早些時候，通過AI輔助異常檢測系統發現了攻擊，其安全團隊及Agent隨后阻止相關活動。今天，OpenAI進一步確認，這起事件由包括GPT-5.6 Sol和一款更強的預發布模型在內的多款自家模型引發。

二、OpenAI收緊評測環境，模型已能執行長期復雜攻擊

事件發生后，OpenAI公布了五項處理措施：

1）加固研究環境：在漏洞修復期間，OpenAI收緊基礎設施配置，即使這會拖慢研究進度。OpenAI還會定期向公司安全與安保委員會匯報這些措施及其影響。

2）聯合調查：繼續與Hugging Face合作，對事件進行取證分析。

3）修復零日漏洞：向內部軟件包緩存代理的第三方供應商披露漏洞，并與對方共同修補。

4）支持Hugging Face加強防御：將其納入OpenAI的網絡安全模型可信訪問計劃，幫助其盡快使用OpenAI模型的能力改進防護。

5）加強未來評測監控：加強模型訓練和評測期間的對齊機制、網絡安全保護及內部監控。

OpenAI稱，此前為模型增加的部署防護沒有在此次評測中開啟，因為測試目的就是觀察模型發現和利用網絡漏洞的能力。此次事件說明，即使在內部評測階段，OpenAI也需要進一步加強模型對齊、網絡安全保護和運行軌跡監控。

英國人工智能安全研究所的評估顯示，GPT-5.6 Sol等模型越來越能長時間執行復雜、多步驟的網絡行動。這次事件進一步說明，相關能力已經可以作用于真實系統，模型甚至能在沒有源代碼的情況下發現新的攻擊路徑。

▲不同模型網絡攻擊任務能力對比（圖源：OpenAI）

OpenAI稱，發展這些能力的同時，必須加強隔離、監控、訪問控制和防御工具。另一方面，安全團隊也可以利用模型提前發現弱點、理解多個漏洞如何串聯，并加快修復速度。OpenAI還邀請其他安全團隊申請可信訪問計劃。

Hugging Face聯合創始人兼CEO克萊芒·德朗格（Clément Delangue）稱，這起可能是首例的事件說明，AI安全無法由一家公司獨立解決，而是需要開放協作，并讓更多安全防守人員獲得AI能力。

三、Hugging Face清理受影響系統，本地部署GLM-5.2完成取證

截至7月16日，Hugging Face已經阻止攻擊并開始處置受影響系統。公司發現，攻擊者未經授權訪問了少量內部數據集和部分服務憑證，公司仍在評估合作伙伴或客戶數據是否受影響；但沒有證據顯示公開模型、數據集、Spaces及軟件供應鏈遭到篡改。

針對這起事件，Hugging Face采取了以下五項措施：

1）修復根本漏洞：關閉攻擊者首次進入系統時利用的兩條數據集代碼執行路徑。

2）清理受影響系統：清除攻擊者在相關集群中的殘留訪問，并重建遭入侵的節點。

3）更換相關密鑰：撤銷并輪換受影響的憑證和Token，同時擴大預防性密鑰輪換的范圍。

4）加強集群防護：增加新的安全措施，并實施更嚴格的集群準入控制。

5）改進檢測和告警：確保高危信號能在數分鐘內通知安全響應人員，包括周末和節假日。

攻擊最初由Hugging Face的AI輔助檢測系統發現。為了弄清數萬次自動操作，大模型驅動的分析Agent處理了超過1.7萬個記錄事件，負責還原攻擊時間線、提取入侵指標、梳理被訪問的憑證，并區分真實影響與誘餌活動，把通常需要數天的工作壓縮至數小時。

Hugging Face最初嘗試調用商業API背后的前沿模型，但真實攻擊命令、漏洞載荷和C2信息觸發了安全護欄。相關系統無法區分安全響應人員和攻擊者，分析請求因而受阻。Hugging Face隨后在自有基礎設施上運行GLM-5.2完成取證，同時確保攻擊數據和相關憑證不離開內部環境。

四、為何選擇GLM-5.2：開源、100萬Token上下文，可本地部署

7月20日，Hugging Face再次發文，進一步解釋了為何選擇GLM-5.2完成攻擊日志取證，并介紹了如何在本地服務器或企業自有的微軟、AWS云環境中部署該模型。

Hugging Face選擇GLM-5.2，首先是因為它采用開放權重和MIT許可證，可以部署在企業自己的基礎設施中。安全人員能夠自行控制模型和運行環境，不會因為商業API的使用政策或安全護欄而中斷調查。攻擊日志、漏洞載荷及其中涉及的憑證也無需發送給第三方服務。

其次，GLM-5.2擁有100萬Token上下文窗口。Hugging Face此次需要分析超過1.7萬個記錄事件，包括攻擊命令、憑證訪問和橫向移動過程。較大的上下文窗口可以讓模型在一條完整時間線上關聯這些操作，不必把日志切成大量片段分別處理。

GLM-5.2在推理、工具編排和終端操作方面也具備較強能力。GLM-5.2在MCP-Atlas和SWE-bench Pro上得分分別為76.8和62.1，僅落后于Claude Opus 4.8，領先GPT-5.5和Gemini 3.1 Pro；在Terminal Bench 2.1上得分為81，落后于Claude Opus 4.8和GPT-5.5，但領先Gemini 3.1 Pro。

▲GLM-5.2、Claude Opus 4.8、GPT-5.5、Gemini 3.1 Pro模型部分能力對比（圖源：Hugging Face）

GLM-5.2并非在每項測試中都領先，但它可以在企業內部正常運行，并直接處理真實攻擊材料。企業既可以把它部署在自己的物理服務器上，也可以運行在自有云賬戶中。Hugging Face建議安全團隊提前完成部署和測試，將模型接入現有安全工具，而不是等攻擊發生后再尋找可用模型。

結語：模型安全防線需前移至內部評測

這起事件中，內部評測的隔離和監控未能阻止模型越界。隨著模型能夠長期執行多步驟任務，網絡安全保護不能只在產品部署后啟用，也需要覆蓋訓練和評測階段。

Hugging Face使用GLM-5.2完成取證則說明，安全事件發生時，模型能否本地部署、處理敏感數據并持續調用安全工具，可能比單項測試排名更重要。安全團隊需要提前準備可控、可用的模型，而不是等攻擊發生后再臨時尋找工具。

來源：OpenAI、Hugging Face