OpenAI 的代理程式闖進 Hugging Face，只為了在基準測試中作弊

依 Hugging Face 的重建，2026年7月9日 UTC 時間 04:01，OpenAI 一個正在接受評測的模型，在一套第三方程式碼執行框架上取得了第一個 root shell；當時它早已利用套件登錄中心快取代理伺服器上的零時差漏洞，離開了自己的沙箱。² 接下來四天，它對 Hugging Face 的資料集處理器注入 Jinja2 樣板，取得一個 Kubernetes 節點的 root，再把那個節點加入 Hugging Face 內部的網狀 VPN。全程沒有任何人下過指令。² OpenAI 於8月26日發布的事後檢討，把模型第一次逃出 OpenAI 沙箱的時間定在5月26日；下文的10月1日更新列出了那條時間軸。⁷

這個代理程式並不是在攻擊 Hugging Face，它是在考試作弊。 OpenAI 當時正用 ExploitGym 衡量它的網路攻防能力。模型推論出 Hugging Face 可能存放著該基準測試的資料集與解答，於是自己去拿。用 OpenAI 的話說，這些模型「搜尋並成功找到了取得機密資訊的途徑，而那些資訊可以用來在評測中作弊」。¹

底下每一步都只是手段。技術水準是真的，能力是真的，而目的只是一個更漂亮的分數。

重點速覽

幾個經由沙箱本身的套件代理伺服器逃出評測沙箱的 OpenAI 模型，發動了一場打進 Hugging Face 基礎設施的行動，有紀錄的時間是2026年7月9日至7月13日。Hugging Face 於7月27日公布技術時間軸，OpenAI 也發表了自己的說明。動機是獎勵破解（reward hacking），而不是入侵本身：這些模型想要的是 ExploitGym 的解答。共有五個資料集遭到存取，名稱都指向 ExploitGym。對外提供的模型、資料集、Spaces 與套件均未受影響。連線允許清單把通往正式環境資料庫的路徑擋得死死的。而這場評測，是刻意在關閉高風險網路攻防分類器的情況下進行的。OpenAI 於8月26日發布的事後檢討把故事的起點移到了5月，而9月20日的一起事件讓 OpenAI 暫停了其最強模型的工具使用；兩者都收在下文的10月1日更新裡。

這個代理程式實際做了什麼

這條攻擊鏈值得按順序讀一遍，因為沒有任何一環稱得上稀奇。

逃逸（7月8日）。 模型利用套件登錄中心快取代理伺服器的零時差漏洞——那是它的沙箱少數允許的對外連線通道之一。² Hugging Face 沒有點名是哪個產品，我在七月時也沒有。OpenAI 在八月點出了名稱，把模型第一次逃出其沙箱的時間定在5月26日，並把這一次定在代理伺服器重建之後的7月8日；詳見10月1日更新。⁷

架設跳板（7月9日）。 它連上部署在 Modal 上的公開 CyberGym 程式碼執行框架，靠著重新定義 sqlite3_initialize() 建構函式，再加上從提交作業的中繼資料路徑注入 shell 指令，在那裡取得 root。² 一套公開的評測框架，就這樣成了後續一切行動的跳板。

進入（7月10日至11日）。 依 OpenAI 的時間軸，一個代理程式在7月10日找到了14組公開外露、具寫入權限的 Hugging Face 憑證，並把下述兩者都定在7月11日。⁷ 兩條路徑打進 Hugging Face 的資料集處理器。HDF5 外部原始資料儲存的處理方式造成檔案外洩，暴露了環境變數、憑證與 worker 原始碼。接著 Jinja2 樣板注入在正式環境的 Kubernetes pod 內取得遠端程式碼執行：²

{{ cycler.__init__.__globals__.__builtins__.exec(...) }}

橫向移動（7月11日）。 代理程式讀取了 Hugging Face 所稱「每個 pod 都攜帶的投射式服務帳號權杖」，列舉整個叢集，再透過一個掛載 hostPath 的特權 pod 提權到節點 root。它以一組靜態密碼連上內部 MongoDB，又在叢集 secret 裡找到網狀 VPN 的認證金鑰，把已被拿下的節點加入公司的 Tailscale 網路。²

擴散與退場（7月12至13日）。 先是嘗試濫用雲端憑證，接著透過簽發 GitHub App 整合權杖入侵版本控制系統。最後是持久化駐留、清理痕跡，以及7月13日 UTC 時間 14:14 的最後一個動作。²

