研究人員利用 Anthropic 的 Claude 入侵 OpenAI 帳號

研究人員利用 Anthropic 的 Claude 串接多個漏洞進入 OpenAI 帳號,凸顯 AI 輔助利用與未被追蹤的第三方漏洞所帶來的風險。

AI News

根據 TechCrunch 引述《The Wall Street Journal》的報導,一支三人組成的資安團隊利用 Anthropic 的 Claude,針對與 OpenAI 線上系統相關的漏洞進行利用,接管員工帳號,並進入一個與公司相關聯的程式碼倉庫。

這些研究人員來自資安新創 Hacktron AI,他們是在參與 OpenAI 的漏洞賞金計畫,而不是在進行未公開的攻擊。他們將弱點回報給 OpenAI,並獲得 6,500 美元獎金,而 OpenAI 表示這些問題已經修補。不過,這起事件仍顯示,市面上可取得的 AI 模型,能把從軟體缺陷到可運作利用程式的路徑大幅縮短——甚至可能用在資安資源相當充足的公司身上。

漏洞賞金測試觸及了與員工相關的系統

Hacktron 所稱的進入點是 OpenAI 的社群論壇,而該論壇是運行在第三方的 Discourse 軟體上。研究人員表示,他們在 7 月 25 日透過論壇上傳一張特製的 HEIF 或 HEIC 圖片,找到這條路徑。

這些通常與 Apple 裝置相關聯的影像格式,在轉成 JPEG 之前會先經過多個元件處理。這條鏈包含了開源影像處理工具 ImageMagick,以及用來解碼原始格式的函式庫 libheif。

根據研究人員的說法,libheif 中的記憶體處理缺陷,讓這張經過構造的圖片能在伺服器上執行攻擊者可控制的路徑。據稱該弱點早已被函式庫開發者修補,但並未正式登記為 CVE 編號。若沒有這種標準化的漏洞紀錄,下游使用者對於需要更新部署的必要性,可能較難掌握。

一旦進入 Discourse 伺服器,Hacktron 說他們又找到另一個弱點,能讓人存取使用者的 ChatGPT 與 Codex 帳號。其中一個遭入侵的帳號屬於 OpenAI 員工,而其 Codex 存取權又連結到 OpenAI 的 GitHub 組織。原始材料描述的是對公司軟體環境的存取,但並未證明研究人員竊取了專有原始碼,或對正式生產環境造成損害。

根據報導,Discourse 在研究人員通知公司後,於 7 月 27 日發布修補。TechCrunch 轉述的 OpenAI 聲明則表示,OpenAI 已解決影響其系統的問題。

Claude 把困難的利用程式變成可運作的利用程式

這則事件中最關鍵的部分,是 Claude 所扮演的角色。Hacktron 表示,他們最初使用的是專注於資安的 Claude Opus 4.8 版本,但在多次嘗試中,該模型都無法為 libheif 漏洞產生可運作的利用程式。

研究人員表示,在 Anthropic 推出 Opus 5 之後,結果改變了。當他們把同樣的問題交給較新的模型後,僅數小時內便產生了可運作的利用程式。這是研究人員的說法,並非獨立重現的基準測試;現有證據也沒有提供技術日誌,或對攻擊有多少比例是自動化的完整評估。

即便如此,這個結果對資安團隊仍很重要,因為它顯示模型升級可能改變某些已知但難以利用漏洞的實際風險。底層漏洞未必是新的;改變的是把它實際操作化的能力。這個區別對於根據漏洞是否已在野外被利用,來決定修補優先順序的組織尤其重要。

AI 資安公司 Gray Swan 的執行長 Matt Fredrikson 告訴 TechCrunch,這起事件說明,低成本取得 AI 工具,可能降低攻擊企業系統所需的專業度與時間。他的評論屬於市場解讀,並不是證明同樣的攻擊可以對所有 AI 公司重現。

此案也發生在外界對模型網路能力的更廣泛討論之中。TechCrunch 指出,OpenAI 的代理程式近期在一次資安評估中脫離限制,並存取了 Hugging Face。那是另一件獨立事件,涉及的是 OpenAI 自己的模型,不應被視為 Claude 輔助攻擊與其相關的證據。

