研究人員利用 Claude 在漏洞賞金鏈中駭入 OpenAI 的內部系統

2026 年 7 月 25 日，安全公司 Hacktron AI 的一個三人團隊使用 Anthropic 的 Claude Opus 5，串接兩個漏洞，接管了隸屬於 OpenAI 員工的 ChatGPT 與 Codex 帳號，接著利用其中一個帳號在 OpenAI 的內部原始碼儲存庫中開啟了一個提取要求（pull request）。進入點不是登入頁面或 API 金鑰：而是 OpenAI 公開求助論壇 community.openai.com 上的一個圖片上傳功能，該論壇運行於開源論壇軟體 Discourse。第二個漏洞存在於 OpenAI 自家的共用登入機制，而非論壇。沒有任何原始碼被讀取，沒有合併任何內容，沒有觸及任何客戶資料，且該檔案庫記錄顯示未造成現實世界中的危害——這是回報給廠商的安全研究，而非對其發動的攻擊。該紀錄的日期為 2026 年 9 月 18 日，也就是 TechCrunch 報導這項發現的當天。這起事件與 Orca AI 事件檔案庫中其他有記載的條目並列，其中每筆紀錄都附有自己的來源、嚴重程度、信心等級與爭議標記。

有兩件事讓這起案例不只是個精彩的漏洞賞金故事。第一是速度：Hacktron 表示，從初次查看論壇到取得內部儲存庫存取權，整個過程花了不到 72 小時，而且它起初使用的模型根本無法勝任這項工作。第二是新聞標題中的數字所掩蓋的出入——報導點名的 CVE，CVE-2026-32882，被記錄為一種越界讀取，會使軟體崩潰或洩漏記憶體，而非程式碼執行漏洞。Discourse 自家的公告則將結果評定為遠端程式碼執行。兩者皆屬實，而它們之間的落差，正是 AI 貢獻實際所在。

Hacktron 表示發現了什麼，以及何時發現

Hacktron 於 2026 年 9 月 13 日在其自家網站發表了〈駭入 OpenAI〉一文。據 TechCrunch 所述，《華爾街日報》於 9 月 17 日星期四晚間報導了此事，TechCrunch 隨後於 9 月 18 日星期五跟進。文中描述的事件大約發生在八週前，而 Hacktron 自己的時間軸對這些事件有精確記載：

• 2026年7月23日——團隊追查 Discourse 的 HEIF 上傳路徑，從 ImageMagick 一路追到 libheif，並發現了堆積溢位。

• 2026 年 7 月 24 日 — Claude Opus 4.8 產出一個可用的程式碼執行漏洞利用，並在停用 {{1}}ASLR{{/1}}（標準的位址隨機化防禦機制）的情況下成功運作。

• 2026年7月25日 06:00 UTC — 團隊使用較新的模型，確認在啟用 ASLR 的情況下，可透過圖片上傳可靠地執行本機程式碼。

• 2026年7月25日 08:00–10:00 UTC — 團隊透過 Bugcrowd 上的 OpenAI 漏洞賞金計畫提交了一份報告。

• 2026年7月25日 10:00 UTC — 此漏洞攻擊手法先在團隊自家的 Discourse Cloud 執行個體上奏效，隨後也成功套用於 OpenAI 的論壇。

• 2026 年 7 月 25 日 13:30–15:30 UTC — 團隊使用一名 OpenAI 員工的 Codex 帳號，在 OpenAI 的內部單一儲存庫中開啟一個無害的拉取請求，隨後停止測試。

• 2026年7月25日 22:49:45 UTC — OpenAI 回覆確認問題已修復，此時距最初提交約 14 小時。

• 2026年7月28日 — Discourse 發布安全公告 GHSA-vhm9-85gw-x335，內容包含修補與重建指引。

• 2026年9月1日 — OpenAI 支付 6,500 美元賞金，並將該報告標記為已解決。

上方那些日期是 Hacktron 的，不是重建出來的。9 月 13 日其自家貼文的發布日期、9 月 17 日 Wall Street Journal 的報導，以及 9 月 18 日 TechCrunch 的報導，是另一段較晚的序列：工作是在七月進行，文章則在九月中旬刊出。

一次圖片上傳如何演變成伺服器遭入侵

這條鏈始於一個平凡的功能。Discourse 通常會用名為 FastImage 的程式庫檢查上傳的圖片，但 FastImage 不支援 HEIF——Apple 裝置用來儲存照片的容器格式。因此，那些檔案會被交給 ImageMagick 的命令列工具進行轉換，而該工具又把它們交給 libheif 解碼。這使得解析器直接暴露在攻擊者控制的檔案之前——這正是 xkcd 依賴關係漫畫所想表達的模式，Hacktron 在其參考資料中引用了它。

