OpenAI 的 AI 找出 948 個 Linux 本地提權漏洞利用程式，API 伺服器如何檢查修補狀態？

OpenAI 的 AI 發現 Linux 上 948 種取得 root 權限的方法：你的 API 伺服器已修補漏洞嗎？

OpenAI 的自動化流程在 Linux 上生成了 948 個各不相同的本機權限提升（LPE）漏洞利用程式，每個僅花費 1,279 USD 的 API 額度。這項發現動搖了 API 開發團隊長久以來的一個假設：在未修補漏洞的伺服器上取得低權限立足點後，難以長期維持低權限。立即要做的事：檢查目前執行的核心版本、安裝 Linux 發行版的安全更新、重新啟動以使用新核心，並限制遭入侵程序可存取的範圍。這些都是本機漏洞（local bug），因此攻擊者必須先取得立足點——漏洞本身並非遠端漏洞利用程式（remote exploit）。

立即試用 Apidog

uname -r              # the kernel you're running now
cat /etc/os-release   # your distro and version
uptime                # how long since the last reboot

快速摘要

• OpenAI 的自動化流程生成了 948 個各不相同的 Linux 本機權限提升（LPE）漏洞利用程式，每個僅花費 1,279 USD 的 API 額度。
• OpenAI 認為，對擁有充足資源的威脅行為者而言，在未安裝最新修補程式的作業系統上，低權限帳戶「在實際效果上，應視同擁有 root 權限。」
• 其中不少漏洞仍在通報及修補階段。OpenAI 沒有公開受影響版本清單，因此目前沒有任何核心版本可視為完全安全。
• OpenAI 的文章沒有記錄任何在實際攻擊中使用這 948 個漏洞的個案。
• 本週要做的事：安裝更新並重新啟動、隔離高風險工作負載，並盡可能縮減每個服務帳戶（service account）的權限。

OpenAI 的發現：具體數字

OpenAI 題為「A thousand fewer paths to root」的報告（少一千條通往 root 的路徑）於 2026 年 11 月 4 日發表，描述了 10 月中旬使用一款即將推出的網絡安全模型，針對最新 Linux 核心進行的掃描。漏洞利用程式在常見 Linux 發行版的標準桌面作業系統上進行測試，並啟用了所有標準防護機制（SMEP、SMAP、KASLR、HARDENED_USERCOPY），測試環境則是隔離的虛擬機器。

OpenAI 表示，上述成本「只是上限估算」，因為他們沒有專門優化成本。10 月的測試發現的新 LPE 數量也比 7 月多出 5 倍以上，儘管兩次掃描之間已有三個月的安全加固。

OpenAI 表示，已就嚴重漏洞提交數百份報告及修補程式，並正與 Patch the Planet 倡議的合作夥伴協調，繼續提交其餘內容。漏洞利用的詳細資料仍未公開，其中包括至少 10 種全新的技術。因此，目前沒有清單可供你對照核心版本；而修補程式出現在上游，也不代表你的 Linux 發行版已及時推出更新。

對 API 伺服器而言，「本機」代表甚麼

本機權限提升（LPE）漏洞可讓原本已能在主機上執行程式碼的用戶提升權限至 root。攻擊者無法單靠向你的 API 發送一個請求觸發此漏洞。他們首先需要取得立足點，例如在服務內執行程式碼，或透過被盜的登入資料取得 shell 存取權。Kernel 漏洞則是第二步。

API 伺服器本身已有不少途徑可讓攻擊者完成第一步：

• 技術堆疊漏洞。 PHP2Shell、React2Shell 和 Node.js Brotli RCE 等事件都顯示，程式碼執行權限可以直接來自應用程式層。
• 令牌外洩。 SSH 金鑰或 CI 令牌外洩，可能讓攻擊者直接取得 shell 存取權。AI API 金鑰被盜的情況，正好説明外洩的登入資料會多快遭到利用。
• 服務帳戶遭入侵。 部署機械人（deploy bot）或共用 worker 帳戶通常持有的權限，比我們想像的更多。

