一次早期安全測試中，OpenAI 團隊收到 200 次成功本機提權回報，人工檢查後發現 20 次其實借用了另一個 0-day 弱點。這表示「拿到 root」不必然證明指定漏洞有效。OpenAI 研究回顧的早期測試呈現了這個反直覺結果。
OpenAI 於 2026 年 11 月 4 日公布 Linux 核心安全研究：管線分析 2,308 個候選發現，在隔離環境重現 1,724 個漏洞，並產生 1,169 個本機權限提升（LPE）利用程式。經變體分析後，研究將其歸納為 948 個不同 LPE，並為之開發候選修補。這些修補仍須維護者審查，不能視為已全部合併或部署。OpenAI 的研究說明指出，人類研究者會檢視結果並向維護者通報。
很多人第一個會先想到，模型找到多少漏洞、產生多少修補，是否就代表安全工作完成？候選是否成立、能否重現、是否沿指定弱點跨越安全邊界、修補是否完整，都需要不同證據。團隊也要界定哪些步驟可自動化，哪些決策由維護者負責。
OpenAI 報告的 948 個不同 LPE，代表流程走到哪一步？
948 是變體分析後歸納出的不同 LPE 數量，研究以 948 個不同修補作為計數依據；修補仍供維護者審查。前面的 2,308 與 1,724 分別是候選發現數與動態重現數。
管線先挑出值得檢查的程式區域，再分析弱點、於隔離虛擬機重現，評估資訊外洩或 LPE 風險，最後產生修補供研究人員檢視。「候選發現」是靜態分析提出的待查問題；「動態重現」是測試環境觀察到相應異常；「利用程式」展示可能的安全影響；「候選修補」則是待審查的程式變更。各階段證據不同，結果也可能淘汰或合併。
團隊記錄成果時，應分欄列出候選、重現、利用與修補，避免用單一總數概括流程結果。
2026 年 10 月這次 Linux 測試去重後有 2,308 個候選發現，系統在 30 小時內重現 1,724 個，約占 74.7%。其餘部分需要更高權限，或受競態、特定觸發條件及時間限制影響。這是特定模型、核心版本與威脅模型下的結果，不能當成其他團隊的準確率保證。
LPE 是低權限使用者利用弱點取得更高系統權限。研究在桌面 Linux 設定中產生 1,169 個可運作的 LPE 利用程式，再經變體分析形成 948 個不同 LPE 與修補。OpenAI 表示已優先通報嚴重問題，並與合作夥伴處理其他報告及修補。漏洞、利用程式、修補提案與已部署版本是不同狀態。
團隊分派與追蹤弱點的背景，可參考 VulnOps 如何把 AI 漏洞發現接上修補流程；本次研究則聚焦自動化發現與驗證。
「候選發現不等於已驗證的漏洞。」（OpenAI 研究說明，中文譯述）
為什麼成功取得高權限，仍不能單獨證明驗證正確？
因為測試可能透過另一個弱點取得高權限。驗收時還要確認利用路徑確實使用了被指派檢查的漏洞。
OpenAI 分享過一次早期測試：系統回報 200 次成功本機提權，研究人員人工檢查後發現，其中 20 次是利用了另一個 0-day 弱點，而非報告指定的漏洞。若只看「是否取得 root」，這些結果會被誤算為目標漏洞已成功驗證。後續團隊收緊測試條件，並加入獨立檢查，確認最終利用程式使用了指定弱點。OpenAI 研究說明回顧了這次測試。
這是測試結果的歸因問題：成功提權不代表預期弱點就是原因。團隊應保留最小重現案例、執行記錄、目標版本、權限與安全邊界變化，讓覆核者能檢查成因。
OpenAI 在隔離虛擬機執行概念驗證（proof of concept，PoC），觀察程式輸出與主控台，並使用記憶體錯誤偵測工具 KASAN。報告仍須寫明核心版本、設定、觸發條件與未測範圍，避免推論所有系統都受影響。
漏洞報告要列出問題位置、觸發輸入、重現結果與影響範圍，並比對新版程式，避免重報已修正問題。更多核對方式見 AI 漏洞回報的人工審核指南。
AI 產生的修補，要檢查哪些品質？
除了確認概念驗證不再觸發，還要確認修補針對根因、涵蓋相關變體，並檢查效能、相容性、程式慣例與回歸測試。
修補擋住一個 PoC，不代表弱點已完整消除。若根因涉及共享程式路徑或多種輸入，單封一種觸發方式可能留下變體。維護者須對照根因、受影響路徑與修補差異，檢查修改範圍及相鄰程式。
OpenAI 表示，早期修補雖能緩解 PoC，仍可能改動過多、影響效能、不符程式慣例，或漏查漏洞變體。團隊增加檢查指引並迭代修補流程；原型也曾發現人類專家修補中的問題。這些觀察說明驗收須同時看功能與非功能品質，不能據此推論 AI 修補普遍可靠。
功能檢查要確認 PoC 失敗、變體無法觸發且根因已處理；非功能檢查則看成本、相容性、錯誤處理及回歸結果。上游設計仍由熟悉該子系統的維護者把關。
「修補流程可能需要反覆迭代，才能同時符合功能與非功能要求。」（OpenAI 研究說明，中文譯述）
哪些工作可以自動化，哪些決策需要人工？
候選排序、重複項整理、隔離重現與修補草稿可由自動化協助；嚴重度判定、通報範圍、修補是否符合專案慣例及正式合併，仍需有權責的人員審核。
自動化可整理大量候選與證據。OpenAI 將分析集中在低權限使用者可接觸的安全區域；威脅模型如何界定權限與安全影響，也會改變搜尋範圍。
人工審查須判定安全邊界、嚴重度、利用路徑、修補影響及通報方式。合併權限應與研究環境分開；測試範圍、網路、憑證與隔離設定都要先獲授權。
第三個案例發生在 OpenAI 的 kernelCTF 測試。研究原型受指派分析系統呼叫入口程式碼，實驗時遇到核心崩潰，追查後發現原因在 QEMU TCG；即使沒有 QEMU 原始碼，代理仍定位並回報問題。
人工分析確認原型進一步做出本機提權利用。該弱點已在上游 QEMU 修復，但實驗使用的發行版本尚未包含修補。OpenAI 說明此測試基礎設施案例。這顯示研究環境的依賴也可能成為測試對象，不能只檢查核心本身。測試前應核對虛擬化平台版本，並限制網路與權限。
團隊如何驗收自己的漏洞研究流程？
選一筆近期漏洞回報，沿著候選、重現、利用路徑、修補、回歸測試與核准紀錄逐站核對，確認每個結論都有可追溯證據與負責人。
-
界定授權與範圍：記錄程式版本、允許測試的系統、帳號權限、網路邊界及禁止操作，並確認測試環境與正式服務隔離。
-
保留候選依據：列出程式位置、問題假設、受影響版本與去重方式；候選報告不能直接計入已確認漏洞。
-
重現並核對原因：保存最小 PoC、執行記錄與環境設定，確認觀察到的影響是由指定漏洞造成，而非其他弱點或測試故障。
-
審查修補差異：對照根因與相關變體，檢查新增程式碼、效能與相容性風險，並讓不同於產生者的人員覆核。
-
完成回歸與核准：跑受影響功能的測試，記錄失敗與修正；由具備專案權限的維護者決定通報、合併與部署，記下版本與時間。
記錄各站失敗原因，可分辨未發現、未重現、無法利用、修補不完整或尚未部署。這些狀態比單一成功率更能指引改善。OpenAI 的研究也顯示，自動化可串接發現、驗證、利用評估與修補草稿，交付仍須隔離測試、人工覆核及維護者協作。
團隊可從一筆已處理的弱點回報開始，核對候選位置、重現紀錄、利用路徑、修補差異、回歸結果及核准者，再將同一驗收表套用到自動化流程。每站標記證據存放位置與負責人，交接時才能重做核查，而不只看到摘要結論。
Linux 核心維護文件要求漏洞報告列出受影響版本、描述、重現方式及觸發條件，並先核對新版。安全漏洞通報指引可作驗收欄位參考，正式通報仍依目標專案政策處理。
- 2,308 個候選、1,724 個重現、1,169 個利用程式與 948 個不同 LPE／修補，計數口徑各異，修補仍待審查。
- 利用成功仍須核對攻擊路徑，確認它使用的是報告指定的漏洞。
- 修補要通過根因、變體、效能、相容性、回歸及人工核准檢查。
常見問題
Q1：948 個不同 LPE 代表修補都已上線嗎？
不代表。948 是變體分析後的不同 LPE 計數，研究據此開發不同修補；是否被上游接受、合併及部署，仍須分別確認。
Q2：模型產生的利用程式可以直接判斷漏洞嚴重度嗎？
不能只靠利用程式。研究者還要確認利用是否對應指定漏洞、影響的安全邊界、前置條件與測試環境，才能判斷嚴重度與處理優先次序。
Q3：AI 修補通過測試後可以自動合併嗎？
測試通過是必要證據之一，仍須檢查修補完整性、回歸影響、專案慣例與授權責任。正式合併應由專案授權的維護者核准。