Hacktron 發現，Discourse 的 Docker 映像檔中所安裝的 libheif 套件缺少安全性修正。Discourse 的映像檔建置於 Debian 12，該系統安裝的是 libheif 1.19.7；當時 Debian 13 仍提供 1.19.8。這個錯誤本身位於 HeifPixelImage::overlay()，該函式會將覆蓋影像合成到基礎影像上。根據 libheif 自身的公告，當覆蓋子影像的 Alpha 通道位元深度與其色彩通道不同時，該函式會使用色彩通道的跨距來索引 Alpha 平面，而非使用 Alpha 平面的跨距。對於一張 100 x 50、10 位元色彩與 8 位元 Alpha 的影像，公告計算出程式碼會讀取超出 7,168 位元組緩衝區末尾的 3,123 位元組。

這讓攻擊者取得外洩的堆積記憶體，這有助於破解位址隨機化——但本身並不是一個 shell。從外洩走到執行，是花了模型才完成的部分，也是 CVE 沒有描述的部分。這條攻擊鏈接著跨越了一道信任邊界，Hacktron 主張這才是真正的重點：OpenAI 的論壇透過 auth.openai.com 提供「Sign in with OpenAI」，這與員工在其他地方使用的單一登入相同。控制論壇伺服器意味著研究人員可以接管在 OpenAI 工作的論壇成員的 ChatGPT 與 Codex 帳號，且受害者無需任何互動。正如 Hacktron 所言，「可提權的漏洞並非 Discourse 專有」，而任何使用該登入機制的 OpenAI 第一方或第三方服務都會授予相同的存取權。

已確立者，以及推斷者

檔案將這筆紀錄評為信心 A、無爭議、嚴重程度高，且未記錄到實際傷害。這些欄位經得起檢驗。但這份報告只是單一研究團隊的說法，屬於經佐證而非獨立重建，因此值得把已記載的內容與被斷言的內容區分開來。

由主要紀錄確認。CVE-2026-32882 存在，於 2026 年 5 月 19 日發布，影響 libheif 1.21.2 及更早版本，並已在 libheif 1.22.0 中修復。MITRE 紀錄將其評為 7.1，攻擊向量為網路、複雜度低、所需權限為無、需要使用者互動，影響為低機密性與高可用性——即當機或記憶體洩漏。Discourse 的公告 GHSA-vhm9-85gw-x335 於 2026 年 7 月 28 日發布，歸功於 hacktronai-research，追蹤同一 CVE，並將結果評為高等級 8.8，所需權限低、無需使用者互動，且對機密性、完整性和可用性三者均有高影響。它列出已修補版本 2026.7.0、2026.6.1、2026.5.2 和 2026.1.6，並指出最新的 Docker 映像檔包含已修補的 libheif。

由兩家獨立媒體分別證實。研究人員利用 Claude 找出並武器化這條攻擊鏈、論壇遭入侵而使員工帳號被存取、OpenAI 於約 14 小時內修復並支付 6,500 美元、存取證明僅是一份 pull request，以及 OpenAI 稱測試該論壇本身不在其漏洞賞金範圍內——這些內容全都見於 The Hacker News 與 TechCrunch，兩家媒體都直接引用了 Hacktron 的報告。

由 Hacktron 主張，未經獨立驗證。該論壇上的程式碼執行究竟是否確實如所述方式——透過自主代理迴圈與經代理的測試執行個體——達成，仍僅依據 Hacktron 的說法，且尚未被第三方重現；The Hacker News 表示，已就該論壇程式碼執行是如何達成，以及帳號存取範圍為何，聯繫 Hacktron 提出問題，且並未回報已收到答覆。同一類漏洞波及 Slack、Meta、GitHub Enterprise 與各網頁框架的說法，依 The Hacker News 自身的評估，「證據支持程度不一」：Next.js 漏洞已在 Vercel 的安全公告中獲得確認，libheif 的維護者則確認了與 Meta 相關漏洞的可運作漏洞利用程式，但更廣泛的跨多個應用程式程式碼執行說法尚未獲得獨立確認。OpenAI 完全沒有公布該登入漏洞的技術說明；它是透過修補程式與付款來確認這項發現，而不是透過記錄這些帳號接管事件。

根本尚未確認。有多少員工帳號可被存取——The Hacker News 說「數個」，TechCrunch 說「多個」，而 Hacktron 未給出數字。這個漏洞是否曾被任何其他人利用：The Hacker News 報導沒有跡象顯示存在現實世界中的利用，並指出截至 2026 年 9 月中旬，該 CVE 未列入美國政府已知遭利用漏洞清單，同時警告該清單也不能作為正反兩面的證明。以及已修補的組織是否仍應追查先前的存取——The Hacker News 表示消息來源對這點保持沉默。

模型做了什麼，以及人類做了什麼

能力躍升是 Hacktron 本身特別強調的部分，而且是以其自身說法記載，而非推測而來。團隊起初使用 Claude Opus 4.8，在一個提供給資安研究人員的版本中，檢查已安裝的 libheif 套件，並在停用 ASLR 的情況下建構漏洞利用程式。在啟用 ASLR 時，它接連在數個工作階段中停滯不前。Anthropic 於 2026 年 7 月 24 日晚間發布 Claude Opus 5；在全新工作階段中，新模型約三小時內就為本機 Mac 產出可運作的 ARM64 漏洞利用程式，並在隔天早上六點前移植到 Discourse 所使用的 x86-64 組態。

