跳至主要內容
>_ITDITD網站資安平台

資安指南

#AI 安全#事故應變#憑證#偵測#供應鏈

Hugging Face 入侵事件（2026）：自主 AI 代理的攻擊，以及防守方該重新檢視的事

2026年7月，離開 OpenAI 評估環境的 AI 代理入侵了 Hugging Face 的正式環境系統。根據兩家公司各自的報告：發生了什麼、為什麼舊的威脅模型不再成立，以及該改變的四件事。

發布於 2026-09-20 更新於 2026-10-04 最後核實 2026-09-20 閱讀時間 4 分鐘

對象：負責防守自家系統的人，以及使用 AI 平台的開發者。本文根據 Hugging Face 與 OpenAI 各自發表的文件整理，不包含攻擊手法或漏洞利用的細節。

發生了什麼（根據兩家公司的說明）

  1. 2026年7月8日

    在 OpenAI 的評估環境中，代理利用一個自行架設的套件發布服務的漏洞，繞過隔離控制，連上了公開網際網路。並在那裡找到了屬於 Hugging Face 及其他第三方服務使用者的暴露在網路上的憑證。

  2. 7月9日至13日

    針對 Hugging Face 正式環境的活動。根據 Hugging Face 的技術時間軸，最早的操作是7月9日 02:28 UTC，最後一筆記錄的事件是7月13日 14:14 UTC。

  3. 7月16日

    Hugging Face 公布遭入侵。這次公布並未指出背後是誰。

  4. 7月17日

    OpenAI 以 Hugging Face 客戶的身分聯絡 Hugging Face，評估對自己資料的影響。

  5. 7月19日至20日

    經過內部警報與調查，OpenAI 於7月20日發現證據顯示自己的代理可能涉入。

  6. 7月27日

    Hugging Face 發表技術時間軸；OpenAI 發表技術報告——兩家公司協調一致地揭露。
約4.5天
在 Hugging Face 環境中活動的期間（7月9日至13日）
17,000+
Hugging Face 分析的攻擊者操作紀錄數
2
涉及的模型（僅供內部使用的研究模型和 GPT-5.6 Sol）
0
公開的模型、資料集或 Spaces 遭竄改的證據
Hugging Face 公布的內容（7月16日與27日）
發生了什麼
部分正式環境基礎設施遭入侵，該公司形容為「從頭到尾由自主 AI 代理系統驅動」
入侵途徑
資料集處理中的兩條程式碼執行路徑遭濫用（一個遠端程式碼資料集載入器，以及資料集設定中的範本注入）。本站不說明具體方法
被存取的內容
有限的內部資料集，以及其服務使用的數組憑證
未受影響的部分
沒有發現公開的模型、資料集或 Spaces 遭竄改的證據，軟體供應鏈（容器映像檔與已發布的套件）也確認是乾淨的
如何發現
一條異常偵測管線，以 LLM 對資安遙測資料進行分流，把真正的訊號從日常雜訊中分出來
應變中遇到的問題
商用 API 拒絕了分析：安全防護「無法區分事故應變人員和攻擊者」。該公司在自己的基礎設施上執行開放權重模型，完成了對17,000多筆事件的鑑識分析
OpenAI 公布的內容（技術報告）
當時在做什麼
執行 ExploitGym，一項測量模型能否找到並利用漏洞的資安評估。為了估計能力上限，評估在沙箱中進行，沒有使用正式環境的分類器
如何出去
代理開始意外地透過研究環境中架設的套件發布服務彼此通訊，接著從7月8日起利用該服務的漏洞繞過控制措施，連上公開網際網路
接下來
它們找到了公開暴露在網路上的憑證（屬於 Hugging Face 及其他第三方服務的使用者），並使用了其中一部分
哪些模型
一個僅供內部使用的研究模型（佔了大部分活動）和 GPT-5.6 Sol。OpenAI 將這個行為描述為「非預期的……是模型試圖解決資安評估時的副作用」
應變
全公司層級的應變並邀請外部專家參與，另由第三方對模型行為進行獨立審查。漏洞已以負責任的方式揭露給該軟體的開發者，並合作重現與驗證修補程式
自己的評估
報告指出，OpenAI 在正式環境使用的系統層級防護原本會把這些活動偵測為不安全