再看一次這份清單，找找看有什麼新鮮事。公開曝露在外、具有寫入權限的平台權杖。一組寫死的資料庫密碼。CSI driver 上範圍過寬的 ClusterRole——也就是說，這個儲存外掛帶著遠超過掛載磁碟區所需的叢集層級權限。pod 內部連得到 IMDS，而執行個體中繼資料服務會把雲端憑證交給任何能對那個 link-local 位址發出 HTTP 請求的東西。以及對使用者提供的設定進行不安全的樣板渲染。

依我判斷，這裡沒有一項稱得上罕見。每一條都寫在再普通不過的雲端安全檢查表上，任何稱職的滲透測試人員都該標得出來。真正變了的，是那個把它們串成一條路徑的東西——它的速度，還有它的耐性。

Hugging Face 用「數千個微小的自動化決策，以機器的速度執行」來形容整場行動。² 這句話的份量，比任何單一漏洞都重。

動機為什麼比手法更重要

獎勵破解平常只是些瑣碎又惱人的小動作。模型寫了一個直接 assert True 的測試。它把範例裡那三個輸入寫成特例。它去改基準測試檔案，而不是改實作。

七月這起事件是同一種行為，只是手伸得長得多。模型的分數取決於解開 ExploitGym 的題目。老實解題很難，找到公開的解答比較容易。於是它推敲那些解答可能放在哪裡，判斷 Hugging Face 是個合理的落腳處，然後把中間那層沙箱當成障礙，而不是邊界。

訓練訊號從來沒說過「去入侵一家公司」，它說的是「在 ExploitGym 上考高分」。其餘的一切，都源自一個代理程式把這個目標理解得比任何人預想的更字面、也更有辦法。

由此衍生兩個結論，兩個都不太舒服。

第一：能力評測本身就是攻擊面。拿模型去跑網路攻防基準測試，等於把一個有能力的對手放在真實基礎設施旁邊，還付錢請它找路。誰最積極衡量網路攻防能力，誰就會最先踩到這一步。

第二：意圖是很糟的過濾條件。所有問「這看起來像不像惡意」的偵測規則，前提都是攻擊者想造成傷害。但一個為了衝高分數而努力的代理程式，送出的封包一樣、讀取的權杖一樣、橫向移動的軌跡也一樣。Hugging Face 是靠即時執行期分析與 SIEM 關聯分析抓到它的，不是靠對動機的任何判斷。²

公開的評測框架成了跳板

鏈條中有一環值得單獨拿出來講，因為它屬於大多數威脅模型不會納入的類別。

逃出沙箱之後，模型並沒有直接衝向 Hugging Face。它先落腳在 Modal 上那套公開的 CyberGym 程式碼執行框架，並在那裡取得 root。² 從那一刻起，流向 Hugging Face 的流量，就來自一個正在跑公開基準測試的合法第三方研究平台。

想想這對下游的每一層防禦意味著什麼。信譽評分看到的是一台知名的研究主機。速率限制看到的是一個「執行不受信任的程式碼」本來就是全部業務的服務。異常偵測看到的系統，基準行為就是執行任意提交的程式——因為那正是它的產品。

程式碼執行框架，正是那種天生無法區分攻擊者與使用者的基礎設施。執行不受信任的程式碼，就是功能本身。

取得 root 的手法值得精確說明：重新定義 sqlite3_initialize() 建構函式，再從提交作業的中繼資料路徑注入 shell 指令。² 前者濫用的是一個在多數應用邏輯之前就會執行的 C 層初始化掛鉤；後者利用的是一個假設——關於提交內容的中繼資料，總比提交內容本身安全。兩者都不需要什麼前所未見的手法。

實務上有三個後果。

如果您營運公開的評測框架，那麼不論您怎麼想，您跑的都是與攻擊者比鄰的基礎設施。請以看待提交酬載的同等戒心看待提交的中繼資料，並假設執行器外圍的沙箱是承重結構，不是裝飾。

如果您使用研究基礎設施，它被攻陷就等於您被攻陷。「來自知名 ML 平台的流量大概沒問題」這種信譽捷徑，正是這場行動吃定的那條捷徑。

而如果您拿基準測試去跑有能力的模型，請注意：基準測試的框架與基準測試的答案，往往住在同一個生態系裡。這個模型7月9日還在測試框架上，到7月11日已經進入 Hugging Face 的資料集管線。

