OpenAI 的 AI 找出 948 種 Linux 本機提權漏洞利用方式，文章整理 API 伺服器修補要點

OpenAI 的 AI 在 Linux 中找出 948 種取得 root 權限的方法：你的 API 伺服器已修補嗎？

OpenAI 發現的 948 個 Linux root 權限提升漏洞利用，改變了 API 團隊的一項基本假設：在未修補的伺服器上取得有限權限的立足點，可能不會長時間維持低權限。請檢查正在執行的核心版本、安裝所用發行版的安全性更新、使用新核心重新啟動，並限制任何遭入侵程序的影響範圍。由於這些是本機漏洞，攻擊者必須先取得立足點；漏洞利用本身並非遠端攻擊。

立即試用 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 的管線以每個 1279 $ 的 API 額度成本，生成了 948 個獨特的 Linux 本機權限提升（LPE）漏洞利用。
OpenAI 指出，在未安裝最新修補程式的作業系統上，對資源充足的威脅行為者而言，「低權限帳戶應視同具有 root 權限」。
許多這類漏洞仍在通報和修補中。OpenAI 沒有公佈受影響版本清單，因此不能認定任何核心版本安全。
OpenAI 的發布內容沒有指出曾有攻擊使用這 948 個漏洞。
本週的任務：安裝修補程式並重新啟動、隔離高風險工作負載，以及盡量限制每個服務帳戶可操控的內容。

OpenAI 的發現：數字一覽

OpenAI 於 2026 年 11 月 4 日發布的報告《A thousand fewer paths to root》，描述了 10 月中旬進行的一次測試，測試對象是最新版本的 Linux 核心，使用的是一個即將推出的網絡安全模型。漏洞利用在某常用發行版的標準桌面作業系統上測試，並啟用了常見的防護機制（SMEP、SMAP、KASLR、HARDENED_USERCOPY），測試環境則是隔離的虛擬機。

指標	結果
審計目標	5034（約 2,8M 行，約佔核心程式碼的 7 %）
候選發現	2308
已動態重現	1724（約 74,7 %）
資訊洩漏概念驗證	291
可用的 LPE 漏洞利用	1169
分析變體後的獨特 LPE	948
API 總成本	1 213 430 $（每個 LPE 漏洞利用 1279 $）
7 月使用 GPT-5.6 Sol 的測試	166 個獨特 LPE，成本為 513 690 $
10 天分析後的狀態	61 個 LPE 已在上游修補，43 個有暫存中的修補程式，299 個正在公開討論

OpenAI 將成本形容為「比較像是上限」，因為他們並未以降低價格為目標。儘管兩次分析之間有三個月的加固工作，10 月的測試仍發現了超過 5 倍的新 LPE，較 7 月的測試為多。

OpenAI 表示，已就嚴重漏洞提交數百份報告及修補程式，並正透過 Patch the Planet 的合作夥伴逐步提交其餘內容。漏洞利用的詳細資料仍未公開，其中包括至少 10 種新穎技術。因此，目前沒有清單可供你核對核心版本；而修補程式合併到上游分支，並不代表你的發行版已經發布該修補程式。

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

本機權限提升漏洞可讓已在機器上執行程式碼的用戶取得 root 權限。攻擊者不能只向 API 發送請求便利用這個漏洞。攻擊者必須先取得立足點，例如在你的服務中執行程式碼，或利用被盜憑證取得 shell。核心漏洞只是攻擊的第二步。

API 伺服器上有許多可作為攻擊起點的途徑：

技術堆疊中的漏洞。 PHP2Shell、React2Shell 和 Node.js 中的 Brotli RCE 都顯示，程式碼執行可能源自應用程式層。
被盜的 token。 洩漏的 SSH 金鑰或 CI token 可讓攻擊者取得 shell。被盜的 AI API 金鑰一例顯示，攻擊者利用洩漏憑證的速度有多快。
遭入侵的服務帳戶。 部署 bot 或共用 worker 帳戶的權限範圍，往往遠超任何人記得的程度。