以前，你可能會認為這個立足點仍在可控範圍內，因為程序只以非特權用戶的權限執行。然而，OpenAI 的觀點已令面對資源充足的攻擊者時，未安裝修補程式的系統不再令人安心。請按情境制定應變方案：單一 API 初始漏洞完全可能導致伺服器失去 root 權限。

不過，也必須正確認識這項研究的限制。測試對象是桌面作業系統，而 OpenAI 沒有説明這 948 個漏洞中有多少適用於特定伺服器版本。風險程度取決於 kernel、修補程式狀態，以及攻擊者能否建立第一個入侵點。

在 2 分鐘內檢查 kernel 和修補程式狀態

uname -r 指令顯示的是目前正在運行的版本，而非已安裝的版本。伺服器的磁碟上可能已安裝較新的 kernel，但在重新啟動前仍會繼續使用舊 kernel。這個版本落差正是你首先需要檢查的地方。

在 RHEL 上，needs-restarting -r 指令在需要重新啟動時會回傳結束代碼 1，無需重新啟動時則回傳 0，方便你在整個伺服器機羣中編寫自動化指令碼。在 Debian 上，needrestart -k 用來檢查目前的 kernel 是否已過時。

即時修補有不少好處，但仍有一些限制：

• 無法涵蓋所有情況。 AWS 以盡力而為（best-effort）的方式提供即時修補，並指出部分修補程式只會隨完整 kernel 套件一併發布。
• uname -r 不會改變。 版本只會在主機重新啟動後改變，因此請直接檢查即時修補的狀態。
• Ubuntu 上要求重新啟動的提示可能會消失。 當 Livepatch 已處理下一個 kernel 修正的 CVE 時，Livepatch 可能會移除重新啟動提示。你可以使用 canonical-livepatch status --verbose 指令查看已套用的 CVE。

請把即時修補視為下次重新啟動前的暫時方案，同時縮短系統重新啟動週期。

容器與主機共用核心

容器並沒有自己的核心。在包含 API 的容器內執行 uname -r，你會看到的正是主機的核心版本。更新基礎映像檔完全不會影響這個核心；因此，能從容器內接觸到的核心漏洞，正是直接入侵主機的跳板。

對於 Kubernetes 叢集，只需一個命令，就能在 KERNEL-VERSION 欄查看所有節點的核心版本：

kubectl get nodes -o wide

這種攻擊情況確實曾經發生。在一宗獨立事件中，SecurityWeek 報道，OpenAI 的 Agent 曾利用一個已知核心漏洞（CVE-2026-53362），從容器內取得底層工作節點的 root 權限；事件發生在 OpenAI 的內部環境。該漏洞不在今次的 948 個漏洞利用程式之列。

OpenAI 提出兩種隔離方案，以便在遭受攻擊時縮小影響範圍：

在 Kubernetes 中，你可以透過 RuntimeClass 為每個 pod 設定獨立的沙盒 runtime。請先為風險最高的工作負載設定 runtimeClassName，例如任何會執行用戶程式碼的服務。

別忘記修補這些層本身的漏洞。OpenAI 表示，內部基礎架構測試協助他們在 Kata、Moby/Docker、gVisor 及其他專案中發現並修補多個漏洞。沙盒有助減輕損害，但沙盒本身仍是軟件。

收窄攻擊者可接觸的範圍

要有心理準備，伺服器被取得 root 權限完全有可能。接着，找出並限制該伺服器上的 root 權限可以接觸的內容。

1. 分拆共用的服務帳戶。為每項服務設定獨立身分，避免單一憑證外洩便讓攻擊者直接進入整個系統。我們關於為 Agent API 金鑰套用最低權限原則的指南，同樣適用於服務。
2. 移除工作負載不會使用的 token。在 Kubernetes 中，對不需要呼叫 Kubernetes API 的 pod 設定 automountServiceAccountToken: false。
3. 不要在節點上儲存長期有效的 secret。root 權限可以讀取所有環境變數和已掛載的檔案，因此應優先使用有效期較短的憑證。
4. 發現入侵後，立即撤銷並輪替（rotate）。如果發現有惡意程式碼在伺服器上執行，應假設該伺服器上的所有 secret 都已外洩。帳戶看似正常，並不能證明該機器從未被取得 root 權限。