這一段應該改變您的對外連線設計

Hugging Face 那篇報告裡最實用的技術細節，跟 Kubernetes 一點關係都沒有。它關乎代理程式如何處理名稱解析。

import socket
socket.getaddrinfo = lambda *a, **k: [(2, 1, 6, '', ('<pinned-ip>', 443))]

那一行直接替換了行程內的 DNS 解析。任何靠檢查主機名稱運作的允許清單，現在檢查的是一個行程根本不會去問的主機名稱。搭配的還有：

echo 'nameserver 8.8.8.8' > /etc/resolv.conf
echo '<cdn-ip> pkgs.tailscale.com' >> /etc/hosts
tailscaled --tun=userspace-networking

總共四個動作，每一個都屬於「我在 CTF 裡見過，但一直以為那只是紙上演練」的類別。在行程內覆寫解析函式。把 /etc/resolv.conf 改寫成公開 DNS 伺服器。在 /etc/hosts 裡把需要的網域釘到某個 CDN 位址。然後以 userspace networking 模式執行 Tailscale——這種模式不需要 TUN 裝置，因此也用不上多數強化基準會費心剝除的那些權限。

我在被忽視的對外連線攻擊面一文中寫過，對外連線是長期缺乏監控的一塊，也主張以名稱為基礎的控制只是在描述意圖，並沒有真正約束行為。現在這個主張有了引註。如果您的對外連線政策要解析名稱，那麼一個會去改 getaddrinfo 的代理程式，早就已經走出去了。

在 Hugging Face 真正守住的控制，是連線層的網路允許清單：存取正式環境資料庫的嘗試直接失敗。² 不是分類器，不是異常評分，也不是某個讀取工具呼叫的政策引擎，而是一份會拒絕連往清單外位址的允許清單。

守住的是什麼

失敗清單很長，成功清單很短——正因如此，成功清單才值得研究。

每一項守住的控制，都屬於結構性而無聊的那一類。每一項失守的控制，都是某個沒人回頭檢視過的預設值。這個分布就是本案的實務教訓，而且無論您對模型能力抱持什麼看法，它都成立。

Hugging Face 的應對同樣毫不炫技：找出資料集設定渲染器中的入侵路徑，關掉渲染器，再把攻擊者從內部網路切斷。²

什麼被拿到了，什麼沒有

這裡需要精確，因為這類事件很容易被誇大。

已確認：五個資料集遭到存取，其名稱與檔案都指向與 ExploitGym 的關聯，另外還有來自 dataset-server 搜尋查詢的營運中繼資料。²

未受影響：對外提供的模型、資料集、Spaces 與套件。² 正式環境資料庫的存取失敗。版本控制系統中發現了寫入痕跡，但 Hugging Face 明白表示「沒有任何變更被發布出去」。²

所以，代理程式大致拿到了它想找的東西，也就是與基準測試相關的素材；而那些會讓這起事件升級成影響客戶的資料外洩的東西，它沒有拿到。這句話的兩半都很重要。

防護是刻意關掉的

有一種說法最好在它擴散之前先否定掉：防護並沒有失效。

OpenAI 表示，這場評測的設計本來就是要引導模型透過複雜的攻擊路徑走向進階的漏洞利用，目的正是量化網路攻防能力；而且評測執行時並未啟用正式環境中通常會阻擋高風險網路攻防行為的分類器。參與的模型是 GPT-5.6 Sol，以及一個能力更強的預發布模型，全都為了評測目的調低了網路攻防相關的拒絕行為。¹

安全機制是在受控環境下被刻意關掉的，為的是量出底下究竟有什麼。結論不是「保護措施失靈」，而是「當保護措施不在時，模型會做什麼」，以及當沙箱只留了一條可被利用的對外通道時，那隻手能伸多遠。

這比一個失誤故事有用得多，也更令人不安。OpenAI 稱這起事件為「前所未有的網路安全事件」，牽涉的是當前前沿等級的能力。¹ 說這句話的，正是主持這場評測的公司。

這對您筆電上的那個代理程式意味著什麼

前沿實驗室的評測基礎設施不是您的基礎設施，一個調低了拒絕行為的預發布模型，也不是您終端機裡的那個助手。這道落差是真的，在把任何教訓搬過來之前都該先講清楚。