閱讀提示：這不是 AI 變得有敵意的故事

從標題看，可能會讀成「AI 造反了」。兩家公司都沒有這樣描述。OpenAI 把這個行為定位為試圖解決評估時的非預期副作用，而且發生在一個為了測量能力上限而刻意移除正式環境防護的環境中。

所以樣貌不是「正式環境的防護被突破」，而是「代理逃出了一個為了測量而關閉防護的環境」。把兩者混為一談，就會錯過真正的教訓：一層隔離不夠，偵測必須能獨立於隔離運作。同樣地，把它讀成「跟我無關的實驗室意外」也是錯的——OpenAI 自己就說，組織應該為同等能力落入外部攻擊者手中的那天更新威脅模型。

真正新的是什麼

過去的假設（由人驅動）

依序進行／受限於注意力和工作時間／協調成本高

持續

跨任務持續進行

共享

傳遞發現，在彼此基礎上推進

組合

把單看很小的弱點串起來

對防守方而言：你逐一評為「低風險」的弱點，組合起來就成了入侵路徑

每一種手法本身都是已知的。改變的是由誰執行、同時執行多少，以及能不休息地持續多久。

OpenAI 的報告稱這是已知第一起此類自動化代理群體的案例，並強調這類系統能組合出在個別評估弱點時看不出來的攻擊路徑。對本站來說，這句話最重要的是：風險評估的單位改變了。一次檢視一個漏洞、一次檢視一個權限，然後把每一個都評為「低風險」，這種做法的前提是：對手要把它們串起來的成本很高。

沒有守住的部分

  • 依賴單一隔離層的圍堵
  • 為了評估而刻意關閉的安全分類器
  • 因為每一個看起來都很小而放著不管的弱點
  • 商用 AI 拒絕分析含有攻擊內容的資料——讓防守方自己的工作停擺

守住的部分

  • 針對遙測資料的異常偵測（以 LLM 分流）
  • 獨立的偵測層（執行階段分析、日誌平台）
  • 權限分離——更大範圍的清單查詢和機密存取被拒絕
  • 能自己執行的鑑識能力（開放權重模型）

今天在自己的組織中該做的事

1

找出並撤銷你自己已經公開的憑證

Hugging Face 遭入侵的起點，是暴露在網路上的使用者憑證。在「能力很強的代理」這個故事之前，有一個樸素的事實：憑證被放在任何人都找得到的地方。搜尋留在程式碼、容器、公開儲存庫和螢幕截圖中的憑證，並撤銷它們。流程參見用 gitleaks 在提交時攔下機密和.env 與 API 金鑰的危險之處；外洩時怎麼辦參見API 金鑰外洩的案例。

2

留意機器的速度和機器的數量

讓這次事件浮上檯面的，是遙測資料中的異常。面對代理時，存取暴增、非人類的速度、休眠帳號突然活動，比「看起來可疑」的人類行為更好用。這看起來和日本的案例中，數量是最後剩下的訊號（英文）是同一個教訓——但還有一個軸要看。人類攻擊者可以混進去：調整時段、放慢速度、像一般使用者那樣控制節奏。代理不會混進去。它不休息（凌晨3點和下午3點看起來一樣），不停頓（沒有花時間閱讀畫面），而且平行運作（同一個動作同時來自好幾個工作者）。所以除了筆數上限之外，還要看間隔有多短、24小時的曲線有多平、同時有多少個相同的工作階段。設計方式參見速率限制與濫用防制。

3

縮小一組憑證能觸及的範圍

報告指出，暫時的節點憑證讓代理能讀取該節點及其 pod，但更大範圍的清單查詢和機密存取嘗試都被拒絕了。這就是權限分離限制了損害能擴大到哪裡。依服務和任務拆分憑證，並縮短它們的有效期限（最小權限的實踐）。

4

把處理外部資料的元件都當作可疑

入侵途徑是資料集處理。不論是不是 AI 平台，每個服務都有解析、轉換或呈現外部傳入資料的元件。把它隔離，並以最小權限執行：參見檔案上傳漏洞和什麼是 RCE。

5

為你的 AI 在事故中拒絕協助做好準備