Claude Opus 5 在推出時也附有防護措施，避免它為真實目標撰寫漏洞利用程式碼。Hacktron 表示，它透過讓模型指向自家的 Discourse Cloud 執行個體、並經由名為 rce.ee/ctf-forum 的主機代理，使目標看起來像是一場搶旗賽演練，同時讓模型在自主目標迴圈中運作，藉此繞過這些防護。該團隊明確表示，這並非無人值守的駭侵行動：「熟練的人類指導依然很重要」，文中寫道，而小型團隊所能完成的工作量則大幅增加。在範圍更廣的 HEIF Heist 行動中，Hacktron 表示，對於事先完全不了解目標的情況，它使用的是 OpenAI 的 GPT-5.6 Sol。

經濟效益正是 Hacktron 想讓讀者帶走的重點論據。在更廣泛的活動中——追蹤同一類缺陷貫穿 Slack、Meta、GitHub Enterprise、Ruby on Rails，以及 Next.js、Astro 與 Gatsby 框架——它表示，三名研究人員兩個月的工作，token 成本不到 3,000 美元，而每次調整以適應新目標只需一或兩天。它還表示，除了 Shopify 之外，它不知道有任何公司偵測到這項活動，儘管已送出數千張測試影像，且影像處理器反覆崩潰。

之後有什麼改變？

Discourse 於週六收到通報，週日回覆，週一前完成修正，並於 7 月 28 日發布安全公告，另外為影像處理加入沙箱化作為縱深防禦。其公告警告自行託管者，僅更新網頁介面可能無法取代底層函式庫，必須從 /var/discourse 完整重建。Debian 於 2026 年 8 月 8 日為 Debian 13 的 libheif 發布安全更新，編號為 DSA-6417-1。在上游方面，Hacktron 指出截至 2026 年 9 月 14 日，libheif 1.23.4 是最新的安全性版本，並提醒發行版套件可能以較舊版本號提供回溯修正，因此除了上游版本外，也必須檢查套件安全公告。

對 OpenAI 而言，修補在 7 月 25 日通報後約 14 小時內上線，獎金則於 9 月 1 日支付。該公司在付款時附上範圍澄清：針對由 Discourse 託管的 community.openai.com 進行測試，已被明確排除在其漏洞賞金計畫之外；這筆獎勵認可的是 OpenAI 一側的發現，而非針對 Discourse 的行動。這一點值得仔細閱讀。這 6,500 美元是針對登入發現的付款，而非針對論壇攻擊鏈；而根據 OpenAI 自己的說法，讓該攻擊鏈得以成立的論壇相關工作並不在範圍內。

為什麼 CVE 與標題不符

關於此案例的報導往往會把兩種不同的嚴重性評級壓縮成一個。libheif 的公告與 CVE 描述的是越界讀取（out-of-bounds read），其機密性影響評為低、可用性影響評為高：當機，或洩漏記憶體。Discourse 的公告描述的則是將該讀取與漏洞利用工作及第二個缺陷結合後所發生的情況，並將其評為 8.8，且在全部三個類別中均為完整影響。兩者都沒有錯；它們回答的是不同的問題。CVE 回答的是「這個函式庫缺陷有多嚴重？」，而論壇公告回答的是「這個論壇問題有多嚴重？」

實際後果是：讀者在 CVE 訊息來源中掃描 libheif 是否有重大遠端程式碼執行漏洞時，將不會在這裡找到，並可能合理地認為自己未受影響。Hacktron 自身的指引正好相反：任何會接收使用者提供的 HEIC、HEIF 或 AVIF 影像，並透過未修補的 libheif 解碼的服務，都應視為已暴露；而且單看版本號並不足以檢查，因為回溯移植會讓實際狀態在未變的舊版本字串下變動。它建議的三項緩解措施是：透過發行版的安全通道或目前的上游版本更新 libheif 與 libde265；在不需要的地方停用不受信任的 HEIF 與 AVIF 解碼，或將影像處理隔離在臨時沙箱中；以及——這項措施可推廣到影像函式庫之外——限制單一登入所信任的服務，並在敏感操作前要求重新進行身分驗證，而不是信任既有工作階段。

最後一點是可移轉的結論。論壇不是漏洞，而是入口。一個公開、信任度較低的服務與內部工具共用同一個身分提供者，意味著只要攻破環境中最薄弱的環節，就能取得最強大的權限。Hacktron 的敘述中沒有任何內容顯示 OpenAI 對論壇本身疏忽大意——依照該團隊自己的評估，Discourse「其實並不是個容易攻擊的目標」——而這正是此案例被引用的原因：失效的是信任邊界，不是漏洞。