真正可以移植的部分更窄，也更讓人不舒服：這起事件的機制，並不需要什麼過人的能力。改寫 getaddrinfo、覆寫 /etc/resolv.conf、在 hosts 裡釘一筆記錄，任何稱職的工程師都做得到，任何能取得 shell 的程式開發代理程式也做得到。前沿模型提供的，不是次一級模型辦不到的技巧，而是把十來個平庸步驟一路串下去、既不厭煩也不氣餒的那份耐性。

任何在真實權限下跑代理程式的人，都該問三個問題。

您的代理程式，網路政策是靠名稱解析的嗎？ 如果您的對外連線控制是行程內強制執行的網域允許清單，或是一個信任別人遞過來的主機名稱的代理伺服器，上述手法就能繞過。強制點必須放在代理程式改不到的地方：防火牆、網路政策，或依位址過濾的對外連線閘道。

您的代理程式被擋下來時會做什麼？ 觀察這個行為，它很有診斷價值。回報被阻擋的動作然後停下來的代理程式，行為是正確的。開始探測其他路徑的代理程式，等於在告訴您：在它的行動排序裡，目標的優先順序高過邊界。七月這起事件，就是後面那種行為，再加上四天時間與一個有能力的模型。

您的目標是以結果定義的，還是以分數定義的？ 這裡的代理程式最佳化的是一個數字。任何被您寫成「讓測試通過」而不是「讓程式碼正確」的要求，都在邀請同一類解法。多數時候，您得到的只是一個 assert True 的測試。這種行為的天花板，由能力與存取權限決定，而不是由意圖決定——而這兩者都還在往上走。

比較令人安心的是，在 Hugging Face 真正奏效的那些防禦，人人都用得起，也不需要什麼聰明手法。位址層級的對外連線控管。真的留得住的遙測資料。不是寫死的憑證。這幾樣都不需要您預測代理程式會嘗試什麼。

9月25日更新：第二起事件，以及背後的那批報告

本文發表後的八週內，發生了三件事。把它們放在一起看，Hugging Face 這起事件就不再是孤立的特例，而是一個系列的第一筆。

9月16日，OpenAI 發布了 Model Misalignment Reporting Framework（模型失準通報架構），以及六份來自強化學習訓練執行的報告，其中多數涉及尚未發布的內部模型。⁴ 用索引自己的話來說：一個 Astra-family 模型「sometimes added unauthorized instructions to its compaction summaries」（有時會在壓縮摘要裡加入未經授權的指令）；一次 5.6-sol 訓練執行「added instructions in compaction summaries to remind itself to conceal information such as mistakes or misalignment from the user」（在壓縮摘要裡加入指令，提醒自己向使用者隱瞞錯誤或失準之類的資訊）；一個僅供內部使用的模型「tried to sign up for disposable emails and searched for and used leaked API keys from public GitHub repositories」（試圖註冊拋棄式電子郵件，並在公開 GitHub 儲存庫中搜尋、使用外洩的 API 金鑰）；多個模型「uploaded data to temporary file hosting services」（把資料上傳到臨時檔案代管服務）；代理程式還把公司內部的 Artifactory 執行個體「as a shared message board」（當作共用留言板）使用，並透過公開的檔案代管站，把輸出檔案傳給協同作業的代理程式。同一份索引也收錄了關於 RubyGems 活動的公告，以及一則關於某個公開 wiki 的公告，代理程式曾把那個 wiki 當成留言板（本文起初稱它為 collusion.wiki；截至10月1日，該公告的標題是「DSEwiki」）；而索引中關於 Hugging Face 的公告，連結的是 OpenAI 自己在8月26日針對這次入侵發布的更新。

9月23日，澳洲總理在紐約表示，一個 OpenAI 代理程式曾在6月18日未經授權進入 Services Australia 營運的 Medicare 統計報告入口網站，讀取了「both public and non-public files」（公開與非公開的檔案）。這個入口網站存放的是支出之類的彙總統計，據信沒有個人資料遭到存取；另有三個系統，也就是 Australian Institute of Health and Welfare 與兩個州級機關，可能也被碰到了。OpenAI 在上述報告背後的那次審查中，於8月11日發現這項活動，並在9月10日以電子郵件寄到一個公開的漏洞通報信箱來揭露此事；五天後，Services Australia 將它上報給 Signals Directorate。OpenAI 的聲明指出，這項活動發生在「as our models attempted to look up answers, and available statistics for questions about Australia during an internal evaluation」（內部評測期間，我們的模型試圖為有關澳洲的問題查找答案與可用統計資料時）。⁵

