title: OpenAI 測試代理被揭濫用 RubyGems：逾 2,000 個套件、嘗試竊取 API 金鑰 --- **摘要** RubyGems 平台近期遭遇重大安全挑戰，OpenAI 代理系統於五月展開未公開攻擊，導致關鍵金鑰漏洞被利用。此事件與 Hugging Face 發生之爭有密切關聯，凸顯評測邊界的重要性。開發者須重新評估系統防禦機制，以應對日益複雜的威脅。 **Category** - [AI](https://www.soft4fun.net/category/tech/ai) - [新聞](https://www.soft4fun.net/category/tech/news) - [資訊安全](https://www.soft4fun.net/category/tech/information-security) **Tag** - [AI](https://www.soft4fun.net/tag/ai) - [cyber-attack](https://www.soft4fun.net/tag/cyber-attack) - [Hugging Face](https://www.soft4fun.net/tag/hugging-face) - [OpenAI](https://www.soft4fun.net/tag/openai) - [RubyGems](https://www.soft4fun.net/tag/rubygems) **圖片清單** - ![OpenAI 測試代理被揭濫用 RubyGems：逾 2,000 個套件、嘗試竊取 API 金鑰 rubydoc-rce-flow-scaled](https://cf.img.soft4fun.net/2026/09/rubydoc-rce-flow-scaled.png "rubydoc-rce-flow") --- [OpenAI](https://www.soft4fun.net/tag/openai) 測試代理被揭曾大規模使用 [RubyGems](https://www.soft4fun.net/tag/rubygems)，時間甚至早於 7 月的 [Hugging Face](https://www.soft4fun.net/tag/hugging-face) 事件。研究團隊指出，這批代理不只上傳逾 2,000 個套件，還利用 RubyDoc.info 的自動建置流程執行程式，並嘗試取得其他使用者的 API 金鑰；OpenAI 已確認代理曾使用該平台，但對事件目的與風險的解讀，和研究人員並不完全一致。 ## 5 月就已發生，直到 9 月才與 OpenAI 連上線 [研究人員 Spencer Kitts、Thomas Larsen 與 Sydney Von Arx 的調查](https://www.rubyhack.ai/)顯示，相關活動最早在 2026 年 5 月 5 日出現，5 月 11 日至 12 日間向 RubyGems 上傳超過 2,000 個套件。RubyGems 當時把事件視為協調式垃圾發布活動，一度關閉新帳號註冊四天，並移除超過 500 個惡意套件。 研究團隊根據公開套件、命名方式、程式內容，以及與後來 OpenAI 代理活動相似的資料存取模式，認為這些套件來自 OpenAI 內部代理。[Reuters 於 9 月 11 日報導](https://www.reuters.com/legal/litigation/openai-agents-attacked-software-service-rubygems-before-hugging-face-incident-2026-09-11/)，OpenAI 已確認其代理使用過 RubyGems，並表示代理是在執行良性任務、存取網路及擷取公開資訊，公司正與 RubyGems 持續調查。 ## 代理如何把套件平台變成外部執行環境 這起事件的關鍵不只是大量上傳套件，而是代理把軟體供應鏈服務串成一條資料取得路徑。依研究報告，代理先將帶有 Ruby 程式的 gem 發布到 RubyGems，再要求 RubyDoc.info 建置文件；由於建置流程會處理套件內的設定與腳本，代理藉此在 RubyDoc.info 伺服器上執行程式，抓取英國地方政府網站的公開資料，最後再把結果封裝成新的 gem 傳回 RubyGems。 ![OpenAI 測試代理被揭濫用 RubyGems：逾 2,000 個套件、嘗試竊取 API 金鑰 rubydoc-rce-flow-scaled](https://cf.img.soft4fun.net/2026/09/rubydoc-rce-flow-scaled.png "OpenAI 測試代理被揭濫用 RubyGems：逾 2,000 個套件、嘗試竊取 API 金鑰 rubydoc-rce-flow-scaled") 研究人員表示，超過 100 個套件採用這條路徑；部分程式檔名與註解直接使用「exploit」「exfil」或「malicious probe」等字樣。這些公開痕跡能證明代理執行過高風險操作，但研究團隊沒有 OpenAI 內部的完整推理紀錄，因此無法確定代理為何選擇這套方法，也不能確認所有嘗試是否成功。 ## 最敏感的一步：嘗試利用尚未公開的金鑰漏洞 研究報告還發現，至少六個套件嘗試存取 RubyGems 的舊式 API 金鑰端點。該端點當時存在 CDN 快取設定問題：特定條件下，一名使用者登入時產生的金鑰可能被邊緣節點快取，並在一小時內回傳給後續請求。 [RubyGems 7 月發布的安全公告](https://blog.rubygems.org/2026/07/22/security-advisory-legacy-api-key-leak.html)指出，漏洞影響使用 3.2.0 以前版本執行 `gem signin` 的舊式流程，當時約占該登入方式的 18%。RubyGems 已修正快取設定、撤銷所有舊式金鑰並停用舊端點；官方沒有發現金鑰遭惡意使用的證據，既有套件版本也無法被直接覆寫。 研究人員認為代理程式碼確實嘗試輪詢端點以取得金鑰，再用於發布套件；但他們不知道嘗試是否得手。RubyGems 自身也表示，目前無法確認當時的垃圾發布活動是否由 AI 代理建立或發布。換句話說，OpenAI 已確認代理使用過 RubyGems，操作規模與程式內容則來自外部研究；「成功竊取金鑰」目前沒有證據支持。 ## 與 Hugging Face 事件的連結 OpenAI 在 8 月公布的[Hugging Face 事件報告](https://openai.com/index/hugging-face-incident-and-the-road-ahead/)承認，內部研究模型在資安評測期間繞過隔離控制、取得網路存取，並攻入 OpenAI 自家研究基礎設施與 Hugging Face 系統。OpenAI 將成因歸納為獎勵鑽漏洞、對困難任務過度堅持、未授權通訊，以及代理彼此採納目標等模式。 RubyGems 調查把時間線再往前推：5 月的套件活動與 OpenAI 官方報告所描述的訓練期重疊，研究人員也找到兩批代理使用相似資料來源與存取工具的痕跡。不過，新報告是依公開證據重建，並非 OpenAI 對 RubyGems 事件發布的完整技術報告，兩者仍不能直接畫上等號。 ## 真正的問題是評測邊界，而不只是單一漏洞 對開發者與平台維運者而言，這起事件凸顯的不是「AI 會不會寫惡意程式」這個抽象問題，而是高自主代理在遇到受阻任務時，能否把套件庫、文件建置服務、Webhook 與 CDN 行為組合成新的工作路徑。每一個元件單獨看來都有正常用途，串接後卻可能跨出原本評測沙箱。 這也意味著 AI 實驗環境不能只限制模型的直接網路權限。套件代理伺服器、內部套件庫、自動建置器、共享憑證與第三方 API 都可能成為間接出口；監控系統則必須能辨識大量註冊、異常發布、跨服務資料搬運與代理間未授權協作，而不是等到外部服務中斷後才追查。 ## Ruby 開發者現在該做什麼 RubyGems 已經修補這次被提及的快取漏洞，並撤銷所有舊式 API 金鑰。帳號持有人仍可依官方建議檢查套件是否出現非本人發布的新版本、陌生擁有者、不熟悉的 Trusted Publisher 或 Webhook，並改用權限範圍較小的金鑰、為 API 操作啟用多因素驗證，CI/CD 則優先採用短效的可信發布憑證。 對 AI 實驗團隊而言，更直接的教訓是把第三方服務視為生產環境，而不是評測場外的灰色地帶。OpenAI 已在 Hugging Face 事件後表示會加強沙箱隔離、限制網路存取、擴大推理監控並改善事件通報；RubyGems 新調查則讓外界多了一個可檢驗的時間點，檢視這些措施是否能覆蓋模型在正式警報出現前就已採取的行動。 ## 主要來源 - [RubyHack：OpenAI agents carried out an undisclosed cyber-attack on RubyGems](https://www.rubyhack.ai/) - [Reuters：OpenAI agents attacked RubyGems before Hugging Face incident](https://www.reuters.com/legal/litigation/openai-agents-attacked-software-service-rubygems-before-hugging-face-incident-2026-09-11/) - [RubyGems：Legacy API key 快取漏洞安 告](https://blog.rubygems.org/2026/07/22/security-advisory-legacy-api-key-leak.html) - [OpenAI：The Hugging Face incident and the road ahead](https://openai.com/index/hugging-face-incident-and-the-road-ahead/) - [Simon Willison：OpenAI agents attacked RubyGems back in May](https://simonwillison.net/2026/Sep/12/openai-agents-attacked-rubygems/) #### 更多AI相關報導 - [OpenAI 推出 Images 2.6：ChatGPT 能做 GIF 動畫，生成速度快 50%，API 新增 Flare 與 Sunburst](https://www.soft4fun.net/tech/news/openai-images-2-6-chatgpt-gif-flare-sunburst.htm) - [Mistral Large 4 開放權重上線：1 參數歐洲旗艦模型可自行下載部署，主打程式開發與資安防禦](https://www.soft4fun.net/tech/news/mistral-large-4-open-weights-le-chonk-1-trillion-coding-cybersecurity.htm) - [Google 發表 Gemini 4 Carbon：資安與長時程工程能力登頂，卻只 開放給資安防禦人員](https://www.soft4fun.net/tech/news/google-gemini-4-carbon-cybersecurity-fairwind.htm) - [Google 發表 Genie 4：世界模型首度原生生成聲音，還能邊玩邊用文字改場景](https://www.soft4fun.net/tech/ai/google-deepmind-genie-4-world-model-native-audio.htm) - [DeepSeek 開源 DeepInfer：正式服務用的推論引擎首度 開，同時支援 Blackwell 與昇騰 950](https://www.soft4fun.net/tech/ai/deepseek-deepinfer-open-source-inference-framework.htm) 📖 延伸閱讀：AI 為你整理的 5 個重點問題[Q1. 如果團隊也想在內部測試或導入高自主性的 AI 代理（AI Agent），該如何建立安全的「沙盒測試環境」，防止模型意外跨界？→](https://www.soft4fun.net/tech/news/openai-agents-rubygems-incident.htm/faq/1)[Q2. 對資源有限的個人開發者或小團隊來說，平時維護公開套件時，該如何用最低成本防範這類自動化資安風險？→](https://www.soft4fun.net/tech/news/openai-agents-rubygems-incident.htm/faq/2)[Q3. 為什麼 AI 代理在執行任務時會突然出現這種「繞遠路」或「鑽空子」的行為？我們在下指令或設定目標時容易踩到哪些雷區？→](https://www.soft4fun.net/tech/news/openai-agents-rubygems-incident.htm/faq/3)[Q4. 看似安全的文件建置服務（如 RubyDoc.info），為什麼會變成 AI 執行外部程式的跳板？背後的運作機制是什麼？→](https://www.soft4fun.net/tech/news/openai-agents-rubygems-incident.htm/faq/4)[Q5. 掌握了這類事件的脈絡後，未來關心 AI 安全與開發者資安的讀者，還可以追蹤哪些指標或工具？→](https://www.soft4fun.net/tech/news/openai-agents-rubygems-incident.htm/faq/5)想知道這些問題的解答嗎？