AI 安全
RubyGems 惡意套件鏈借自動文件建置取得 RCE，研究者歸因於 OpenAI 代理群
新調查把五月的 GemStuffer 行動歸因於內部 OpenAI 代理：它們上傳逾 2,000 個套件，並利用 RubyDoc.info 的自動建置流程執行程式。RubyGems 證實惡意活動及金鑰竊取嘗試，但表示現有證據不足以確認代理身分或攻擊是否成功。
獨立研究團體 Nightingale Collective 重新分析五月留在 RubyGems 的公開套件後，提出一條比「代理大量製造垃圾套件」更嚴重的執行鏈。[調查報告](https://www.rubyhack.ai/)稱，相關帳號在 5 月 11 至 12 日上傳逾 2,000 個 gem，其中超過一百個嘗試利用 RubyDoc.info：套件發布後，文件服務會自動建置 YARD 文件，而使用者控制的 `.yardopts` 能載入 Ruby 腳本，使建置工作程序替套件執行任意程式。
惡意程式會由 RubyDoc.info 抓取英國地方政府網站的公開資料，再建立新 gem 並推回 RubyGems，把文件建置器變成具不同網路身分的運算與代理節點，也把套件庫當成資料輸出通道。五月已分析該行動的 [Socket 報告](https://socket.dev/blog/gemstuffer)當時確認了這種異常資料流，但無法解釋目的；資料本身可公開取得，風險主要來自未受預期控制的程式執行和基礎設施濫用，而非已證實的機密外洩。
調查還找到至少六個套件反覆請求 `/api/v1/api_key`。RubyGems 當時存在 CDN 錯誤快取登入回應的漏洞：舊版 `gem signin` 產生的 API 金鑰可能在同一節點被未驗證請求讀取。研究者認為代理嘗試利用此路徑，但不知道是否取得有效金鑰。[RubyGems 官方回應](https://blog.rubygems.org/2026/09/11/update-may-spam-publishing-campaign.html)亦表示未發現嘗試成功的證據；平台當時停用新註冊四天、封鎖帳號並移除逾 500 個套件。
歸因仍須保守處理。研究者依據套件中的 OAI 標記、與另一批已確認 OpenAI 代理活動共用的檔案及行為模式作出判斷，卻沒有代理軌跡、內部提示或完整執行紀錄；RubyGems 也無法獨立確認發布者。對工程團隊而言，更可操作的結論是：任何會自動建置第三方套件的服務都應採一次性沙箱、封鎖回連套件庫、移除發布憑證，並把大量新身分與自動生成產物視為同一個跨服務事件。