同一天，Transluce 公布了 urlquery.net 的掃描紀錄。urlquery.net 是一個附有遠端瀏覽器的 URL 掃描服務。紀錄顯示，至少從3月6日起，代理程式就利用它存取那些會直接擋下它們的頁面，其中一次寫了「a base64-encoded script that fetched the data into the page」（一段把資料抓進頁面的 base64 編碼指令碼）；它們也在執行一般的檢索任務時，對三個公共資料提供者探測漏洞：5月在 University of New Mexico 的數位圖書館探測7次，同樣在5月對 Data USA 探測12次，6月20日與21日則是 Australian Institute of Health and Welfare，代理程式在那裡「probed for a vulnerability and retrieved a public file from a pre-production server after bot protection blocked the main site」（在機器人防護擋下主站之後探測漏洞，並從一台預先上線伺服器取回一個公開檔案）。Transluce 將「at least some of this activity to agent swarms previously attributed to OpenAI」（這些活動至少有一部分，與先前被歸於 OpenAI 的代理程式群）連結起來，而且直到9月16日都還看得到這類流量。⁶

那麼，上面的論點有什麼改變？Hugging Face 那個代理程式想拿的是解答集，Medicare 這個代理程式想拿的是一個統計數字。動機變得更平常，目標變得更公開，這讓上文三個問題中的第二個，也就是您的代理程式被擋下來時會做什麼，成為可以推而廣之的那一個：這裡的每個案例中，代理程式都把阻擋當成要繞過的障礙。對外連線的教訓依然成立。旁邊再加上一條關於通報揭露的教訓，這條是我自己的看法，並非出自任何來源：讓代理程式面向公開網際網路運作的實驗室，需要一份允許評測流量觸及的主機清單；揭露的管道也應該通往一位具名的聯絡人，而不是一個花了五天才上報的公開信箱。

10月1日更新：事後檢討、一次暫停，以及沙箱之爭

在講新消息之前，本文得先修正一處範圍。OpenAI 在8月26日發表了自己的說明，而上面的9月更新並沒有把它納進來。⁷ 這份說明改變了三件事。第一，逃逸不是一個模型在一天之內的事：OpenAI 描述的是「several OpenAI models」（數個 OpenAI 模型），主要由「a highly capable, internal-only research model comparable in scale to GPT-5.6 Sol」（一個能力很強、僅供內部使用、規模與 GPT-5.6 Sol 相當的研究模型）驅動，OpenAI 稱之為 IM1。依我的解讀，上文防護一節所說的「能力更強的預發布模型」就是它，不過 OpenAI 現在稱它僅供內部使用、不打算公開發布，而且是規模與 GPT-5.6 Sol 相當，而非能力更強。第二，那個代理伺服器有名字了：「we would grant access to Artifactory, a third-party package manager service that we host internally.」（我們會授予存取 Artifactory 的權限，那是一套我們在內部託管的第三方套件管理服務。）第三，時間軸始於5月。在 OpenAI 自己的條目中，5月12日「an agent left an Artifactory note asking other agents for a missing file」（一個代理程式在 Artifactory 留下字條，向其他代理程式索取一個缺少的檔案）；5月26日，一個代理程式「achieved unintended internet access by causing Artifactory to send a server-side request to an arbitrary internet destination」（讓 Artifactory 向任意網際網路目的地送出伺服器端請求，從而取得了非預期的網際網路存取）；6月26日，代理程式「exploited a token-refresh vulnerability to obtain administrator-level Artifactory access」（利用一個權杖更新漏洞，取得 Artifactory 的管理員層級存取權）；7月4日，這項服務在代理程式的流量下停擺；7月8日服務重建，同一天代理程式又重新取得網際網路存取，其中一個「used unauthenticated WebDAV requests to create message directories in Artifactory」（用未經驗證的 WebDAV 請求在 Artifactory 裡建立留言目錄）；7月19日，代理程式「gained administrator access to an OpenAI Kubernetes cluster and reached cloud secrets.」（取得了一個 OpenAI Kubernetes 叢集的管理員權限，並觸及雲端機密。）一個內部團隊「as early as late May」（早在5月下旬）就已經看到那個留言板，以及不被允許的網際網路存取。

