研究人員在不到72小時內，結合 Claude 協助開發漏洞利用程式，從 OpenAI 社群論壇的圖片處理缺陷一路鏈到員工帳號與內部程式碼儲存庫存取；事件凸顯 image parser、SSO 與 IDE/CI 整合風險的連鎖效應。
這起研究由 Hacktron 揭露，核心路徑是先從 OpenAI 採用 Discourse 架設的社群論壇切入，再串聯員工 ChatGPT 帳號與 OpenAI 內部程式碼儲存庫的存取能力。研究人員在不足 72 小時的測試中，先找到論壇圖片處理元件的安全問題，接著控制多名 OpenAI 員工帳號，最後透過其中一名員工已連結 OpenAI GitHub 組織的 Codex，確認可操作內部程式碼儲存庫，但在完成驗證後即停止測試，未查看內部原始碼。
來源顯示，OpenAI 社群論壇在處理 HEIC／HEIF 圖片時使用 libheif，而當時版本存在堆積緩衝區溢位相關問題，Discourse 後續將其公告為 CVE-2026-32882，並標示 CVSS 3.1 為 8.8，屬於高風險漏洞。研究人員於 7 月 25 日透過 OpenAI 漏洞懸賞計畫通報，OpenAI 約在 14 小時後確認修正，並於 9 月 1 日標示案件已解決。
技術鏈的第一段是 image parser 攻擊面。論壇允許使用者上傳圖片，而 libheif 負責解析 HEIC／HEIF 等格式；一旦解析器對特製圖片的處理出現記憶體邊界錯誤，就可能讓攻擊者在伺服器端觸發程式碼執行。來源指出，研究初期以 Claude Opus 4.8 協助開發漏洞利用程式，但在 Discourse 預設啟用 ASLR 的環境下無法穩定利用；改用 Claude Opus 5 後，約 3 小時便完成可在本機 Mac ARM64 環境運作的利用程式，之後再針對 Discourse 使用的 x86-64 環境調整，最終取得遠端程式碼執行能力。
第二段是身分與授權鏈的放大效應。當論壇伺服器被拿下後，研究人員進一步利用 OpenAI SSO 機制的問題，控制多名員工的 ChatGPT 帳號。這裡的關鍵不是單一帳號失陷，而是員工帳號與內部工作流工具之間的連結；其中一名員工的 Codex 已連到 OpenAI 的 GitHub 組織，使攻擊面從應用層延伸到程式碼協作層。為了確認權限邊界，研究人員要求 Codex 建立一筆無害的 pull request，證實可操作內部儲存庫，但未進一步存取內容。
第三段是 AI 工具在漏洞研究中的角色。這次案例並不代表 AI 自主完成入侵，而是由研究人員主導攻擊路徑、環境辨識與利用條件調整，再讓 Claude 協助加速 exploit 開發。來源也提到，將同類研究擴展到其他支援 HEIF、HEIC 與 AVIF 的服務時，仍需先確認目標版本、配合實際環境調整圖片酬載，部分遠端程式碼執行測試甚至需要上傳數千張圖片。這說明 AI 能縮短研發時間，但無法取代對目標堆疊、版本與防禦機制的精準分析。
直接影響集中在三個層次。第一層是論壇與圖片上傳流程，只要服務使用受影響的 libheif，且允許外部上傳 HEIF／HEIC 圖片，就可能成為初始入侵點。第二層是員工帳號與 SSO 整合環節，當社群平台或支援系統與內部身份驗證鏈互通時，一個外部服務失守即可延伸至內部工作帳號。第三層是開發協作與程式碼儲存庫，若員工的 Codex、GitHub 組織或其他自動化開發工具已串接，攻擊者便可能從帳號層進一步接觸內部專案流程。
更廣泛的風險在於，這類問題並不侷限於 OpenAI。Hacktron 已將研究擴大到其他支援 HEIF、HEIC 及 AVIF 的服務，而 CyberScoop 相關報導指出，不同服務要成功利用仍需依版本與環境調整，部分測試甚至必須大量上傳圖片。也就是說，凡是依賴 libheif、libde265 等底層解碼程式庫，且前端對圖片上傳採寬鬆策略的服務，都可能面臨相似風險。
第一，圖片解碼元件必須納入資產與弱點管理。對於 libheif、libde265 這類被廣泛使用的解析器，應持續比對供應商公告與已知弱點資料，並立即升級至修補版本。來源已指出 CVE-2026-32882 對應的修正資訊應優先納入維運排程。
第二，上傳面要做強制隔離。論壇、客服系統與協作平台的圖片處理應與核心服務分離，並限制解碼器權限、降低檔案處理程序對主機的存取範圍，同時對 HEIF、HEIC、AVIF 這類高風險格式採更嚴格的檢查與額度控制。若業務不需要這些格式，應直接停用。
第三，SSO 與工作流整合要做最小權限設計。員工帳號若能連動 ChatGPT、Codex、GitHub 組織或其他內部工具，應確保每一段授權都可獨立撤銷，並加上異常登入、裝置指紋、地理位置與行為監控。尤其是可建立 pull request、提交程式碼或觸發自動化流程的帳號，應採更高強度驗證。
第四，對外部研究通報要建立快速修補與驗證流程。這起事件顯示，從通報到修正之間的窗口可能非常短，但前提是組織已具備回應、驗證、部署與回溯的完整鏈條。若缺乏可觀測性，漏洞即使已修補，也可能在其他系統或舊版本中持續存在。
第五，AI 輔助開發與安全研究應視為效率放大器，而不是風險消失器。企業需要同時治理兩件事：一是讓防禦端也能使用 AI 加速弱點分析與修補；二是防止攻擊端利用 AI 快速產出 exploit、迭代環境適配與繞過防禦。真正的防線仍然是版本管理、權限分段、檔案隔離與持續監控。