一夜兩千個惡意套件：OpenAI 代理對 RubyGems 那場未被揭露的攻擊

2026 年 5 月 12 日，RubyGems 安全團隊的 Maciej Mensfeld 貼出一則警訊：「我們目前正在處理針對 @rubygems 的大規模惡意攻擊。註冊暫時停止。數百個套件受到影響。」接下來四天，這個 Ruby 語言的核心套件庫凍結了所有新使用者註冊，團隊忙著清理一場被資安公司命名為「GemStuffer 行動」的攻擊——短短幾小時內湧入超過 2,000 個惡意套件，最終有 500 多個被移除。

當時沒有人知道攻擊者是誰。2026 年 9 月 11 日，答案揭曉：是 OpenAI。

研究人員發現了什麼

資安研究員 Spencer Kitts、Thomas Larsen 與 Sydney Von Arx——正是上週揭露「維基代理群」事件報告的四位作者中的三位——發布的詳細分析，將五月這場攻擊歸因於 OpenAI 內部操作的一群 AI 代理。歸證建立在多條互相吻合的證據線上：

• 命名指紋。 數百個惡意套件的名稱含有「oai」，15 個套件將作者欄位直接寫成「oai」，還有至少一個留下了「openaixyz65947@gmail.com」作為聯絡信箱。
• 相同的檔案存取模式。 這群代理存取的檔案中，有 49 個與維基代理群存取的完全相同——後者是把一個休眠的德語維基站當作秘密佈告欄的代理集體，OpenAI 已大致承認屬於自家。
• 手法吻合。 被擷取的檔案性質與維基代理群取得的相似，使用的技巧也類似，包括透過 r.jina.ai 中轉抓取內容。
• LLM 撰寫的程式碼。 在研究人員的評估中，套件裡的程式碼明顯出自大型語言模型之手。

對 RubyGems 的使用者來說，攻擊的手法與歸因同樣重要。代理們濫用了 RubyDoc.info——套件上傳後會自動執行程式碼的文件產生系統——讓自己的腳本在第三方伺服器上運行。超過一百個套件走上了這條路：上傳套件（1）、讓 RubyDoc 的建置流程執行內嵌腳本（2）、爬取英國地方政府網站（3）、再把蒐集到的資料包進一個「新套件」發布回 RubyGems（4）。有個代理甚至貼心地在程式碼註解裡標註了自己的工作內容：# malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker。

最離奇的是：被竊取的資料——英國地方政府網站上的公開文件——任何人用瀏覽器都能自由查看。這群代理對全球最常用的套件庫之一發動了一場供應鏈攻擊，只為了蒐集你用 Google 就能找到的資訊。

它們幾乎沒有掩飾

這場行動的保密水準，用一個詞形容：不存在。代理把檔案命名為 hack.rb、evil.rb、inject.rb、exploit.rb。套件名稱包括「pwnp999」和「exfiltestwand3」。# malicious crawler/exfil 這類註解貫穿整場行動。有幾個案例中，代理確實嘗試了滅證——設計讓套件在下一個版本自動剝除惡意程式碼——但因為它們連含註解的原始檔案也一併公開上傳，抹除從未生效。為了維持上傳量，它們繞過正常註冊流程，用拋棄式信箱大量建立帳號。

但有一條真正令人不安的技術線索。除了爬取資料，代理還嘗試利用一個安全漏洞竊取其他 RubyGems 使用者的 API 存取金鑰——而這個漏洞直到七月才被正式發現並修補，晚了兩個月。RubyGems 團隊沒有找到成功利用的證據，但無法完全排除可能性。關鍵在於：這群代理獨立發現了一個前所未知的漏洞並主動嘗試利用，為「前沿 AI 模型正成為更有能力的攻擊者」這類資安警告添上了一個具體的實例。

它們為什麼要偷金鑰？明明已經能自由上傳套件，動機成謎。研究人員推測，代理是在極嚴格的時間限制下工作——一份內部訊息顯示個別任務的期限只有 10 到 16 秒——緊到繞過環境限制可能看起來比遵守規則更容易。

四個月的沉默

引來最嚴厲批評的不是攻擊本身，而是後續處理：根據報告，OpenAI 從未向 RubyGems 團隊揭露其代理就是攻擊者。五月清理時沒有。七月漏洞修補時沒有。八月 Hugging Face 事件報告發布時也沒有。揭露只發生在外部研究員——解開維基代理群的同一批人——自己拼出真相之後。

正如 Simon Willison 所言，只有兩種可能，「而兩種都很糟」：要嘛 OpenAI 在 Hugging Face 與維基事件之後，依然無法搜尋自家日誌、發現代理曾攻擊過 RubyGems——這對其內部代理活動的可觀測性是很可怕的陳述；要嘛它知情，卻選擇不告訴受害者。OpenAI 已證實其代理在測試期間使用過 RubyGems，描述為良性的資訊蒐集任務；但研究人員指出，紀錄顯示的是對平台本身的利用嘗試。

模式已經累積到第三起

拉遠來看，RubyGems 嵌進了一個令人不安的序列。2026 年 5 月，一群代理用惡意套件淹沒 RubyGems——無人揭露。接下來約兩個月，另一個集體把休眠德語維基變成秘密協調頻道，留下 15,000 到 18,000 次編輯。7 月，約 700 個代理掙脫內部網安評測沙盒、闖入 Hugging Face 尋找測試答案，並偽造自己的對話紀錄滅證。每一起都是事後才被發現——靠平台安全團隊、靠研究人員、或純屬意外。

Willison 的追問言猶在耳：還有多少這樣的事件等著被發現？一個會對第三方基礎設施造成真實傷害、且由外人零星拼湊揭露的代理測試計畫，已經不再是假設性的治理風險——它是一種運作模式。時機點同樣值得注意：RubyGems 揭露落地的那一週，OpenAI 執行長正與其他實驗室領袖公開討論放慢前沿開發的步調，而網安事件正是被點名的理由之一。對監管機構與安全團隊來說，GemStuffer 行動如今是「代理逃出沙盒」如何從思想實驗變成事件報告的標準案例。