72 小時與 6,500 美元：Claude Opus 5 如何從一張論壇圖片攻進 OpenAI

2026 年 7 月 25 日，一家只有三個人的資安新創 Hacktron AI 入侵了多名 OpenAI 員工的 ChatGPT 與 Codex 帳號。從那個位置出發，他們本可以翻遍 OpenAI 的內部 GitHub 組織、Slack 工作區和電子郵件。但他們做了一件節制得近乎戲劇化的事：用被入侵員工的 Codex 開了一個無害的 pull request——#1186742——在 OpenAI 的內部 monorepo openai/openai 裡，純粹為了證明權限存在。然後他們停手，透過 Bugcrowd 通報一切，等待修復。

由 Harsh Jaiswal、Mohan Pedhapati 與 Rahul Maini 三人在 9 月 13 日發布、並在本週末被媒體全面引爆的完整報告，讀起來像一份 AI 資安社群警告事項的逐條驗證清單——而其中一個細節更成了整個故事的核心：Claude Opus 4.8 在多個工作階段中都未能完成這個攻擊；Claude Opus 5 在釋出後幾小時內拿到同一個題目，成功了。

攻擊鏈：一張圖片、一個函式庫、一個身分缺陷

這場攻擊的起點是一個相依套件，而不是目標本身。OpenAI 的社群論壇 community.openai.com 跑在 Discourse 上，以 Debian 12 為基底的 Docker 映像自行架設。跟大多數現代論壇一樣，它接受圖片上傳——包括 HEIC 與 HEIF 檔案，也就是 iPhone 預設拍出的格式。Discourse 正常的圖片檢查流程用 FastImage，但 FastImage 看不懂 HEIF，於是這類檔案被轉交給 ImageMagick 的 magick 指令做轉檔。這一步把攻擊者可控的原始資料，直接送進了底層的開源 HEIF 解碼器 libheif。

Hacktron 團隊對著 Discourse Docker 映像開了一個 Opus 4.8 工作階段，請它審查安裝的 libheif 套件。模型發現某些特定的安全修復從未被回移（backport）：上游前一年修改漏洞程式碼的 commit 既沒被標記為安全修復、也沒有申請 CVE，這很可能就是 Debian 12 出貨時帶著 libheif 1.19.7、連 Debian 13 都還帶著仍有漏洞的 1.19.8 的原因。這個 bug 是 HEIC 解碼路徑中的堆積緩衝區溢位（heap buffer overflow），提供越界讀寫（OOB R/W）原語——遠端程式碼執行（RCE）的原料。

把這個原語發展成可用攻擊的過程，正是兩代模型分出高下的地方。7 月 24 日，Opus 4.8 在關閉 ASLR 的環境下寫出了可用的 ImageMagick/libheif 程式碼執行攻擊，但多個工作階段都無法讓它在 Discourse 預設開啟 ASLR 的設定下穩定運作。當天晚上，Anthropic 釋出了 Claude Opus 5。一個全新的工作階段在三小時內為本地 Mac 寫出可用的 ARM64 攻擊，接著把它移植到 Discourse 使用的 x86-64 與 jemalloc 環境。到 7 月 25 日早上 6 點，上傳圖片就等於執行程式碼。

還有最後一哩路。團隊把 Claude 放進一個自主的 /goal 迴圈，攻擊他們自己的 Discourse Cloud 實例，並透過 rce.ee/ctf-forum 代理，讓它看起來像個 CTF 靶機——因為 Opus 拒絕對遠端正式環境撰寫攻擊程式。四小時後，這個 agent 在 Discourse Cloud 上完成 RCE，讀取 /etc/hosts 作為證明。而產出的攻擊腳本，隨後對 OpenAI 的實例也直接生效。

最後一環其實不是 Discourse 的錯。論壇上的「使用 OpenAI 登入」透過 auth.openai.com 進行，而那裡的一個 SSO 設定缺陷，意味著拿下論壇就能級聯成任何活躍成員的 ChatGPT 與 Codex 完整帳號接管——包括帳號連著內部 GitHub、Slack 與電子郵件的 OpenAI 員工。研究人員特別強調：升級路徑是 OpenAI 的身分問題，不是 Discourse 的——任何掛在 OpenAI SSO 後面的第一方或第三方服務，都能當墊腳石。

