OpenAI 找出 948 個 Linux 核心提權漏洞，真正的資安挑戰才剛開始

948 不是掃描器的警告數，而是經過多層測試的結果

看到「AI 一口氣發現近千個 Linux 核心漏洞」，最容易產生的聯想是：所有 Linux 設備是否突然都不安全了？答案不能這樣推論。OpenAI 描述的是在特定研究時間點、特定測試條件下，對 Linux 核心原始碼進行的安全研究。它不是一份所有 Linux 發行版的受害清單，也不表示每個漏洞都已被不特定攻擊者利用。

真正值得注意的是證據鏈。依 OpenAI 11 月 4 日發表的技術報告，團隊先挑出 5,034 個值得審查的程式區域，涵蓋約 280 萬行程式碼，約占核心程式碼的 7％。接著用分析代理產生 2,308 個去重後的候選發現，再透過隔離虛擬機與執行測試，重現其中 1,724 個問題。最終經過攻擊利用驗證、變體分析及修補提案，將 948 個不同的本地權限提升問題列為本次成果。

這些層次必須區分。「候選問題」是程式碼看起來有風險；「動態重現」是實際跑出可觀察的異常；「可利用漏洞」則是證明異常能突破預定的安全邊界。把三者混為同一數字，會大幅高估任何一套 AI 資安工具的實際能力。

OpenAI 另提到，開發利用程式時曾獲得 1,169 個能成功取得本地高權限的結果；經過變體分析，將對應漏洞歸整為 948 個不同問題。因此 1,169 與 948 並非互相矛盾，而是「成功利用案例」與「不同弱點」的計數口徑不同。新聞標題只寫 948，正文仍應說明這項差別。

為什麼「本地權限提升」特別值得重視

Linux 是雲端伺服器、容器平台、Android 裝置及大量嵌入式系統的核心基礎。對企業而言，核心是作業系統最有權限的部分之一。當一般使用者或低權限程式能利用漏洞取得 root 權限，原本設計用來限制存取範圍的邊界可能被突破。

「本地」兩字非常重要。它通常意味著攻擊者必須先有一定程度的系統執行或存取條件；不能因為存在本地提權漏洞，就直接宣稱網路上的陌生人能從遠端直接接管任何 Linux 主機。可是企業不能因此忽略它。真實入侵常有多個階段：先取得某個應用服務帳號，再尋找提權可能，最後觸及高價值資料或管理能力。若一個環節的權限隔離失效，原本影響有限的事件可能擴大。

OpenAI 測試的目標不是刻意關閉防護的簡化系統。報告指出，代理在一般 Linux 桌面配置的保護措施啟用時進行實驗，包括 SMEP、SMAP、KASLR 與 HARDENED_USERCOPY。這使研究比只在弱化測試機上成功更有現實意義，但仍不能等同企業所有版本、架構、設定和防禦產品都面臨相同可利用性。

從單一研究員到分工代理：AI 改變了資安工作單位

傳統漏洞研究高度依賴專家經驗。研究員閱讀程式碼、推測邊界條件、設計測試，發現可疑處後再逐一排查。這些工作仍是必需的，但難以用人力對數千個候選問題同步進行完整證據蒐集。

這次實驗呈現另一種作業模式。Scout 代理先評估哪些區域值得看，Analyst 代理深入閱讀程式碼提出疑點，Triage 代理在隔離環境重現異常，ExploitDev 代理檢驗是否能真正突破權限，Patch 代理提供修補候選版本，最後由人類研究員審查與通報。不是單一聊天機器人突然變得無所不能，而是把研究任務拆成可分派、可重試、可保留證據的工作鏈。

這個差別直接關係到企業的採購判斷。市面上已有工具會用 AI 解釋掃描報告或替警告寫建議，卻未必能自行建立測試環境、產生可重現證據、核對安全邊界，再將修補提交到既有開發流程。若只看「使用 AI」或「發現漏洞數」比較產品，往往錯過最昂貴的工作：人工驗證與修復協調。

OpenAI 公布這次實驗的 API 成本約為 1,213,430 美元，折算每個確認的不同本地權限提升漏洞約 1,279 美元。這是特定研究管線的 API 記帳成本，不含所有外部營運、維護與資安團隊組織成本，也不是一般公司購買漏洞掃描的報價。它提供的是研究經濟性線索，尚不是全球漏洞市場的標準價格。

最難的工作也許不再是「找得到」，而是「處理得了」

當候選漏洞可以在短時間內大量產生，真正受壓的可能是上游維護者、發行版安全團隊及企業內部變更流程。OpenAI 指出，掃描進行期間的 10 天內，有 61 個提權問題已在上游修補、43 個處於準備修補階段、299 個正在公開通報與討論。這些狀態代表的是報告發布當時的片段，不能推估剩餘問題都尚未修補，更不能把已提出修補候選檔案解讀成修補已正式合併。