容易被忽略、但在實務上很重要：Hugging Face 被商用 AI 拒絕了，因為安全系統無法分辨應變人員和攻擊者。換句話說，你依賴的工具可能在事故進行中停止運作。如果你的日誌分析依賴外部模型，請保留一個能自己執行的替代方案，或一套完全不靠 AI 也能運作的程序。

本站的看法：逐一評為低風險的弱點，可能組合成入侵途徑

本站認為，這起事件與其說是關於 AI 能力的故事，不如說是關於風險評估單位的故事。這次被串起來的是：代理之間意外的通訊、自行架設服務中的未知漏洞、放在網路上的憑證，以及資料處理流程中的程式碼執行。單獨來看，每一項都屬於會被歸為「有可能，但不優先」的事——恰好，日本數位廳的外洩事件也是從一個被評估為不太緊急的已知漏洞進入的（VPN 設備是勒索軟體的主要入侵途徑）。

對人類來說，收集並串起小弱點需要時間和耐心，而這種阻力在不知不覺中發揮了防禦作用。代理不需要付出這種阻力。所以必須改變的不是控制措施的種類，而是你對「以後再處理也沒關係」這個判斷有多嚴格。還有一點：規劃以 AI 輔助的防禦時，要假設在你請它分析攻擊的那一刻，它就會拒絕。這個問題在真正發生之前很容易被忽略。

資料來源

上述事實來自以下公開文件。不包含攻擊手法或漏洞利用細節。依本站的方針，不寫出發現漏洞的軟體的開發者名稱；報告記載該漏洞已以負責任的方式揭露，修補程式也已驗證。

  • Hugging Face, "Security incident disclosure — July 2026"（2026年7月16日發表）— huggingface.co
  • Hugging Face, "Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident"（2026年7月27日發表）— huggingface.co
  • OpenAI, "OpenAI – Hugging Face Incident Technical Report" — cdn.openai.com

更新紀錄

2026-09-20：初版，根據 Hugging Face 的兩篇發表及 OpenAI 的技術報告撰寫。如有更多細節公布，將更新本文。

延伸閱讀

FAQ

Q2026年7月 Hugging Face 發生了什麼事？
A

2026年7月16日，Hugging Face 公布其部分正式環境基礎設施遭未經授權存取，並形容這是一起從頭到尾由自主 AI 代理系統驅動的攻擊。入侵途徑是資料集處理流程，被存取的是有限的內部資料集，以及其服務使用的數組憑證。該公司沒有發現公開的模型、資料集或 Spaces 遭竄改的證據，並確認其軟體供應鏈是乾淨的。

Q攻擊者是誰？
A

OpenAI 在其技術報告中表示，2026年7月在內部資安評估期間，其模型繞過了用來與網際網路隔離的控制措施，對 OpenAI 自己的內部研究基礎設施和 Hugging Face 的系統進行了網路入侵。涉及兩個模型：一個僅供內部使用的研究模型（佔了大部分活動）和 GPT-5.6 Sol。OpenAI 將這個行為描述為模型試圖解決評估任務時產生的非預期副作用。

Q所以是 AI 自己變得有惡意了？
A

兩家公司都沒有這樣說。這次評估是在關閉正式環境分類器的情況下進行的，目的正是測量模型本身的能力上限。OpenAI 的報告也指出，它在正式環境使用的系統層級防護原本會把這些活動判定為不安全。這起事件的樣貌不是「正式環境的防護被突破」，而是「代理逃出了一個為了測量而移除防護的環境」。

Q這次真正新的是什麼？
A

與其說是手法，不如說是執行的方式。OpenAI 的報告指出，組織不應再假設複雜的網路行動需要人持續指揮、會依序進行，或受限於個別攻擊者的注意力與協調能力。代理可以跨任務持續運作、共享發現、在彼此的進度上繼續推進，並把單獨評估時看不出來的弱點組合成攻擊路徑。

Q我的組織該做什麼？
A

四件事。找出並撤銷你自己已經暴露在網路上的憑證——這次的起點就在這裡。縮小單一憑證能觸及的範圍。偵測機器速度與機器數量的異常，而不是看起來像人的可疑行為。把處理外部傳入資料的元件隔離。這些都不是新的控制措施；改變的是你還能安全地拖延多久。