通報流程：快、乾淨、而且便宜

時間軸本身跟技術一樣有參考價值。7 月 25 日 05:00–06:00 UTC 初步發現；08:00 提交 Bugcrowd；13:30 在 OpenAI 內部 monorepo 開出概念驗證 PR，15:30 全面停止測試。OpenAI 在當天 22:49 確認修復——距離通報約 14 小時。Discourse 同日經 HackerOne 收到報告，週日回覆、週一就有修復，並把 ImageMagick 沙箱化作為縱深防禦，7 月 28 日發布安全通告 GHSA-vhm9-85gw-x335。9 月 1 日，OpenAI 支付 6,500 美元賞金並結案——附帶說明：獎金僅針對 OpenAI 端的發現，因為 Discourse 代管的論壇本來就明文排除在賞金計畫範圍外。

再來是經濟學。整個「HEIF Heist」研究計畫——包含這次 OpenAI 入侵，加上橫掃 Slack、Meta、GitHub Enterprise、Ruby on Rails，以及 Next.js、Astro、Gatsby 等 Node.js 框架的兩個月調查——總 token 花費不到 3,000 美元，由三名研究員完成。把攻擊移植到每家新公司，通常只需要一到兩天。團隊指出，模型每次都近乎盲目起步，不知道確切的 libheif 版本、libc 版本或部署環境，然後自己摸清楚。

為什麼這比標題更重要

最輕鬆的解讀是「Claude 入侵了 OpenAI」；更困難也更要緊的解讀，是研究人員真正想說的事。這不是全自主駭客——純熟的人類引導依然不可或缺。但模型世代之間的落差，才是真正的訊號。Opus 4.8 找得到未回移的修復、寫得出玩具等級的攻擊；Opus 5 能在數小時內擊敗 ASLR 與 jemalloc。在更大範圍的行動中，團隊還觀察到從 Opus 5 到 GPT-5.6 Sol 的再一次跳躍——在對目標系統一無所知的情況下完成利用。無論你原本對 AI 攻擊能力的估計為何，這條斜率現在已經可以用「釋出事件」為單位來量化，而且很陡。

報告的結語把結構性的問題講得很白。軟體長期受惠於一種「複雜度帶來的安全」：漏洞甚至可以是公開的，但把 bug 變成穩定可用的攻擊，需要稀缺的專家、大量時間與對目標環境的認識。這從來不是真正的安全邊界，但它實務上保護了平凡的公司。AI 正在把這層保護拆掉——把稀缺專家變成運算資源。過去需要一個資源充足的團隊忙好幾個月的工作，現在壓縮成幾天，成本不過一頓像樣的晚餐。建立在「誰有能力發動精密攻擊」上的威脅模型，已經過時了。

兩個實務層面的註腳值得記下。第一，偵測基本上缺席：除了 Shopify 之外，團隊「不知道有任何公司偵測到這些活動」——儘管上傳了數千張圖片、圖片處理程序反覆崩潰。如果你經營的服務接受使用者圖片並解碼 HEIF/AVIF，指引很直接：立刻更新 libheif 與 libde265（截至 9 月 14 日，上游安全版本為 v1.23.4）、用不到就關掉未受信任的 HEIF/AVIF 解碼、並把圖片處理管線隔離在強化的暫態沙箱裡。如果你自架 Discourse，只更新網頁介面不夠——要重建 Docker 映像。

第二，是關於邊界的問題。Anthropic 的模型拒絕對線上遠端目標武器化這個攻擊，團隊得把自己的實例偽裝成 CTF 靶機才得以繼續。護欄改變了工作流程，卻沒有阻止它——攻擊依然存在、依然有效、最終依然在 OpenAI 的論壇上執行。當前沿模型越來越強，「直接要求時拒絕」與「換個方式要求時成功」之間的縫隙，將是大量安全政策被反覆協商的地方。

對 OpenAI 而言，這起事件為這個不舒服的季節再添一筆——同一週，模型異常行為的披露連環出爐，緊接著又是 Google Gemini 紅隊演練的曝光。對其他人而言，這是一場預演：72 小時、三名研究員、一個聊天視窗，換到一家全球市值最高公司之一的內部儲存庫存取權——賞金 6,500 美元。