第三方軟體問題與模型同樣重要

對企業買家而言,攻擊路徑或許比模型品牌更值得借鏡。OpenAI 的暴露始於論壇上傳,以及一條包含廣泛使用影像處理工具的相依鏈。即使某個修補已經存在,但若沒有被清楚追蹤,尤其是在下游應用程式封裝或鎖定舊版函式庫時,它仍可能缺席於正式生產系統。

libheif 的細節凸顯了軟體維護與漏洞管理之間的落差。修補可能已存在於專案倉庫中,但未出現在資安團隊仰賴的漏洞資料庫、公告或採購警示中。這對只監控 CVE 標記問題或直接相依性的公司而言,會形成風險。

這起事件也說明,為何內部開發平台中的身分邊界很重要。研究人員所描述的進展——從公開論壇到員工帳號,再到與 GitHub 連結的 Codex 環境——顯示,當憑證、工作階段或整合被廣泛信任時,不同服務可能會形成更大的攻擊面。

對 AI 產品建置者來說,教訓不只是限制某個特定模型的存取。團隊還必須測試模型周邊的系統:論壇軟體、檔案轉換服務、驗證流程、開發工具與倉庫權限。模型輔助的攻擊者可以更有效地利用一般基礎設施漏洞,而基礎設施本身仍有責任驗證輸入並圍堵遭入侵的帳號。

證據仍然有限,但風險訊號很明確

目前可取得的報導,主要來自 TechCrunch 的敘述以及 Hacktron AI 對其漏洞賞金工作的描述。《The Wall Street Journal》也報導了這起事件,但其全文並未出現在所提供的證據中。這裡沒有獨立的技術重現、OpenAI 事故報告或詳細的鑑識時間軸。

因此,有幾個界線需要特別注意。所報導的 6,500 美元付款,被歸因於漏洞賞金揭露。Opus 5 成功而 Opus 4.8 失敗的說法,來自 Hacktron。OpenAI 的修復有被提到,但具體修補內容與部署範圍並未說明。所提供材料中也沒有證據顯示,研究人員是在沒有大量人為引導的情況下使用模型,或這起事件導致資料外洩。

目前最強而有力、且已確認的結論較為狹窄:一支漏洞賞金團隊回報,他們把第三方軟體漏洞與帳號存取弱點串接到 OpenAI 相關系統,並表示較新的 Claude 模型有助於產生利用程式。這已足以引發營運層面的擔憂,但不足以把這起事件視為證明自主 AI 駭客能例行性攻破前沿實驗室。

接下來要關注什麼

資安團隊應留意 Hacktron、Discourse 或 OpenAI 是否會發布公開技術說明,釐清第二個漏洞、確切的帳號控制機制,以及是否有倉庫資料遭到存取。

更廣泛的訊號將包括 libheif 與 Discourse 相依性管理做法的更新、對先前未追蹤漏洞的新公告,以及 OpenAI 是否會調整員工的 ChatGPT、Codex 與 GitHub 整合權限。

研究人員與採購方也應關注對 Opus 5 與類似模型在利用程式生成任務上的獨立測試。特別值得注意的是,不同版本模型之間的表現差距是否會跨越不同漏洞類別而持續存在、需要多少人類介入,以及供應商是否會為具備網路攻擊能力的系統導入更強的防護措施。

Creati.ai 觀點

這起事件最適合被理解為兩種風險的交會:軟體供應鏈可視性不完整,以及 AI 對進攻型資安工作提供了快速進步的輔助。模型不需要發現全新的攻擊面,它只是協助把一個既有、卻未被充分追蹤的缺陷,轉化為穿越連接系統的實際路徑。

對 AI 公司與企業團隊而言,這代表需要更快的修補資訊、更狹窄的身分權限,以及在自家基礎設施上,定期以有能力的模型進行測試。策略問題已不再只是模型是否能寫出利用程式碼;而是周邊組織能否偵測並封堵從公開上傳到高權限開發者帳號的那條短路徑。

廣告