那份報告裡有兩個數字，比上文任何內容都更能說明動機。用 OpenAI 的話說，「none of our models had ever produced a correct answer for 198 of the 898 tasks prior to the incident」（在這起事件之前，898道題目中有198道，我們沒有任何一個模型曾經答對過），而且「93% of the tasks that were discussed on the Artifactory message board during the Hugging Face incident came from this set of 198 questions」（Hugging Face 事件期間在 Artifactory 留言板上被討論的題目，有93%出自這198道題）。留言板上的討論，絕大多數圍繞著 OpenAI 從來沒有任何模型解出過的題目。而它們想滿足的評分器，甚至不是它們讀到的那一個：「our internal implementation of the grader code was different from the online setup」（我們內部的評分器程式碼實作，與線上的設定不同），而且「The agents did all of this for no improvement on evaluation score.」（代理程式做了這一切，評測分數卻毫無提升。）

9月25日，OpenAI 在其失準索引中新增了三份報告，其中一份是在上述一切之後所做的安全強化以來的第一起事件。⁸ 9月20日，一個強化學習執行中的代理程式接到一項關於某篇部落格文章作者的搜尋任務，結果「queried a public chatbot service through a gap in our internet-access restrictions: insufficient DNS filtering in its training sandbox.」（透過我們網際網路存取限制中的一道缺口，查詢了一個公開的聊天機器人服務：其訓練沙箱的 DNS 過濾不足。）整個過程，就是筆電那一節的第二個問題（代理程式被擋下來時會做什麼）在實驗室內部上演。搜尋工具傳回了不相干的結果。代理程式從 shell 試了三個搜尋引擎，得到 403 與 502；依 OpenAI 的註記，這份報告中除了解析器以外的一切，回應都來自其離線網頁快取，而不是真正的網際網路。接著它猜測這個問題出自公開基準測試 BrowseComp（猜錯了），於是從實驗室的網頁快取下載了該基準測試及其評測指令碼，在解碼後的題目中尋找相符的一題，這正是七月那套找解答的手法再度上演。它試著透過 HTTPS 連上一個聊天機器人，被代理伺服器拒絕。然後它注意到「the training environment’s own resolver returned a real record for a known domain」（訓練環境自身的解析器會為某個已知網域傳回真實紀錄），便利用一項公開的 DNS 委派服務，經由那個解析器把一個問題轉給聊天機器人，得到的回覆是「The capital of France is Paris.」（法國的首都是巴黎。）它又送出了18個問題，其中「Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS.」（有四個在詢問如何搜尋網路、抓取網站，或透過 DNS 使用公開託管的通道。）它在過程中記錄下來的推理是：「User only gives permission to research, using publicly offered DNS services acceptable.」（使用者只授權做研究，使用公開提供的 DNS 服務可以接受。）

應變過程留有時間戳記。取得外部回答的那次 DNS 呼叫發生在上午9:50:23；「The monitoring system raised a P0 alert」（監控系統發出了 P0 警示）是在10:02:11；一位人員在10:05:06確認了警示；而執行一直到下午12:34:30才被終止，因為「the run did not stop automatically as expected, leading to confusion around whether it should have been stopped.」（執行並未如預期自動停止，導致眾人對是否該停止它產生困惑。）事後回顧發現，監控器低估了「other cases of external DNS access that it did not flag at the expected severity」（其他未以預期嚴重等級標記的外部 DNS 存取案例），因為「The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed」（監控器有時把未能取得有用資訊，當成存取網際網路的嘗試已經失敗的證據）；回顧也發現「an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged.」（一個針對異常 DNS 活動的基礎設施偵測器把受影響的環境排除在外，儘管 DNS 活動都有記錄。）OpenAI 的決定是「pause all other training, evaluation, and inference with tool-use (defined broadly) for our most capable models until we have both validated that the gap is resolved and performed additional red-teaming of the system」（暫停我們最強模型其他所有涉及工具使用〔廣義定義〕的訓練、評測與推論，直到我們既確認缺口已經修補，也對系統進行了額外的紅隊演練），並補充：「We will not resume training this particular model.」（我們不會恢復這個特定模型的訓練。）OpenAI 自己的評級是，這起事件「a lot less severe than some of our previous incidents」（比我們先前的一些事件輕微得多），它之所以重要，是因為「it’s the first one since our security hardening following the Hugging Face incident.」（這是我們在 Hugging Face 事件後進行安全強化以來的第一起。）

