一家三人的資安新創，用 Anthropic 的 Claude 打進 OpenAI 內部系統：從論壇的一張 HEIF 圖片取得伺服器控制權，再靠一個權限過大的登入 token 接管 OpenAI 員工的 ChatGPT 與 Codex 帳號，最後在內部 GitHub 開了 Pull Request 當證明。OpenAI 付了 6,500 美元賞金。
這則消息由《華爾街日報》在 2026 年 9 月 17 日晚間率先披露，TechCrunch 於 9 月 18 日跟進報導，Hacktron AI 也在自家部落格公開完整技術細節。整件事最讓資安圈坐立不安的地方有兩個：第一，攻擊鏈的起點是一張圖片，而且是 iPhone 預設拍出來的格式；第二，真正讓攻擊從「理論可行」變成「實際打得進去」的臨門一腳，是 Anthropic 在某個晚上發布的新模型。
一句話結論
這不是「AI 會自己駭進公司」的科幻劇本，而是「AI 把資安專家的產能放大到不合比例」的現實版：三個人的小隊在 72 小時內完成了過去要一整個團隊、好幾週才能完成的工作，而防守方的偵測能力還停在「網站有沒有掛掉」。
事件時間線：從 7 月 23 日到 9 月 18 日
Hacktron AI 在官方技術報告中把整個過程記錄得相當細。他們的專案代號叫「HEIF Heist」。
| 時間（UTC） | 事件 |
|---|---|
| 2026-07-23 | 團隊開始審查 Discourse 的圖片上傳處理流程，發現 HEIC/HEIF 檔案會被送到 libheif 解析 |
| 2026-07-24 | 用 Claude Opus 4.8 寫 exploit：關閉 ASLR 的環境可以成功，預設開啟 ASLR 的環境多次嘗試都失敗 |
| 2026-07-24 晚間 | Anthropic 發布 Claude Opus 5 |
| 2026-07-25 05:00–06:00 | 換 Opus 5 重跑同一題，取得可用 Exploit，在 community.openai.com 論壇伺服器上拿到 RCE 與管理權限 |
| 2026-07-25 08:00–10:00 | 確認跨產品影響後，透過 Bugcrowd 平台向 OpenAI 提交漏洞報告 |
| 2026-07-25 13:30–15:30 | 以受影響員工的 Codex 帳號，在 OpenAI 私有 monorepo 建立無害的 PR（#1186742，改 README）作為存取證明，15:30 停止測試 |
| 2026-07-25 22:49 | OpenAI 回覆：自家側的漏洞已修補完成（距離提交約 14 小時） |
| 2026-07-25–28 | 透過 HackerOne 通報 Discourse；7/26 回覆、7/27 修補、7/28 發布安全公告 GHSA-vhm9-85gw-x335 |
| 2026-09-01 | OpenAI 發放 $6,500 美元賞金並結案 |
| 2026-09-13 / 09-18 | Hacktron 公開技術部落格；WSJ、SecurityWeek、Tom’s Hardware 等媒體跟進報導 |
值得注意的是整個流程的紀律：研究團隊在取得內部儲存庫存取權後，只讀了極有限的 metadata 與 commit 紀錄、沒有下載或閱讀敏感原始碼，選擇用「改一行 README 開 PR」這種最不打擾的方式留下存取證明，然後主動停手、回報。這在漏洞賞金圈是標準做法，也是這次事件沒有演變成法律糾紛的關鍵。
九步攻擊鏈：一張 iPhone 照片如何走到內部 GitHub
把技術細節攤開來看，這條鏈其實是「多個小疏忽串起來」的典型案例。
第一步：上傳惡意圖片。 攻擊者把精心構造的 HEIF/HEIC 圖檔上傳到 OpenAI 的社群論壇 community.openai.com（頭像或一般貼圖都行）。
第二步：Discourse 的轉檔管道。 Discourse 平時用 FastImage 檢查圖片，但 FastImage 不支援 HEIF/HEIC，於是論壇把這類檔案交給 ImageMagick 的 magick 指令轉成 JPEG。
第三步：ImageMagick 再往下丟。 ImageMagick 自己的工具鏈處理不了 Apple 的格式，於是把檔案交給底層的 C/C++ 解碼函式庫 libheif。在當時的 Debian 12 容器環境裡，版本是 1.19.7——而這個版本缺少上游在一年前就已修掉的安全修正。
第四步：記憶體損壞與 RCE。 惡意圖片觸發 libheif 的堆積緩衝區溢位（heap buffer overflow），研究人員取得越界讀寫（OOB R/W）原語，進而在論壇伺服器上實現遠端程式碼執行，並取得管理權限。
第五步：第二個漏洞——登入 token 權限過大。 OpenAI 的 SSO 讓使用者與員工透過 auth.openai.com 登入論壇，但論壇產生的 sign-in token 權限開太大，等於直接授予了關聯 ChatGPT 與 Codex 帳號的全功能 API 存取權。
第六步：橫向移動與帳號接管。 研究人員在已控制的論壇伺服器上截獲登入中的員工 Session/Token，順利接管該員工的 ChatGPT 與 Codex 帳號。
第七步：碰觸內部程式庫。 該員工的 Codex 帳號綁定在 OpenAI 官方 GitHub 組織上。
第八步：留下證明。 研究人員叫 Codex 在 openai/openai 私有 monorepo 建立 Pull Request #1186742，僅更新 README。
第九步：回報與修補。 向 OpenAI 與 Discourse 雙軌通報，兩邊分別在 14 小時與 2 天內修補完畢。
Opus 4.8 vs Opus 5：差一個晚上，差一個世界
這次事件最被反覆引用的段落，是 Hacktron 對兩個模型版本的對比。老實說，這段落比「AI 會不會搶工作」的任何討論都更有說服力。
| 比較項目 | Claude Opus 4.8（資安研究授權版） | Claude Opus 5 |
|---|---|---|
| 關閉 ASLR 的測試環境 | 可成功實現程式碼執行 | 可成功 |
| 預設開啟 ASLR 的真實環境 | 多個 session 嘗試均無法穩定構造 Exploit | 3 小時內生成可用的 working exploit |
| 架構移植 | — | 從 macOS ARM64 自動移植到 Discourse 的 x86-64 + jemalloc 配置 |
| 結果 | 卡住 | 在獨立 Discourse Cloud 實例上取得 RCE |
Hacktron 在報告中寫得很直白：「Opus 4.8 嘗試了多個 session 都無法產出可用的 exploit。Opus 5 發布後幾小時內，我們把同一個題目丟給它，它就成功了。」
換句話說，讓這次攻擊從「差一點」變成「真的打進去」的變數，不是研究員的功力突然變強，而是模型換了一版。這也是為什麼 AI 資安圈現在討論的重點不是「AI 會不會被用來攻擊」，而是「攻擊能力的斜率長什麼樣子」。
為什麼這個漏洞沒有 CVE？供應鏈的沉默風險
整件事裡最技術、也最容易被忽略的一段：libheif 的缺陷其實一年前就被上游修掉了，但那個 commit 沒有被標註為安全修正，因此沒有取得 CVE 編號。
連鎖反應是這樣的：
- Debian 等發行版的套件維護者不會知道那是一次安全修補，自然不會把它 backport 到穩定版套件。
- 所有依賴 CVE 資料庫與版本比對的掃描器，都會把「執行中有漏洞的 libheif 1.19.7」判定為安全——也就是偽陰性（false negative）。
- 而 libheif 被上層套件層層引用：ImageMagick、
sharp、libvips，甚至 Next.js（每週下載量約 4,500 萬次）。研究資料指出，Slack、Zoom、Meta 等系統與大量使用 Next.js 的企業服務，都落在這條隱形攻擊面上。
還有一個更令人不安的觀察：Hacktron 在整個「HEIF Heist」研究期間，對多個目標送出了數千張異常圖像，導致對方的影像處理器反覆崩潰，但整輪測試下來只有 Shopify 一家偵測到異常活動。大多數企業的監控只盯著 uptime，把「影像處理器一直 crash」當成一般的使用者上傳問題吞掉了。
對照組更殘酷：過去要找這種「沒有 CVE 的記憶體漏洞」、還要寫出繞過 ASLR 的 exploit，需要資深安全專家投入數週，成本動輒六位數美元。現在小團隊搭高階 AI Agent，1 到 3 天內就能自動解析記憶體結構、算出溢位邊界、生成武器化檔案。
$6,500 的賞金，與兩個「但書」
OpenAI 在 9 月 1 日支付了 $6,500 美元賞金。社群對這個數字看法兩極——一般大廠對這種等級的 Critical 漏洞，賞金常在 $20,000 美元以上。
OpenAI 的說明是：測試 Discourse 論壇本身屬於賞金計畫的排除範圍，這筆錢獎勵的是「OpenAI 端的 SSO 授權漏洞」。這個區分在技術上站得住腳，但也剛好點出了這次事件的核心結構——攻擊的入口在第三方服務，真正讓傷害擴大的卻是自家系統的授權設計。
事件同時把「模型能力紅線」的老問題重新翻上檯面：
- Opus 5 沒有受到任何資安出口限制，而較新的 Mythos 5 曾因「進階駭客能力」的顧慮被暫時鎖住。同一家公司的兩個模型，管制標準不一致，這條線到底畫在哪，目前沒人有共識。
- 開源權重模型正在追上。AI 安全非營利組織 SaferAI 曾發現中國廠商 Z.ai 的 GLM-5.2 在網路攻擊能力上，只落後 OpenAI GPT-5.5 與 Anthropic Claude Opus 4.7 幾個月。
- Anthropic 澄清：Hacktron 使用的是經授權、專為資安研究放寬限制的 Claude 版本，不是一般商用模型。
業界怎麼說
Gray Swan 執行長 Matt Fredrikson 對 TechCrunch 的評論被大量轉引：
「一個月 $200 美元，任何人都能用這些工具駭進像 OpenAI 這樣規模的公司。如果連他們都會中——我不覺得他們最近在資安衛生上鬆懈過——那任何人都可能中。」
Hacktron 創辦人 Mohan Pedhapati 則在 X 上寫下這句被視為事件註腳的話：
「AI 正在減少開發 exploit 所需的稀缺專業知識。過去要花好幾個月的工作，現在幾天就能完成。」
給開發者與自架族的實務清單
這則新聞離台灣讀者其實不遠——任何有讓使用者上傳圖片、或跑著 Discourse 論壇的自架站，都站在同一條攻擊鏈上。可以立刻檢查的幾件事：
| 檢查項 | 具體做法 |
|---|---|
| libheif 版本 | 檢查系統與容器內的 libheif 是否已更新到含上游修正的版本，別只看 CVE 清單 |
| ImageMagick / sharp / libvips | 確認這些會呼叫 libheif 的上層套件是否連帶更新 |
| Discourse | 版本更新到 2026-07-27 之後，並確認 GHSA-vhm9-85gw-x335 已修 |
| SSO token 權限 | 第三方整合拿到的登入 token 是否有「最小權限」設計？論壇 token 不該能開 Codex |
| 監控指標 | 除了 uptime，把「影像處理程序異常崩潰次數」列入告警 |
| 出站流量 | 內部服務被攻陷後能否連外、能否碰 GitHub？網段與權限切開才擋得住橫向移動 |
如果你正在自架服務並思考「要不要把東西放到公網」，這次事件也提供了一個反向思考的角度：暴露面越小越好，而 Cloudflare Tunnel 這類「不開 inbound 埠」的架構，正是為了把 origin 藏起來而存在的（詳見下方延伸閱讀）。
延伸閱讀
- OpenAI 史上首例！新模型 Astra 觸發最高資安風險「Critical」等級：自主開發零日漏洞能力太強，發布緊急喊停——同一條「模型資安能力紅線」的主線，發生在 2026 年 8 月。
- OpenAI 代理軍團攻擊 RubyGems：2,654 個惡意套件灌爆套件庫、企圖偷 API 金鑰，隱匿 4 個月才曝光——AI Agent 被用於供應鏈攻擊的案例。
- Anthropic 揭發工業級蒸餾攻擊：7 家中國實驗室用 1.51 億次對話抽取 Claude 思維鏈——當「攻擊工具」本身就是被濫用的模型。
- 網站防爬蟲實戰指南：從 robots.txt 到 Cloudflare Bot 管理——從防守端看自動化流量該怎麼分層處理。
- 什麼是 Webhook？白話文完整教學——想補齊「token 權限過大」這類授權漏洞的背景知識，先搞懂簽章與驗證。
資料來源
- Hacktron AI 官方技術報告：Hacking OpenAI
- TechCrunch：Researchers used Anthropic’s Claude to hack into OpenAI
- SecurityWeek：AI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code
- Tom’s Hardware：Hackers breach OpenAI using Claude tools
- 《華爾街日報》報導（WSJ）
本文以公開報導與 Hacktron AI 官方技術報告為基礎整理；事件細節以 Hacktron 原始報告與 OpenAI、Discourse 官方說法為準。涉及漏洞的技術過程僅作資安教育用途說明，請勿用於未經授權的測試。