修補一個 Linux 核心問題通常不只是修改某一行程式。維護者要確認是否可重現、是否已有相似報告、修改是否會影響其他子系統，以及不同硬體與發行版需要哪些回歸測試。企業還要評估補丁能否透過供應商提供、是否涉及維護視窗，以及機房中的關鍵服務可否接受重啟。自動化讓漏洞被看見的速度上升，但如果修補與部署容量沒有一起擴張，資安風險的積壓反而可能變得更可見。

更重要的是，AI 也可能產生「看起來成功、其實答錯問題」的證據。OpenAI 報告提到，在早期驗證過程曾發現部分利用案例雖然取得高權限，觸發的卻可能是另一個未預期的漏洞。這揭露了自動化研究的一個關鍵陷阱：結果是真的，不代表對原因的解釋就是正確的。因此修補工作必須把「是否成功提權」與「是否證明特定漏洞根因」分開測試。

攻防成本下降，並不代表資安風險可以用單一金額換算

OpenAI 以歷史資安競賽的獎金區間，試算本次成果可能對應的漏洞獎勵價值。這是方便理解量級的假設比較，並非 948 個漏洞已取得獎金，也不是這些漏洞的市場交易價格。將假設金額直接寫成 OpenAI「賺到多少」會誤導讀者。

對防守方來說，新的機會是先用更低成本找出過去難以覆蓋的問題，並在攻擊者之前提供維護者可執行的證據。對惡意使用者來說，同樣的技術發展可能降低尋找弱點的門檻。兩者的差距取決於是否有責任揭露、修補協調、安全隔離與存取控制，而不是模型排行榜上的名次。

實際部署還涉及授權問題。代理能否讀取企業原始碼、是否能執行帶有攻擊性的測試、測試資料會不會外流、能否自動修改正式環境，皆應事先以明確的角色與權限規範管理。企業不應把研究文章中的實驗能力，直接轉換成「授權 AI 在全部生產主機嘗試提權」。

台灣企業應如何調整漏洞管理，而不是急著買新工具

如果企業有 Linux 伺服器、Kubernetes 節點、網路設備或含 Linux 的工業裝置，第一步應整理真正擁有的版本與責任歸屬。弱點資訊需要對照資產清冊、套件與核心版本、公開可用的修補狀態及服務暴露面；沒有這些資料，更多掃描結果只會變成更大的待辦清單。

第二步是訂立「發現到修復」的證據格式。每個高優先弱點至少要有重現條件、受影響版本、影響範圍、可用修補、驗證結果、負責人與截止日。若使用 AI 代理協助，應讓它建立草稿與測試紀錄，由具備權限的工程師批准合併，而非直接修改系統。

第三步是把修補 SLA 與風險分級結合。評估時不能只根據 CVSS 分數，還應考慮是否真的可利用、是否暴露在攻擊鏈上、有無已知利用跡象，以及部署修補所需的停機風險。某個功能重大的服務若使用不受影響的核心版本，就不必僅因新聞出現 948 而啟動緊急停機；反之，已被證實受影響的環境應優先安排更新與緩解措施。

第四步是保留第三方通報與研究者合作管道。新流程若讓發現速度超過企業處理能力，便需要清楚的去重、通報、回覆與責任人制度。把 AI 掃描報告一股腦轉寄給開發團隊，只是把工作從一個隊列移到另一個隊列。

一個可操作的導入驗收方式

企業可以先選一個非正式環境、已獲授權的開源系統或內部示範專案，做為 30 天的資安自動化 PoC。驗收不必追求漏洞總數，而是觀察四個結果：有效候選比例、可重現且符合根因的比例、提出修補後通過測試的比例，以及從接獲報告到確定處置的時間。

這四個指標可以把模型能力和組織能力區分開。即使 AI 一天提出 100 個問題，如果 90 個需要大量人工排除，或修補提案無法通過回歸測試，節省的成本未必如宣傳所示。相反地，一套只找出少量高風險弱點、卻能提供清楚修補證據的工具，也可能比較符合企業需求。

另需明確禁止未授權探測、外部目標測試與無審核的生產部署。團隊在評估 AI 研究能力時，應選用隔離的實驗平台，建立審計日誌，並在必要時與軟體供應商或資安應變團隊合作。這是資安治理的底線，不應為了追求效率省略。

下一階段要觀察的不是 948 會不會變成 9,480

未來研究可能找到更多弱點，但單一數字不一定表示系統正在變得更差。更強的檢測技術可能把既有、長期未被發現的問題顯露出來；修補效率上升也可能讓累積風險逐步下降。需要一起觀察的，是真實可重現率、負責任揭露進度、修補正式合併率、企業實際部署覆蓋率，以及新版本引發的回歸問題。

OpenAI 的研究說明，自動化漏洞發現、利用驗證與修補候選產生已能組成高吞吐量工作鏈。它尚未證明人類研究員可以完全退出，也不表示 Linux 生態系會因這一批報告立即全面失守。真正改變的，是資安工作由「少量發現逐一處理」走向「大量證據持續流入」。能不能把這些證據轉成安全的更新，將決定 AI 資安能力在企業裡是否真的有價值。

