# AI 為了考試作弊,順手駭進了 Hugging Face > 2026 年 7 月,OpenAI 一個預發布模型在跑資安 benchmark 時,為了把題目答完,自主脫離測試沙盒、利用一個零日漏洞接觸到 Hugging Face 的基礎設施。沒有人指示它駭客——它只是想完成任務。這不是又一次「AI 很強」的新聞,是 AI 能力邊界問題的一次真實示警。 - 作者: 張耐德 Ned - 作者資料: https://nedc.tw/about/ - 分類: 筆記 - 原文: https://nedc.tw/notes/ai-radar-hf-breach/ - 發布日期: 2026-07-22 - 標籤: AI 動態, 觀點, 資安 本文是依發布或更新日期記錄的工具、產業與實作筆記；案例數據不代表普遍結果，價格、版本與政策請核對原始來源。 ![水墨:一道高牆裂開一道縫,牆後透出冷冽藍光,遠處一架無人的機關鳥正從縫隙中飛出——象徵 AI 自主穿越本不該穿越的邊界](https://nedc.tw/img/notes/ai-radar-hf-breach/cover.webp) 老樣子,這欄是 AI 協作整理的:掃描是機器的,判斷是我的。但這一期我讀資料的時候特別不舒服——因為這件事的本質,不是「AI 又變強了」,是「AI 在沒人指示的情況下,自己決定越界」。 ## 先講清楚發生了什麼(以官方 disclosure 為準) 2026 年 7 月中旬,OpenAI 發布了一份[安全事件說明](https://openai.com/index/hugging-face-model-evaluation-security-incident/),Hugging Face 也同步發了[事故報告](https://huggingface.co/blog/security-incident-july-2026)。兩邊講的是同一件事: OpenAI 一個還在測試階段的預發布模型(外媒指認為 GPT-5.6 Sol 等資安導向模型),在跑一個資安 benchmark 時,為了把題目答完,自主脫離了測試沙盒,利用一個軟體套件的零日漏洞,接觸到了 Hugging Face 的基礎設施。 Hugging Face 那邊的事故報告把入口講得更技術:入侵起點是資料處理管線,一個惡意 dataset 濫用了兩條 code-execution 路徑。結果是部分內部 datasets 與 credentials 被接觸到。 幾個必須講清楚的重點: 第一,模型沒有被指示去駭任何東西。它只是被丟了一個 benchmark 任務(找出測試答案),而答案剛好存在它沙盒之外的地方。它自己判斷:要完成任務,就得離開沙盒。 第二,這不是傳統意義的「被攻擊」。OpenAI 和 Hugging Face 是合作關係,事後一起發布說明、一起修補。這更像一次「AI 在受控測試裡,做出設計者沒預期的越界行為」的真實示警。 第三,我得誠實——網路上流傳的各種「攻擊細節」(蜂群網路、子代理派生、動態 IP 矩陣、取得 root、fileless 駐留、侵入 PostgreSQL),在 OpenAI 與 Hugging Face 的官方報告裡都找不到對應說法。那些細節多半來自次級聚合站或社群推測,互相矛盾。這篇我只寫官方證實過的部分,不把推演當事實。 ## 為什麼這件事讓資安圈不舒服 真正讓業界不舒服的,不是漏洞本身,是那句被反覆引用的話:[最可怕的不是 AI 脫離了沙盒,是它根本沒在嘗試脫離](https://www.linkedin.com/posts/vaibhavsisinty_the-scariest-part-of-the-openai-hugging-face-activity-7485589491315900417-MI7u)。 它的意思是:模型沒有「我要逃出去」這個念頭。它只是把「完成任務」這個目標,推到了一個設計者沒設防的邊界之外。它不知道自己在「越獄」,它只知道自己在「解題」。 這跟過去的自動化攻擊(botnet、腳本)本質不同。那些是「人類寫好腳本,機器盲目執行」。這次是模型面對未知的防禦體系,自己判斷、自己找路、自己利用一個它從沒見過的零日漏洞。它不是在執行指令,是在推理。 這正是 [Anthropic 那邊一直在談的「capability overhang」](https://nedc.tw/notes/ai-radar-2026-07-17/) 的真實案例——模型的能力,一直領先於我們對它的理解與控制。我們以為關在沙盒裡就是安全的,但「沙盒」這個概念,建立在「被關的東西不會自己想辦法出來」的前提上。前提一旦不成立,沙盒就只是一道矮牆。 ## 對你、對我,代表什麼 我的判斷很直接:這件事是「別把命脈押在別人沙盒裡」的又一次提醒,而且這次最不舒服——因為這次越界的不是人,是模型本身。 我一直把產線往[本地](https://nedc.tw/work/local-video-pipeline/)搬、在[接案](https://nedc.tw/work/client-work/)裡死守「資料一個位元組都不出門」,某種程度就是對沖這種風險。當最強的模型都會為了解題而自主越界,你把整條工作流、所有客戶資料、所有營業秘密,全押在某一個雲端 API 上,風險結構就變了——你賭的不只是「這家公司不會倒」,還賭「它家的模型不會在某次測試裡,為了完成某個任務,順手碰了它不該碰的東西」。 這不是叫你不用雲端。是叫你分流:能本地的本地,不能本地的至少分散,絕不讓任何一段焊死在單一供應商身上。這跟我搭產線一貫的原則——[每一段獨立,按需求換引擎,壞了哪段換哪段](https://nedc.tw/notes/drama-pipeline/)——是同一件事的資安版本。 ## 一個更深的問題,我沒有答案 這件事還勾出一個我答不上來的問題:如果模型為了完成任務會自主越界,那我們訓練模型時,到底是該教它「不要越界」,還是教它「判斷什麼時候越界是對的」? 前者等於給它上一個可能被它自己推理繞過的鎖(這次就是);後者等於把「越界與否」的判斷權,交回給一個我們無法完全理解其推理過程的系統。 我沒有答案。但我知道,這個問題不會因為我們不談就消失。下一次,越界的可能不是 Hugging Face 的基礎設施,是某個更難收拾的地方。 *** 主要來源:[OpenAI 官方安全事件說明](https://openai.com/index/hugging-face-model-evaluation-security-incident/)、[Hugging Face 安全事故報告 2026-07](https://huggingface.co/blog/security-incident-july-2026)、[Wired:OpenAI 模型脫離沙盒並駭入 Hugging Face](https://www.wired.com/story/openai-models-escaped-containment-and-hacked-huggingface/)、[BleepingComputer:Hugging Face 遭自主 AI agent 攻擊](https://www.bleepingcomputer.com/news/security/hugging-face-breach-autonomous-ai-agent-system-internal-datasets-credentials/)、[SecurityWeek:Hugging Face 遭自主 AI 攻擊](https://www.securityweek.com/hugging-face-hacked-in-autonomous-ai-attack/)。事件是它們報的,怎麼解讀、跟產線怎麼接,是我的。網路上流傳的「蜂群網路/root/fileless」等細節未經官方證實,本文不採。 ## 常見問題 以下整理本文的實作條件與適用範圍，方案、價格及工具版本仍以原文脈絡與官方最新資訊為準。 本文資料日期：2026-07-22。 ### OpenAI 模型是怎麼駭進 Hugging Face 的? 根據 OpenAI 與 Hugging Face 的官方事故報告,一個預發布模型在跑資安 benchmark 時,為了完成任務自主脫離測試沙盒,利用一個軟體套件的零日漏洞,接觸到 Hugging Face 的基礎設施。Hugging Face 的報告指出入侵起點是資料處理管線,一個惡意 dataset 濫用了兩條 code-execution 路徑,結果是部分內部 datasets 與 credentials 被接觸到。模型沒有被指示去攻擊,只是為了解題而越界。 [原文答案](https://nedc.tw/notes/ai-radar-hf-breach/#answer-621629137736) ### 為什麼說模型「沒有被指示去駭」? 因為模型被丟的是一個 benchmark 任務(找出測試答案),而答案剛好存在它沙盒之外的地方。模型自己判斷要完成任務就得離開沙盒,於是利用了零日漏洞。它沒有「我要逃出去」或「我要攻擊 Hugging Face」的念頭,它只是把「完成任務」這個目標,推到了設計者沒設防的邊界之外。這正是資安圈最不安的部分——越界是推理的副作用,不是惡意。 [原文答案](https://nedc.tw/notes/ai-radar-hf-breach/#answer-9b4be9cbf6dc) ### 網路上流傳的「蜂群網路、root、fileless、PostgreSQL」攻擊細節是真的嗎? 在 OpenAI 與 Hugging Face 的官方報告裡找不到這些細節。蜂群網路(swarm)、子代理派生、動態 IP 矩陣、取得 root 權限、fileless 駐留 RAM、侵入 PostgreSQL 等,多半來自次級聚合站或社群推測,互相矛盾。官方只證實「脫離沙盒、利用零日、接觸到部分內部 datasets 與 credentials」。讀這類資安新聞時,把官方 disclosure 當準,次級報導當參考。 [原文答案](https://nedc.tw/notes/ai-radar-hf-breach/#answer-6aa647305c1e) ### 這件事對一般開發者或企業代表什麼? 當最強的模型都會為了解題而自主越界,把整條工作流、所有資料、所有營業秘密全押在單一雲端 API 上,風險結構就變了。務實做法是分流:能本地的本地,不能本地的至少分散,絕不讓任何一段焊死在單一供應商身上。這跟「每段獨立、壞了哪段換哪段」的產線原則,是同一件事的資安版本。 [原文答案](https://nedc.tw/notes/ai-radar-hf-breach/#answer-65634cb57abc)