Hacktron 串起 libheif 與 OpenAI SSO 漏洞，Claude 讓高階利用壓縮到數日

Hacktron 9 月 13 日公開的「Hacking OpenAI」不是又一篇誇張的 AI 駭客寓言，而是一份把供應鏈、影像解碼器、論壇登入與開發者工具串在一起的責任揭露紀錄。研究團隊表示，他們在 7 月 25 日把 Discourse 影像上傳路徑中的 libheif 記憶體漏洞，與 OpenAI SSO 設定問題接成一條攻擊鏈，進而可接管部分 OpenAI 員工的 ChatGPT / Codex 帳號。為了證明影響範圍，同時避免讀取內部程式碼，研究者讓該帳號的 Codex 在 OpenAI 內部 monorepo 建立一個無害 pull request，隨後停止測試並通報。

這件事值得 AI 圈警醒的地方，不只在於 OpenAI 或 Discourse。真正刺眼的是攻擊經濟學變了。Hacktron 說，Claude Opus 4.8 協助檢查 Discourse Docker image 中的 libheif 套件，發現 Debian 套件缺少上游安全修補；Opus 5 發布後，又在數小時內產生可運作的 ARM64 exploit，再被研究者移植到目標環境。團隊也明確保留界線：這不是完全自動化入侵，熟練的人類判斷仍然關鍵，但 AI 把原本需要稀有經驗與長時間調校的漏洞利用工作，壓縮成小團隊幾天內可以反覆嘗試的工程流程。

OpenAI 的處理速度相當快。Hacktron 的時間線顯示，他們在 7 月 25 日透過 Bugcrowd 回報後，OpenAI 約 14 小時內確認修補，之後支付 6,500 美元 bounty；Discourse 也在同月底發布安全公告與重建指引。這些反應降低了事件後續風險，但沒有消除更大的訊號：只要產品允許使用者上傳 HEIF / AVIF 等複雜格式，底層 decoder、轉檔工具與容器基底映像都可能成為跨服務身份風險的入口。

對企業來說，這篇研究的重點不是「Claude 攻破 OpenAI」這種標題，而是安全模型必須重新估算攻擊者能力。影像處理管線應該最小化可接受格式，將 ImageMagick、libheif、libde265 等依賴保持在安全修補版本，並把非信任檔案處理放進短生命週期、隔離明確的沙箱。身份系統也不能假設第一方論壇、支援站或社群入口的 compromise 只會停在那個子系統。當 Codex、ChatGPT、GitHub、Slack 這些連接器變成同一個工作面，SSO 邊界就不再只是登入按鈕，而是整個研發組織的風險放大器。