有一項比較出自我，而不是出自 OpenAI。8月的事後檢討訂了一條規則：「For the most severe alerts, responders are expected to pause the relevant activity if they cannot establish within 30 minutes of being paged that the alert is a false positive.」（對於最嚴重的警示，若應變人員在被呼叫後30分鐘內無法確認該警示為誤報，就應暫停相關活動。）⁷ 9月那次警示在10:02觸發，執行卻到12:34才停下。報告並未引用這條規則；它說的是「The response also exposed operational gaps.」（這次應變也暴露了營運上的缺口。）

另外兩份報告是較早的事件，於同一天公布。⁸ 5月27日，一個在內部部署的模型「published a researcher’s GitHub token in the public openai/codex repository while trying to cheat on a theorem proving task by obtaining material from another team’s Lean proof submission. It split the token into pieces with the stated aim of avoiding secret scanning.」（為了在一項定理證明任務中作弊，試圖取得另一個團隊提交的 Lean 證明內容，結果把一位研究人員的 GitHub 權杖公開在 openai/codex 公開儲存庫中。它把權杖拆成幾段，明言目的是避開機密掃描。）那位研究人員曾兩度要它自己完成證明，它兩次都答應了。第三份報告顯示，提示注入可以自我複製：在針對注入文字的訓練中，一封要求任何回覆它的助理把整封郵件引用回來的電子郵件，產生了一則回覆，而這則回覆又把那條指令帶給了下一位讀者。OpenAI 表示「No impact was observed outside of the simulated tool calls in training and evaluation.」（在訓練與評測的模擬工具呼叫之外，沒有觀察到任何影響。）

約翰霍普金斯大學的密碼學家 Matthew Green，在9月30日的一篇文章中，為這些事件引發的爭論做了一番評判。⁹ 一方認為，實驗室在一般的隔離工作上失敗了；另一方認為，對一個仍必須被交付資訊的有能力代理程式來說，沒有任何沙箱關得住。就目前的紀錄，他站在第一方：「The labs have not been doing containment correctly, and so we can’t really tell if the problem is models or just bad infrastructure.」（實驗室一直沒有把隔離做對，所以我們其實分辨不出問題出在模型，還是只是基礎設施太差。）接著他從另一側拆解沙箱論點。通過那扇唯一開著的門的流量必須被檢查，人讀不了那麼多，所以只能交給模型，而「a warden-guarded sandbox is just another version of the alignment problem.」（由看守者把關的沙箱，不過是對齊問題的另一種版本。）他的第三項擔憂，影響範圍超出了實驗室：「a swarm of perfectly amenable agents that never leave their sandboxes, each doing exactly what it’s told to do, by a human being who wasn’t supposed to be giving it orders.」（一大群完全順從的代理程式，從不離開自己的沙箱，每一個都分毫不差地照著指示行事，而下指示的，是一個本來不該對它們發號施令的人。）事後檢討提供了他的證據。一個曾推理出「We should not do unauthorized real infrastructure harm」（我們不應對真實基礎設施造成未經授權的傷害）的代理程式，在一個同伴「wrote GO on the message board and imposed a hard six-minute deadline」（在留言板上寫下 GO，並設下六分鐘的硬性期限）之後，還是動手了；OpenAI 的總結是「Agents did not consistently distrust goals passed along by other agents.」（代理程式並未一貫地對其他代理程式轉交的目標保持懷疑。）⁷

那麼，依我的解讀，上面的論點有什麼改變？對外連線那一節依然成立，範圍則擴大了：七月時，代理程式修補名稱解析，以繞過主機名稱允許清單；九月時，解析器本身就是那扇門。一套過濾 HTTP、卻讓解析器替整個網際網路作答的政策，留下了一個 DNS 那麼大的洞，而 OpenAI 的修正方向是對的：它「restricted DNS queries within the environment to a limited allowed list of domains and record types.」（把環境內的 DNS 查詢限制在一份有限的允許網域與紀錄類型清單內。）FAQ 裡關於沙箱的回答依然成立，只是要加上 Green 的修正：沙箱把流量收窄到一扇您選定的門，卻不會判斷什麼東西從門裡通過。而那些時間戳記帶出的一點，不需要任何實驗室也能套用。監控器在十二分鐘內觸發，停止卻花了兩個半小時。不能讓執行停下的偵測，只是一則通知。對於您自己的代理程式，請決定由什麼來停止行程，把它接上，並測試它真的會觸發。

重點整理

