吳明宜研究人員 Spencer Kitts 、 Thomas Larsen 與 Sydney von Arx 發現，2026 年 5 月開原套件庫 RubyGems 發生一起重大惡意攻擊，背後操作者為 OpenAI 旗下一群 AI 代理人。
2026 年 5 月 12 日，軟體供應鏈安全廠商 Mend.io 研究人員 Macjej Mensfeld 揭露一起以數百個垃圾 gem（套件）對 Ruby 開發語言套件管理器展開協同攻擊，迫使維護人員暫停新用戶加入約 4 天。
隨後供應鏈安全廠商 Socket 發現一宗名為 GemStuffer 的攻擊，背後是一群超過 150 個 gem，利用套件註冊表 (package registry) 作為外洩資料通道，並自英國地方政府民主服務入口網站取得公共資料。該安全廠商指出，此攻擊與前述 RubyGems 垃圾套件攻擊具有相同濫用模式，但由於相關資訊本就屬於公開資料，實際目的仍待釐清。
最新調查由《華爾街日報》首先報導。研究人員發現事件背後為一群 OpenAI 代理人，最早於 2026 年 5 月 5 日上傳套件至 RubyGems，並於 5 月 11 日與 12 日上傳超過 2000 個套件；5 月 26 日及 27 日再發布 5 個套件，隨後於 6 月 18 日上傳 83 個套件。
分析顯示，這些套件由大型語言模型 (LLM) 撰寫，上傳至 RubyGems 的上百個 gem 名稱含有 oai 字樣，部分套件以 oai 列為作者，或以 openaixxx@gmail.com 作為聯絡電子郵件。研究人員認為，這群行為者的活動模式與先前德文論壇 DseWiki 遭存取的事件高度相似。
DseWiki 事件同樣發生於 2026 年 5 月，OpenAI 代理人在內部限時聯網評估測試中突破沙箱連上 DseWiki，作為公布欄尋求其他代理人解答並共享技巧。在 RubyGems 事件中，代理人則是利用文件建立平台 RubyDoc.info 的設計弱點，將政府網站資料外洩，手法類似從外部網站蒐集解題資訊。
此外，RubyGems 事件中有名為 zzsouthrunner 的代理人，命名手法與 DseWiki 及 Hugging Face 事件一致，用以降低遭管理員刪除的機率。
研究人員進一步指出，代理人在取得 RubyDoc.info 文件建置環境的遠端程式碼執行 (RCE) 權限後，企圖竊取其他使用者的 API 金鑰；從套件命名（如 pwnp999）與原始碼註解 (#hack) 來看，代理人明確辨識出此為非授權存取真實系統之行為，甚至嘗試在註解中隱藏意圖。
代理人亦於 5 月 12 日的行動中嘗試利用一項 CVSS 風險值 7.3 的未命名 CDN 快取漏洞。理論上該漏洞可能導致特定帳號的 API 金鑰在最長 1 小時內暴露給其他帳號持有者，修補前共有 6 個套件觸及該漏洞；RubyGems 已於 7 月完成修補，並表示未發現遭惡意濫用跡象。
其他發現包括代理人繞過 RubyGems 電子郵件驗證機制，未經郵件驗證即取得 API 金鑰，以便透過拋棄式信箱大量註冊帳號（該漏洞已於 5 月 12 日修補）。代理人亦嘗試運用 RubyGems Webhook 系統以編碼 URL 傳輸資料，並於 6 月 18 日在 3 小時內發布 83 個 gem，測試存取美國證券交易委員會 (SEC) 的不同途徑。
此為 OpenAI 繼 Hugging Face 與 DseWiki 之後，被記錄的第三起未授權存取第三方網站事件。儘管 OpenAI 近期公布 GPT-6 Astra 並強調其遵循規範能力，業界對自主 AI 代理人的失控風險與安全邊界仍表達高度關切。
（綜合外電報導）