接下來，使用API 安全測試檢查清單（API security testing checklist）檢查整個系統，因為你在這一層修補的每個漏洞，都會減少攻擊者建立立足點的機會。

讓 coding agent 在修補漏洞後重新測試 API

頻繁更新核心時，最大的阻礙往往是對重新啟動系統的擔憂。在升級前後進行回歸測試，就能消除這種顧慮。讓 coding agent 在更新前後，使用同一套測試透過 Apidog CLI 執行測試，然後比較結果。

初始設定只需設定一次：

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

之後，向你的 agent 提供以下唯一提示詞：

Find my API regression suite in Apidog project <id> and run it against the
staging environment. Save the reports to reports/before. Stop and wait while
I update the kernel and reboot. When I say done, run the same suite to
reports/after, compare both reports, and list every request whose status or
assertion result changed.

Agent 會自動執行以下命令：

apidog test-suite list --project <id>
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/before
# you update the kernel and reboot
apidog run --test-suite <id> --project <id> -e <envId> -r cli,junit --out-dir reports/after

請先在 staging 環境開始，然後在全面部署至整個伺服器叢集前，於一個 production 節點重複這個流程。一個會改變狀態的請求，可以讓你在其他節點出現問題前，準確找出問題所在。

對 agent 的報告，也應像 OpenAI 的流程一樣謹慎核實。在一次初步測試中，200 個已報告的漏洞利用程式中，有 20 個透過不同於指定漏洞的另一個 0-day 漏洞取得 root 權限，迫使 OpenAI 加入獨立驗證步驟。不要只看結果，也要核實得出結果的過程：使用命令 uname -r 或即時修補工具，確認更新確實已成功載入，才相信「更新後」的報告。

這個附有 -r junit 旗標的命令亦完全適用於 CI 系統。詳情請參閲 將 Apidog CLI 整合至 CI/CD 的指南、命令 apidog run 的文件，以及介紹 API 回歸測試 的基礎文章。Apidog 免費方案最多支援 4 位用戶。

接下來需要留意的事項

• 發行版發出的安全警示。隨着 OpenAI 及其合作夥伴繼續提交報告，將會推出更多修補程式，因此請準備應對接連不斷的更新，而非只有一次發布。
• 漏洞利用程式的開發速度愈來愈快。OpenAI 認為，未來幾年內，即使較不先進的模型，也可能在漏洞公開後立即自動編寫漏洞利用程式。

常見問題（FAQ）

這 948 個 Linux 漏洞利用程式可以遠端執行嗎？

不可以。這些是本地權限提升（LPE）漏洞利用程式，代表攻擊者必須已能以低權限用戶身分執行程式碼。應用程式中的遠端漏洞可能為攻擊者提供這個立足點，這正是 API 開發團隊需要留意的原因。

我的核心版本是否受影響？

OpenAI 沒有公佈受影響的版本清單，因此沒有人能指出一個絕對安全的版本號碼。最佳做法是安裝發行版提供的最新安全更新，然後重新啟動系統以使用該核心。

這些漏洞是否已在實際攻擊中被利用？

OpenAI 的文章沒有記錄任何利用這 948 個漏洞的實際攻擊。許多漏洞目前仍處於負責任披露流程中，正等待修補。即便如此，現在就應更新，因為公開的修補程式可能會無意中提示攻擊者應集中攻擊哪些地方。

即時修補能否完全取代重新啟動？

不可以。即時修補只能處理某些特定問題，而各供應商均清楚指出，許多修補程式只會包含在完整的核心更新套件中。請將即時修補用作權宜措施，直至下次重新啟動電腦。

更新容器映像檔有助修補核心漏洞嗎？

不可以。容器與主機伺服器共用核心，因此你必須更新並重新啟動該伺服器或節點本身。不過，你仍需要更新映像檔，因為當中包含應用程式的相依程式庫。