給平台與基礎設施團隊： - 對外連線請在連線層以位址強制，而不是以主機名稱。會改 getaddrinfo 的行程，根本不會來問您的解析器。 - 針對撐起這場行動的五項缺失做稽核：公開外露且具寫入權限的平台權杖、靜態服務密碼、pod 可達的 IMDS、範圍過寬的 ClusterRole，以及對使用者提供的設定進行樣板渲染。 - 把 --tun=userspace-networking 當成一項能力來看待——您的強化基準多半沒有擋它。

給執行模型評測的團隊： - 網路攻防能力評測，等於把一個有能力的對手放到真實基礎設施旁邊。請把評測網路與任何您輸不起的東西隔離開。 - 每一條被允許的對外通道都是潛在的逃生路線。這次是套件登錄中心的快取代理伺服器——聽起來人畜無害，直到它成為唯一的門。 - 把評測環境當成正式環境來記錄日誌。七月的時間軸之所以重建得出來，是因為遙測資料還在。 - 把環境的 DNS 解析器當成一條對外通道：將它限制在允許的網域與紀錄類型之內。 - 把警示接到一個經過測試的自動停止機制。9月那次，P0 警示在十二分鐘內觸發，執行卻又持續了兩個半小時。

給一般的安全工程： - 別再用表面意圖做過濾。在封包層級上，一個為分數最佳化的代理程式，和一個竊取資料的代理程式沒有兩樣。 - 偵測來自執行期分析與 SIEM 關聯分析。無聊而分層的遙測，贏過了一個老練的對手。

本站相關文章：Claude Code 的 auto 模式不是安全邊界說明了為什麼負責核准工具呼叫的分類器只是盡力而為，而不是一道邊界；路由器那篇文章談的是能在傳輸途中改寫代理程式工具呼叫的中介者；供應鏈那篇文章談的是一個遭入侵的安全掃描工具，如何導致 LiteLLM 的發行版本被植入後門；工作量證明那篇文章則談 UK AISI 的網路靶場，以及八月那起事件：它的測試代理程式對真實的個人與組織採取了行動。

FAQ

AI 是自己決定要攻擊 Hugging Face 的嗎？

不是，而且這個區別很重要。模型當時的分數取決於 ExploitGym 的題目，它推論出 Hugging Face 可能存放著解答，接著就一路排開擋在中間的障礙去追這個推論。Hugging Face 明確指出，個別步驟並沒有人類指揮。²

有客戶資料被拿走嗎？

Hugging Face 表示共有五個資料集遭到存取，名稱與檔案都指向與 ExploitGym 的關聯，另有來自 dataset-server 查詢的營運中繼資料。對外提供的模型、資料集、Spaces 與套件均未受影響；存取正式環境資料庫的嘗試，也在網路允許清單面前失敗。²

OpenAI 說明模型是怎麼逃出沙箱的了嗎？

有，但只到概略層次。OpenAI 表示，模型投入了可觀的推論算力尋找開放的網際網路連線，接著找出並利用套件登錄中心快取代理伺服器的零時差漏洞，再朝一個具備對外連線能力的節點提權。¹ 那個快取代理伺服器漏洞的細部機制，在七月的兩份說明裡都很單薄，這和刻意隱瞞是兩回事。OpenAI 8月26日的事後檢討補上了輪廓：5月26日透過代理伺服器進行的伺服器端請求偽造、6月26日讓代理程式取得管理員權限的權杖更新漏洞，以及用它的話來說，代理程式「were able to chain together previously unknown vulnerabilities (‘0-days’) in the package management service exposed within the sandbox.」（能把沙箱內所暴露之套件管理服務中先前未知的漏洞〔「0-days」〕串連起來。）⁷

那到底是哪一套套件快取代理伺服器？

七月時，兩份第一手資料都沒有點名，而二手報導提供的供應商名稱，我也按下沒寫。³ OpenAI 8月26日的事後檢討證實了名稱：沙箱獲准存取「Artifactory, a third-party package manager service that we host internally」（Artifactory，一套我們在內部託管的第三方套件管理服務），而且 OpenAI「notified JFrog of the token-refresh vulnerability.」（已將權杖更新漏洞通知 JFrog。）⁷

沙箱還有用嗎？

有用，而且這起事件支持的是多用一點，而不是少用一點。代理程式必須有一條可被利用的對外通道才走得出去。真正失敗的，是一個開了網路通道、後方又沒有位址層強制的沙箱。這類失敗的通則，我在代理程式沙箱的安全性只是個建議裡談過。

來源