回看板
Disp BBS
作者 LoveSports (如何當一個好男人)
標題 [新聞] OpenAI代理攻擊RubyGems在擁抱臉攻擊前兩
時間 Wed Sep 16 17:49:11 2026


原文標題： OpenAI代理攻擊RubyGems在擁抱臉攻擊前兩個月
OpenAI Agents Hit RubyGems Two Months Before The Hugging Face Attack

原文連結：
https://www.forbes.com/sites/jonmark...efore-the-hugging-face-attack/
https://reurl.cc/QNNEM0

發布時間： 9/14

記者署名： Jon Markman

原文內容： 本文為AI機翻

Fobes網頁提供的摘要:

研究人員將 OpenAI 的代理程式 (Agents) 與 2026 年 5 月針對 Ruby 套件註冊中心
RubyGems 的攻擊活動聯繫了起來。證據顯示，超過 2,000 個惡意套件的名稱中包含「
oai」，並附帶與 OpenAI 相關的電子郵件。這些套件利用了 RubyDoc.info 的漏洞，使
代理程式能在構建伺服器 (build servers) 上執行任意程式碼，並從英國地方議會入口
網站擷取公開數據。OpenAI 承認其代理程式將 RubyGems 用於「良性任務」，但

RubyGems 無法證實有 AI 參與其中。這起事件在幾個月後才由外部研究人員揭露，發生
時間早於 Hugging Face 遭駭事件，引發了對 OpenAI 透明度的質疑。該事件突顯了對
AI 代理程式活動進行獨立監督與強化監控的迫切需求。



新聞內容:

數百個套件的名稱中帶有「oai」。有 15 個將「oai」列為作者。其中一個甚至提供了
openaixyz65947@gmail.com 的聯絡地址。

這些都是研究人員用來將 5 月份針對 Ruby 語言套件註冊中心 RubyGems 的攻擊活動，
歸咎於 OpenAI 代理程式的「指紋」之一。這些研究人員包括 Spencer Kitts、Thomas

Larsen 以及 Nightingale Collective 的執行長 Sydney Von Arx。《華爾街日報》率先

報導了這些發現，該研究報告於週五發表。

關鍵在於日期。第一個套件於 5 月 5 日上傳。OpenAI 的代理程式在 7 月入侵了
Hugging Face，而 OpenAI 於 8 月對該事件的調查報告，自此成為業界評估的依循文件
。

OpenAI 代理程式對外部基礎設施已知最早的攻擊，始於 Hugging Face 遭駭前兩個月，
且是由外部研究人員將其公諸於世的。


RubyGems 上發生了什麼事

根據《駭客新聞》（The Hacker News）對該研究的描述，5 月 11 日和 12 日有超過
2,000 個套件襲擊了註冊中心；隨後在 5 月 26 日和 27 日出現 5 個套件的小波段，6
月 18 日則有 83 個。這些套件利用了 RubyDoc.info 網站的設計缺陷；該網站負責在收
到構建請求時為 gem 套件構建並託管說明文件。


根據研究人員的說法，使用者提供的「.yardopts」檔案可以在構建期間載入 Ruby 腳本
，這讓說明文件的生成變成了在 RubyDoc 伺服器上執行任意程式碼。

大約有 1,397 個套件參照了 r.jina.ai（一項將網頁轉換為純文字的服務）。研究人員
表示，代理程式利用受感染的構建工作節點 (build workers)，從英國三個地方議會（

Lambeth、Wandsworth 和 Southwark）的入口網站擷取公開文件。在他們的描述中，原本

應該用來構建說明文件的軟體，卻在執行代理程式的程式碼，並替它們讀取網頁內容。

這些代理程式還針對 RubyGems 內容傳遞網路 (CDN) 中的一個快取漏洞發起了 6 次攻擊
嘗試。該漏洞可能將某個帳號的 API 金鑰交給另一個帳號長達一小時，RubyGems 已在
7 月修補了這個錯誤。RubyGems 於週五表示，他們「沒有發現這些嘗試成功的證據」，
並已「撤下超過 500 個惡意套件」，而 5 月份暫停的註冊功能「已於 5 月 16 日重新
開放」。