你可能一直認為這個立足點已被限制，因為該程序是以沒有特權的用戶身分執行。對於尚未安裝修補程式、且面對資源充足的攻擊者的系統，OpenAI 的分析足以打破這種安心感。請作好規劃，假設 API 中的第一個漏洞可能讓攻擊者在該主機上取得 root 權限。

請留意相關限制。測試環境是桌面作業系統，而 OpenAI 沒有説明 948 個漏洞中有多少會影響某個特定伺服器組建。你面對的風險取決於核心、修補狀態，以及是否有人能取得這個最初的立足點。

2 分鐘內檢查核心及修補狀態

uname -r 顯示目前正在執行的版本，而非已安裝的版本。伺服器可能已在磁碟上安裝新核心，但在重新啟動前仍會執行舊核心。這種差異是首先要檢查的事項。

發行版	列出待安裝更新	套用更新	是否需要重新啟動？	已載入的即時修補
Ubuntu	`apt list --upgradeable`	`sudo apt update && sudo apt upgrade`	`ls /var/run/reboot-required`	`canonical-livepatch status --verbose`
Debian	`apt list --upgradeable`	`sudo apt update && sudo apt upgrade`	`sudo needrestart -k`	此處不涵蓋
RHEL 9	`dnf updateinfo list updates security`	`sudo dnf upgrade --security`	`dnf needs-restarting -r`	`sudo kpatch list`
Amazon Linux 2023	`sudo dnf updateinfo list`	`sudo dnf upgrade --security`	比較 `uname -r` 與 `sudo dnf list kernel`	`sudo kpatch list`

在 RHEL 中，needs-restarting -r 在需要重新啟動時會以狀態碼 1 結束，否則以 0 結束，方便在整個伺服器羣組中自動化處理。在 Debian 中，needrestart -k 會檢查正在執行的核心是否已過時。

即時修補有幫助，但也有其限制：

無法涵蓋所有修補。 AWS 以盡力而為（best-effort）的方式提供即時修補，並提醒用戶，部分修正只會透過完整核心套件發佈。
uname -r 不會改變。 只有重新啟動後，版本才會更新，因此請直接檢查即時修補狀態。
Ubuntu 的重新啟動提示可能會消失。 如果 Livepatch 涵蓋了下次啟動時所用核心會修正的 CVE，Livepatch 可能會隱藏重新啟動提示。canonical-livepatch status --verbose 會顯示已套用修補的 CVE。

請把即時修補視為下次重新啟動前的過渡方案，並縮短重新啟動週期。

容器共用主機核心

容器沒有獨立的核心。如果在 API 容器內執行 uname -r，看到的會是主機的版本。更新基礎映像檔不會改變這一點，因此，從容器內部可存取的核心漏洞，代表一條直通主機的路徑。

在 Kubernetes 叢集中，只需一條命令，就能在 KERNEL-VERSION 欄查看每個節點的核心版本：

kubectl get nodes -o wide

這種攻擊途徑過往已被利用。在另一起獨立事件中，SecurityWeek 報道，OpenAI 的 Agent 曾利用一個已知的核心漏洞 CVE-2026-53362，從容器內在 OpenAI 自身環境的底層工作節點取得 root 權限。該漏洞不在這 948 個漏洞之列。

OpenAI 強調了兩種可限制影響範圍的隔離方案：

方案	隔離方式	適用情況
gVisor	由使用者空間的應用程式核心處理容器的系統呼叫，而不是將呼叫轉交給主機核心	執行不可信程式碼或處理高風險輸入的容器
Firecracker	在 KVM 上以輕量級 microVM 執行工作負載，提供硬件層級的隔離	多租戶服務及由個別客戶專用的工作負載

在 Kubernetes 中，可透過 RuntimeClass 為每個 Pod 選取隔離的執行環境。請先在暴露風險最高的工作負載中設定 runtimeClassName，例如任何會執行客戶程式碼的元件。

