編按：本文綜合整理自 Nebula Security IonStack Part II 原文、The Hacker News 報導、AlmaLinux 官方修補公告、Red Hat Security Bulletin RHSB-2026-010、Cybernews AI 發現分析，並加入 Siami 編輯部觀點與分析。
一個藏在 Linux 核心深處的漏洞，沉睡了 15 年才被找出來——而且找它的不是人類安全研究員，是 Nebula Security 團隊打造的 AI 代理人 VEGA。這個漏洞被命名為 GhostLock（CVE-2026-43499），藏在 Linux 2.6.39（2011 年釋出）到 Linux 7.1 之間的所有版本。Nebula 把它做成 97% 穩定度的本地權限升級（LPE）exploit，並成功逃出容器，獲得 Google kernelCTF 計畫頒發的 92,337 美元獎金。
漏洞位於 kernel/locking/rtmutex.c 的 remove_waiter() 函式，是一處 stack use-after-free。當程式使用 FUTEX_WAIT_REQUEUE_PI 系統呼叫時，rtmutex 子系統會在「代理路徑」（proxy path）上犯下一個致命的清除錯誤——把 current->pi_blocked_on 指標清除時，卻清錯了對象，造成核心 stack 記憶體留下懸置指標，攻擊者可以把它轉化成任意位址寫入，最終劫持函式表取得 root 權限。
漏洞技術解析：為什麼一個指標清除錯誤能變 root
要理解 GhostLock 的殺傷力，需要先理解 Linux 的 futex 與 rtmutex 設計。futex 是 Linux 處理「快速用戶空間鎖」的機制，幾乎所有多執行緒程式（glibc pthread、Java 虛擬機、Node.js worker thread）都會用到。為了支援優先權繼承（Priority Inheritance, PI），核心延伸出 CONFIG_FUTEX_PI=y 開關，這個開關在所有主流桌面與伺服器發行版都是預設開啟。
問題出在 2011 年的 commit 8161239a8bcc，當時 Linus 為了簡化 rtmutex 的 PI 演算法重寫了內部狀態機，引入了一個新的程式碼路徑：「代理鎖定」（rt_mutex_start_proxy_lock()）。這個路徑的設計是「讓任務 A 替任務 B 排隊等候 rtmutex」，但**remove_waiter() 函式在錯誤清除時，沒有區分原始 waiter 與代理 waiter**，把 current->pi_blocked_on 指標清除時，卻清錯了對象——清的是「再排隊者」（requeuer），而不是真正擁有 waiter 的任務。
「這是一個最簡單卻最危險的核心錯誤：指標清除的對象搞錯了。在核心空間，這種錯誤會留下懸置指標（dangling pointer），而攻擊者只要再呼叫一次 futex 系統呼叫，就能夠把這個懸置指標重新利用（use-after-free）。」
漏洞從 2011 年的 Linux 2.6.39-rc1 開始存在，直到 2026 年 4 月的 commit 3bfdc63936dd 才被修補。這個修補其實只改了幾行——把 remove_waiter() 改成存取 waiter->task 而非 current，但這幾行的代價是：所有 2011 年以來部署的 Linux 系統，無論是 Android 手機、雲端容器、自架伺服器、家用 NAS，只要沒更新到 Linux 7.1 或拿到下游 patch，都在風險範圍內。
Nebula 的 PoC 把這個原使用後釋放漏洞做成完整的攻擊鏈：
- 第一步：用
FUTEX_WAIT_REQUEUE_PI觸發 rtmutex 的代理路徑，留下 dangling pointer - 第二步：用另一個執行緒對該記憶體位址重新配置資料，把核心的 function table 覆寫
- 第三步：呼叫任意系統呼叫觸發被劫持的 function pointer，取得 root
整個鏈條在 Nebula 的測試中達到 97% 成功率，並且能逃出 Docker 容器（CAP_SYS_ADMIN 預設關閉的標準容器），因為攻擊者只需要在容器內有任意使用者帳號。
為什麼這件事重要
GhostLock 不只是「又多一個 CVE」，它代表三個層面的典範轉移。
第一，它是「AI 代理人挖 bug」時代的最新力證。VEGA 是 Nebula Security 打造的 AI 安全研究 pipeline，能自動掃描開源程式碼、產生測試案例、驗證漏洞可利用性。在 GhostLock 之前，類似的成功案例已經出現：今年四月 Anthropic 研究員用 Claude Code 找到一個 23 年沒被發現的 Linux 核心 heap buffer overflow；今年稍早 Xint 團隊用 AI 掃描挖出 CVE-2026-31431「Copy Fail」漏洞（一個藏了 9 年的弱點）。GhostLock 證明 AI 不只能寫程式，還能主動發現漏洞。
第二，它衝擊 Linux 核心安全維護的根基。今年五月 Linus Torvalds 才公開抱怨核心安全郵件列表「變得無法管理」（unmanageable），並且批評大量 AI 生成的垃圾 bug 報告湧入。GhostLock 的出現讓 Torvalds 面臨兩難：要嘛繼續接受 AI 報告，但要花時間過濾；要嘛抵制 AI 報告，但可能錯過真正的漏洞。Linux 6.19 也因此新增了「什麼構成安全 bug + AI 負責任使用」的官方文件。
從 Torvalds 的角度，這是一個「太多信號雜訊比太差」的問題；但從攻擊者的角度，AI 代理人掃描是一個全新的漏洞供應鏈——未來 5 年，我們會看到越來越多 10 年以上的老 bug 被挖出來。
第三，它重新定義了「零時差攻擊」的防禦節奏。傳統漏洞從「發現→報告→修補→部署」的週期以年為單位；GhostLock 從「公開披露」到「AlmaLinux、Red Hat、CloudLinux、Debian、Ubuntu 全數釋出 patch」只花了不到 48 小時。但「釋出 patch」不等於「使用者安裝 patch」——大量未自動更新的伺服器、IoT 裝置、嵌入式設備，將在未來幾年持續暴露在風險中。
數據解讀：五組數字看 GhostLock 的真實衝擊
要把 GhostLock 的影響講清楚，光說「15 年漏洞」不夠，要看下面這五組數字：
- 15 年 / v2.6.39-rc1 到 v7.1-rc1：漏洞存在範圍覆蓋核心版本橫跨 15 年，幾乎所有仍在運作的 Linux 系統都受影響。Linux 7.1 在 2026 年初發布，修補前的 LTS 版本仍是主流。
- 97% 成功率：Nebula 的 PoC 在測試中達到 97% 的 root 成功率，這對 LPE 漏洞而言是極高數字。相較之下，許多公開 LPE exploit 的成功率在 50-70% 之間。
- $92,337 獎金：Google kernelCTF 計畫頒發的 bug bounty 金額。這個數字本身是 google 對 PoC 完整度與可重現性的評價——不是「找到 bug」的錢，是「完整 exploit chain」的錢。
- CONFIG_FUTEX_PI=y 預設開啟：這個核心配置選項在 Ubuntu、Debian、Fedora、RHEL、AlmaLinux、Arch 等所有主流發行版都是預設值。換言之，沒有「特殊設定」就能觸發——這對資安團隊是壞消息。
- 48 小時內全發行版 patch：從 7 月 8 日公開，到 AlmaLinux、CloudLinux、Red Hat、Debian、Ubuntu 全部釋出 patch，耗時不到 48 小時。但實務上雲端 VM 通常要 7-14 天才會自動套用 kernel patch，家用 IoT 設備更可能永遠不會更新。
「從 48 小時釋出 patch 到全面部署」中間的落差，是 GhostLock 最危險的環節。對攻擊者而言，這是一段**「任何未重啟的 Linux 主機都是目標」**的黃金窗口。
延伸研究：AI 代理人挖 bug 的爆發軌跡
GhostLock 不是孤例。把它放在 2026 年 AI 安全研究的脈絡裡看，會發現一個清楚的趨勢：
- 2026 年 4 月：Anthropic 研究員用 Claude Code 在 Linux 核心找到一個 23 年的 heap buffer overflow，這是首次 AI 在通用作業系統核心挖到長期漏洞的公開案例。
- 2026 年 4 月底：Xint 團隊用 AI 掃描挖出 CVE-2026-31431「Copy Fail」，一個藏了 9 年的弱點，攻擊者可在幾秒鐘內取得 root。
- 2026 年 5 月：Linus Torvalds 公開批評核心安全郵件列表「無法管理」，警告大量 AI 生成的垃圾報告湧入。
- 2026 年 6 月：Linux 6.19 新增官方文件，明確規範「什麼構成安全 bug」與「AI 工具的負責任使用」。
- 2026 年 7 月初：Nebula Security 的 AI 代理人 VEGA 挖出 GhostLock，獲得 $92,337 獎金。
這個時間軸顯示一個殘酷的事實：AI 代理人挖 bug 的速度，已經超過人類研究員。VEGA 不是單純的程式碼掃描器，它會「理解」核心程式碼的語意、推導可能的攻擊路徑、實際執行 PoC 並驗證可利用性。這種「端到端自動化」的能力，讓漏洞從「研究團隊數月工作」變成「AI 代理人數小時運算」。
對企業 IT 與資安團隊而言，這帶來兩個直接挑戰：
- 漏洞庫擴張速度超過 patch 部署速度：AI 代理人每挖出一個老漏洞，patch 團隊就要重新評估所有仍在運行的系統。當漏洞供應速度加快，企業必須從「被動 patch」轉向「主動掃描」。
- 「修復等於免疫」的假設不再成立：GhostLock 即使修補完成，使用者的容器映像檔、CI/CD pipeline、IoT 韌體仍可能保留舊版本。漏洞修復是開始，不是結束。
質疑：GhostLock 的威脅真有媒體說的那麼大嗎？
雖然 The Hacker News、SANS NewsBites、SecurityWeek 都把 GhostLock 報導成「critical」等級漏洞，但有幾點需要冷靜看待：
第一，這是本地權限升級（LPE），不是遠端攻擊。GhostLock 攻擊者必須已經擁有系統上的某個帳號（即使是最低權限的 nobody 帳號）。這跟 SSH 漏洞或網頁應用程式漏洞的衝擊範圍不同——外部攻擊者不能從網路直接打進來，必須先透過其他管道取得初步立足點。
第二，97% 成功率是 Nebula 自己的測試數字。Retr0id 在 HN 留言指出，exploit 對編譯器配置 stack frame 的方式非常敏感，需要為每個核心 build 客製化 offset。這代表公開的 exploit code 不等於在所有環境都能跑。
第三，容器逃逸需要特定條件。雖然 Nebula 聲稱能逃出標準 Docker 容器，但這通常需要容器內有能執行任意程式的能力（不能是 distroless 映像檔或無 shell 的最小化容器）。如果企業已經遵循 least-privilege 原則部署容器，GhostLock 的容器逃逸風險會大幅降低。
第四，修補速度其實很快。主流發行版在 48 小時內都釋出了 patch，這比許多 CVE 的修補週期短很多。真正風險在「沒人重啟伺服器」或「IoT 設備沒人更新」，但這是作業系統層級的普遍問題，不是 GhostLock 獨有的。
把 GhostLock 當作「critical 漏洞」沒錯，但不該把它誇大成「Linux 全面淪陷」。它的真正衝擊是「提醒我們 AI 代理人挖 bug 的時代已經來臨」——這比單一漏洞本身更值得企業注意。
後續發展觀察重點
- AI bug 報告的審查機制：Linux 核心社群如何建立「快速過濾 AI 垃圾報告、有效接收 AI 高品質報告」的雙軌制度，將是未來 12 個月的關鍵觀察點。
- VEGA 與類似 AI 代理人的開源化：Nebula 是否會釋出 VEGA 的部分技術細節，會影響這個領域的整體發展速度。
- 企業 patch 部署策略：GhostLock 是否會促使更多企業從「定期維護窗口 patch」轉向「即時 patch 部署」。
- 保險與合規影響：網路保險公司是否會把「核心漏洞 patch 部署時間」列入承保條件。
- 其他老漏洞的出土潮：VEGA 是否會在未來幾個月繼續挖出更多 10 年以上的 Linux 核心漏洞。
受影響系統與修補狀態
| 發行版 | 修補狀態 | 公告連結 |
|---|---|---|
| AlmaLinux 8 / 9 / 10 | ✅ 已釋出 patch | almalinux.org/blog |
| CloudLinux | ✅ 已釋出 patch | blog.cloudlinux.com |
| Red Hat Enterprise Linux | ✅ 已發布安全公告 | RHSB-2026-010 |
| Debian | ✅ 已 patch | 透過 security channel |
| Ubuntu | ✅ 已 patch | 透過 USN 安全公告 |
| Arch Linux | ✅ 已 patch（滾動更新） | core/linux 套件 |
| Android（核心 5.x+） | ⚠️ 需等 OEM 更新 | Pixel 10 已測試，其餘裝置需自行移植 |
網友熱門留言 (5)