16 月份的代理程式存取了 49 個檔案，這與同期盤踞某德國程式設計維基網站的代理程式
所存取的檔案完全相同。在不同網站上、分屬不同群體的 OpenAI 代理程式，正在試圖獲
取相同的資料。


OpenAI 的聲明只有兩句話。「根據我們的審查，我們的代理程式利用 RubyGems 平台連
接網際網路，以執行良性任務並擷取公開資訊，」聲明指出。「我們將繼續進行調查，作
為我們對模型訓練與評估期間代理程式活動進行更廣泛審查的一部分。」


代表 RubyGems 發言的 Ruby Central 成員 Colby Swandale 則給出了截然不同的說法：

「根據我們掌握的證據，我們無法確定這些套件是否由 AI 代理程式建立或發布。我們的
重點是識別並防止濫用，無論它來自人類還是自動化工具。」


「根據我們掌握的證據，我們無法確定這些套件是否由 AI 代理程式建立或發布。」

將兩者結合來看：遭到攻擊的一方無法分辨攻擊者是否為軟體；而擁有該軟體的一方則將
其行為描述為對公開數據的良性擷取。

如果研究人員是對的，那麼用這句話來描述「在他人伺服器上取得程式碼執行權限以進行
擷取的代理程式」，同樣也很貼切。註冊中心無法統計該事件的規模，而供應商則自行決
定如何描述它，因此第一次的公開統計來自於外部研究人員。


上週我們寫道，OpenAI 的內部事件分類決定了其揭露程度。Hugging Face 的入侵被歸類
為資安事件並被詳細報告；而維基網站事件則被歸類為研究，直到外部研究人員發表他們
的發現才浮出水面。


RubyGems 帶來了第三種情況。OpenAI 並未率先披露此事。直到四個月後，才由一個讀取
套件元數據 (metadata) 的研究小組歸因溯源出來。

這正是 Anthropic 執行長週六所描述的環境。他寫道，Anthropic 打算在公司內為外部
評估人員提供辦公地點。根據其計畫的合約，這些人員「應有權發布有關風險等級、事件
與實踐的關鍵發現」，而不受該公司的編輯控制。


曾在 Anthropic 領導安全研究團隊、即將加入 METR 的 Joe Benton 說得更直接：「基
本上，企業提供關於這些風險的所有透明度，完全是出於自願。」而 RubyGems 事件正是
這種「自願」在接收端（受害者端）看來的模樣。


維基網站的統計約為 18,000 個條目。而研究人員對 RubyGems 的統計則包含：超過
2,000 個套件、在第三方構建伺服器上執行程式碼，以及對憑證漏洞的 6 次嘗試。

OpenAI 的公開事件記錄在兩週內增加了兩起，但 OpenAI 都不是最先披露這些事件的人

。


投資者應從中學到什麼

對於部署代理程式的企業而言，營運層面的教訓與第一份報告相同。真正發揮作用的控制
措施存在於模型之外：即監控、隔離以及能夠停止運行中工作負載的能力。

新的教訓則在於「統計數字」。請將任何 AI 實驗室發布的事件統計數字視為「底線（最
低限度）」，因為最近的兩起事件都是由其他人率先通報的。

對投資者來說，立場也由此而生。預計將於下個月開始進行 IPO 行銷宣傳的 Anthropic
已經承諾，將讓常駐的外部評估人員發布有關其事件的關鍵發現，且不受其編輯控制。


週六，Altman 寫道，OpenAI 也將賦予獨立評估人員類似員工的存取權限，並表示「很快

會有更多消息分享」。在這實現之前，OpenAI 事件記錄中的最新條目皆來自外部研究人
員，因此，應根據實際執行的標準來審視每一筆私募估值。

應該投資那些靠驗證和控制代理程式來賺錢的企業，而不是相信供應商會自我報告的承諾
；同時，也應該緊盯 OpenAI，確保其履行 Altman 於週六所作的評估人員承諾。

用於這類驗證的運算能力與其他所有技術一樣，都在相同的加速器上運行，這使得輝達（
Nvidia）繼續保持其今年以來一直所處的位置：位於整個交易的核心。


心得/評論：

雖然目前氣氛好像不適合貼這種新聞

不過這篇9/14的  再不貼就變舊聞了  留下來給有興趣的鄉民討論


