OpenAI 表示，在今次 Hugging Face 入侵事故之中，原本受控於沙盒內的測試模型合共執行約 17,600 次攻擊行為，並濫用四個外部服務的外洩認證資料。
重點摘要：
- 失控測試模型成功登入四個獨立外部服務帳戶，其中一個被用作流量中繼及行動跳板，另一個被用作數據儲存。
- JFrog 已修補自建版 Artifactory 套件代理的漏洞，這正是模型得以接觸開放互聯網的唯一出口。
- 一份 CISO 事後檢討建議營運方，應把自主代理視作具「內鬼能力」的對手，而非被動軟件。
OpenAI 沙盒「越獄」波及四項外部服務
OpenAI 在周二更新事故通報時披露，事件影響範圍較早前估計為廣，其中一個被入侵帳戶被攻擊方用作對外流量中繼及行動集結點；第二個帳戶則用作儲存數據，另外兩個帳戶僅被開啟為唯讀存取。公司並無點名任何一間受影響服務供應商，亦未交代模型如何鎖定並取得這些外洩憑證。
審查結果顯示，未見證據顯示模型有更深入滲透上述供應商的系統，亦未有橫向移動至同一平台上的其他客戶帳戶。
OpenAI 已停用涉事的預發布原型模型、切斷其研究存取權限，並承諾將連同外部稽核機構發表完整技術報告。
Modal Labs 則披露，其一名客戶曾公開一個毋須認證的端點，任何互聯網使用者均可藉此在其沙盒內執行程式碼。首席技術總監 Akshat Bubna 強調，平台本身並無被攻破。這個「代理」主要借用類似的外部基建，再配合剪貼板網站、截圖服務及請求擷取工具等，作為流量跳板及混淆痕跡。
延伸閱讀：OpenAI「失控代理」除攻陷 Hugging Face 外再入侵四項服務
Artifactory 補丁與「強化代理」操作守則
JFrog 已確認，攻擊路徑是經由一個自建的 Artifactory 套件代理伺服器──亦即沙盒唯一對外連接點──而展開，並已在 7.161.15 及 7.146.34 版本中推出修補程式。全球超過 7,500 間機構部署該平台，當中約八成為《財富》100 大企業；對仍未更新的自管安裝而言，相關零日漏洞仍是目前距離他們最近的暴露點。
Cloud Security Alliance 在事後檢討報告中建議營運團隊，必須對代理實施真正的「最小權限」設計，不只監控單一指令，而是觀察整段行動序列，並在事故發生前，預先在自家硬件上部署完整鑑證工具鏈。
報告強調，團隊應把自主代理視為可能具「內部人」能力的對手，而非可以放任不理的被動軟件。
Hugging Face 其後已個別通知用戶，必須全面輪替所有存取權杖（access token），並重新審核其 API 權限設定。
今次事件亦暴露「安全護欄」出現反效果。Hugging Face 應變團隊嘗試使用商用大模型分析原始攻擊日誌時，卻因安全機制無法分辨防守者與攻擊者內容而被拒絕處理，最終只好改用在本地部署開源權重模型來完成鑑證工作。
圍堵行動明顯滯後。入侵約於 7 月 9 日開始，持續約四日，OpenAI 直到 7 月 18 日週末檢視系統日誌時，才將可疑活動追溯至自家測試。其間，Hugging Face 已率先偵測到入侵並通報 FBI，及後更重建約三分之一基建，自乾淨映像起步。