防守方最需要建立的，是漏洞證據的「流通標準」

一個安全問題從被發現到正式修補，至少要經過研究者、程式庫維護者、發行版安全團隊、設備供應商與企業內部維運人員。有些企業直接安裝開源 Linux，有些依賴商用發行版，有些使用封裝在設備韌體中的核心。即使根因相同，不同系統的受影響範圍、修補發送方式和停機安排也未必一致。這使跨組織協作遠比單一模型的漏洞發現分數重要。

理想的資訊傳遞不應只有「危急」或「高風險」標籤。研究者提供的重現證據，應能幫助維護者判斷根因；維護者提出修補後，發行版團隊需要核對適用的程式版本；企業維運人員則需要知道自己是否真的受影響，以及有沒有可採取的緩解措施。每轉一次手，如果缺少版本與測試條件，下一個團隊就必須重新做一次調查。AI 讓發現階段提速，也讓建立共通證據格式的需求變得更迫切。

這裡可以借用軟體供應鏈管理的概念。企業應知道哪些產品採用哪些核心版本，哪個供應商承諾提供安全更新，以及何時需要安排實際部署。若設備已超過支援期限，即使上游開源專案迅速修好，企業也不一定能取得廠商包裝好的更新。採購階段就要求供應商說明修補政策、支援年限和重大漏洞通知，往往比事後才詢問更有效。

如何辨認 AI 安全工具提供的是成果還是展示

企業評估資安代理時，可以設計一組事先知道答案、且經過授權的測試集。測試集應同時包含已知漏洞、正常但容易誤判的程式碼、需要特定權限才可觸發的情境，以及看似能成功、其實根因不同的案例。這種盲測比讓廠商自行挑選最漂亮的成功故事更接近真實使用狀況。

評估指標至少應把精確率、召回率、驗證成本、修補成功率和人工審核時間分開。精確率回答「提出的問題有多少是真的」，召回率回答「真正存在的問題有多少被找到」；若沒有完整標註資料，召回率本身可能無法可靠估計。可重現的高風險漏洞數也不能直接當成精確率，因為它的分母是被測試的候選問題，未必涵蓋所有真實弱點。

修補階段可比較兩種情況：原本團隊自行處理需要多久，以及引入 AI 後從發現到通過測試實際節省多久。每個測試必須控制系統版本、相同人員投入及回歸測試要求。如果 AI 產生一個看似可行、卻造成既有功能失效的修改，那不是完成修補，而是把風險轉到其他地方。

資安主管應避免的兩種極端反應

第一種極端是恐慌式全面更新。看到近千個漏洞就要求所有系統立即重啟，可能在沒有確認受影響範圍時造成營運中斷；若大型企業的關鍵系統涉及跨區域服務，這類操作還可能帶來新的可用性風險。正確做法是先確認供應商公告、版本與修補可用性，再安排分級變更。

第二種極端是認為研究與自己無關。即使本次實驗沒有證明某一台企業伺服器已被攻擊，漏洞發現技術加快仍可能影響未來風險分布。已有資產清冊和補丁流程的企業，可以把更新週期與高風險處置責任重新檢查一次；沒有資產清冊的企業，至少應開始盤點可公開存取、承載關鍵資料及使用過期核心的設備。

這也說明負責任的 AI 資安導入，不應把攻擊與防守能力混成一套沒有邊界的自動化。研究環境隔離、審查權限、結果去重、供應商協作、正式部署批准和可回復機制，每一環都有不同負責人。管理層要問的不是「AI 一次可挖出幾千個問題」，而是「公司的修補能力能否跟上發現能力」。

延伸問答

948 個漏洞是否都已修好？

不能如此判定。OpenAI 提到部分已修補、部分有候選補丁、部分在公開通報討論，並未宣稱全部修補完成。不同發行版的實際狀態仍須核對其維護公告。

這代表所有 Linux 主機都能直接從網路被入侵嗎？

不是。報告關注的是特定測試條件下的本地權限提升問題，不能直接等同遠端未授權入侵。具體風險取決於核心版本、可達條件與其他防護。

企業能否讓 AI 自動修復正式系統？

可以研究以 AI 輔助製作候選修補，但正式變更仍應經過權限審核、回歸測試、部署批准與回復機制。把 AI 輸出直接當成已驗證的安全修補，風險過高。

資料來源與說明

1. OpenAI，A thousand fewer paths to root，2026／11／04。本篇技術實驗數字、方法、成本與通報進度主要依此研究自述；未取得每個漏洞的第三方逐一驗證資料。
2. OpenAI Research 研究總覽，2026／11／04。核對此研究已列入官方研究公布頁；與第一項屬同一機構，並非獨立的第三方驗證。

本文屬資安產業分析，不提供可直接攻擊第三方系統的利用程式或未授權測試指引。資料查核截止：2026 年 11 月 5 日。

圖片資訊

封面為本專題製作的 AI 生成概念插畫，不是新聞現場實拍。

延伸閱讀

探索更多企業 AI 知識與實務 · Iris Hsieh 的專題文章