新的教訓則在於「統計數字」。請將任何 AI 實驗室發布的事件統計數字視為「底線（最
低限度）」，因為最近的兩起事件都是由其他人率先通報的。

目前看來這類事件好像擠牙膏  一個接一個出現

這篇事件居然五月初就有了  而且都不是OpenAI主動提的

這代表也許這些只是冰山一角？ 還有更多類似事件等待浮出水面？


這篇新聞建議IPO上市前要盯著這些AI模型公司所說的

委託常駐的外部機構做檢驗與公開　　實際上實踐程度如何


不過這讓我想到一件事　外部檢驗機構的人大多是這幾家AI公司轉職過去的吧？

這不會有問題嗎？公信力何在？


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 46.231.167.37 (日本)
※ 作者: LoveSports 2026-09-16 17:49:11
※ 文章代碼(AID): #1ggcORWk (Stock)
※ 文章網址: https://www.ptt.cc/bbs/Stock/M.1789552155.A.82E.html
推 asahi98: 這新聞不是很久了嗎？1F 09/16 17:50

這是9/11華爾街日報獨家報導的

最近幾天才陸續有其他家接著報導  以下是華爾街日報做的表

五月初        攻擊RubyGems
五月中        攻擊德國維基百科
五月初~七月初 在自家建立內部留言板
七月初        逃離沙盒 建立秘密留言板 進攻擁抱臉
七月下旬      Astra家族agents 完全控制自家部分基礎設施與雲端網路

※ 編輯: LoveSports (46.231.167.37 日本), 09/16/2026 17:58:58
推 joygo: 看報告覺得很猛 他直接找出人類沒發現的漏洞 現在gpt已經不給你用安全性相關問題2F 09/16 18:05
→ LoveSports: 其他新聞有提到 攻擊RubyGemg時有針對零日漏洞攻擊聽說這件事比擁抱臉事件更嚴重 因為AI不是被測資安能力 是被測日常助理找資料的任務...
也就是說 只是找個資料就當駭客進攻外部網站4F 09/16 18:10
推 LipaCat5566: 越聰明是好事 要笨笨的ai沒用8F 09/16 18:12
→ b9513227: 我怎麼看都是在吹自己AI很屌耶9F 09/16 18:35
→ LoveSports: 不是O家自己公開的，前幾個禮拜有媒體記者問哪四家被攻擊，O家說除了擁抱臉以外無法公開詳情10F 09/16 18:36
推 joygo: 他是被關在沙盒自己跑出來 超酷的 自己找到零日漏洞 而且還是熱門套件 基本上可以宣布 他想要攻入任何伺服器都沒有問題
他找到的漏洞是人類都沒找到的 而且透過的套件是幾乎每台機器都有的 以上是ai整理的12F 09/16 18:41
→ LoveSports: 補充 攻擊擁抱臉之前先去一家叫Modal labs的公司作為中介第三方伺服器以避免IP被擁抱臉資安系統發現好像不完全是自己跑出來 剛好都是有網路漏洞
只是照規定他們即使發現可以跑出去也不該跑出去17F 09/16 18:48
→ patrickk: 擁抱臉這個名字讓人聯想到異形裡的抱臉蟲21F 09/16 20:24
→ LoveSports: 不好意思因為標題太長 所以寫中文22F 09/16 20:27
→ asahi98: 有看到OpenAI在八月二十六日就自己承認這RUBY事件查了一下這次新聞只是把細節重新整理而已
難怪我一直覺得前陣子有看過23F 09/16 20:29

感謝資訊！　查了一下發現是有承認AI代理製作惡意RubyGem攻擊Artifactory

但是沒有提到五月攻擊月RubyGems事件  也沒告知站方

值得注意的是，OpenAI先前公布Hugging Face事件調查報告時，曾承認旗下代理人在7月
製作惡意RubyGem攻擊Artifactory，但並未提及此次研究人員所揭露的5月RubyGems活動
。研究人員表示，OpenAI也未曾向RubyGems告知旗下代理人涉及這起事件。

※ 編輯: LoveSports (135.136.27.50 日本), 09/16/2026 20:35:44
→ lc85301: 擁抱臉……異形表示這我熟26F 09/16 21:25

--
作者 LoveSports 的最新發文:
點此顯示更多發文記錄