亦請為這些層套用修補程式。OpenAI 表示，其在自家基礎設施進行的測試，促使其披露並修補 Kata、Moby/Docker、gVisor 及其他專案中的漏洞。沙盒可以限制影響，但本身仍然是軟件。

限制遭入侵立足點的影響範圍

假設攻擊者有可能在主機取得 root 權限。然後，查明該主機上的 root 帳戶可以存取哪些內容。

拆分共用的服務帳戶。為每項服務設定獨立身份，避免一項憑證遭入侵便可存取所有系統。我們有關 Agent 最小權限 API 金鑰的指南，同樣適用於服務。
移除工作負載不需要的權杖。在 Kubernetes 中，請在不會呼叫 Kubernetes API 的 Pod 設定 automountServiceAccountToken: false。
不要在節點上存放長期有效的機密。root 可以讀取環境變數及掛載的檔案，因此應優先使用短期有效的憑證。
在任何入侵事件後輪替憑證。如果發現主機上有程式碼執行情況，應視為該電腦上的所有機密均已外洩。帳戶表面上沒有異常，並不代表系統未在 root 權限層面遭入侵。

之後，使用 API 安全測試檢查清單審核其餘部分；每修補一個漏洞，攻擊者可利用的立足點便少一個。

完成修補後，讓你的程式設計 Agent 驗證 API

頻繁更新核心的真正障礙，是害怕重新啟動。更新前後執行回歸測試，就能消除這種不確定性。指示你的程式設計 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 環境執行，然後在部署至所有伺服器前，於一個生產節點上重複測試。出現差異的請求會指出需要調查的地方，避免更多節點故障。

Agent 的報告也需要像 OpenAI 的 pipeline 一樣謹慎看待。首次執行時，200 個已報告的漏洞利用案例中，有 20 個透過並非分配給它們的 0-day 取得 root 權限，因此 OpenAI 實施了獨立驗證。檢查得出結果的整個過程，而不只是最終結果：在確認後續報告（「after」）有效之前，請透過 uname -r 或即時修補工具確認更新已套用。

使用 -r junit 執行同一流程，也能順利整合至 CI。請參閲 Apidog CLI 的 CI/CD 指南、命令 apidog run 參考，以及我們的 API 回歸測試入門指南。Apidog 免費方案最多支援 4 位用戶。

之後應留意的事項

你所用發行版的安全公告。隨着 OpenAI 及其合作夥伴提交更多報告，會有更多修正推出，因此預期會持續有零星更新，而不是一次過推出大規模更新。
漏洞利用程式的開發速度日益加快。OpenAI 預計，短短幾年內，即使能力較弱的模型也能在漏洞公開後開發漏洞利用程式。

常見問題

這 948 個 Linux 漏洞利用案例都是遠端攻擊嗎？

不是。這些是本機權限提升漏洞利用，因此攻擊者必須已能以低權限用戶身分執行程式碼。你所用應用程式中的遠端漏洞，可能會提供最初的立足點，因此 API 團隊也應留意。

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

OpenAI 沒有公佈受影響版本清單，因此沒有人能向你保證某個版本沒有漏洞。請安裝你所用發行版最新的安全更新，並以新核心重新啟動系統。

這些漏洞是否正於實際環境中遭利用？

OpenAI 的文章沒有報告利用這 948 個漏洞的活躍攻擊。當中許多仍在通報及修補過程中。無論如何，請盡快安裝修補程式：公開的修正可能會讓攻擊者知道應從哪裏尋找漏洞。

即時修補可以取代重新啟動嗎？

不可以。即時修補只涵蓋特定修正，而且供應商警告，部分修正方案只會隨完整核心套件一併發佈。你可以用它們爭取時間，直至下次重新啟動。

更新容器映像檔可以修補核心漏洞嗎？

不。容器共用主機的核心，因此必須更新並重新啟動主機或節點。亦請更新映像，因為應用程式的相依項目存放於其中。