一則訊息、一個 root 權限：LMCache 未修補的 CVSS 9.8 遠端程式碼執行漏洞暴露 vLLM 推論叢集

AI 基礎設施圈迎來了本季第一個頭條級安全漏洞，而且狀況相當難看。2026 年 10 月 7 日，JFrog 的安全研究團隊揭露 CVE-2026-105192——開源分布式 KV 快取層 LMCache 的一個重大遠端程式碼執行（RCE）漏洞。LMCache 正是加速 vLLM（目前部署最廣的 LLM 推論引擎之一）的關鍵元件。該漏洞的 CVSS 評分高達 9.8／10，而且截至發稿時沒有任何修補版本存在。從 0.3.9（2025 年 10 月發布）到目前最新的穩定版 0.5.5 全部中鏢，連 0.5.6 的候選版本與開發分支也不例外。

對一個在 2026 年急著把 AI agent 推到客戶面前的產業來說，這項發現是一記響亮的提醒：那些 agent 底下的管線，往往只距離一次完整的系統淪陷——差在一個設定錯誤的旗標。

漏洞原理

LMCache 透過快取 KV-cache 區塊來加速 LLM 服務，讓重複或共享的前綴提示詞不必重新計算。在它的多程序模式（也稱分布式模式）下，快取以獨立伺服器的形式運行，LLM 工作程序透過 ZeroMQ 訊息庫與它通訊——這正是多節點部署用來跨機器共享快取的架構。

問題出在伺服器處理訊息的方式。它開啟的 ZeroMQ ROUTER socket（預設埠號 5555）完全沒有任何身分驗證。抵達的訊息以 msgpack 編碼，但其中一個擴充代碼（code 1）會被交給 DeviceIPCWrapper.Deserialize，而它呼叫的是 pickle.loads。Python 的 pickle 格式可以夾帶可執行程式碼，反序列化時就會執行。更糟的是，這個反序列化發生在伺服器還在解碼請求參數的階段——在 handler 執行之前、在任何訊息類型檢查之前，所以攻擊者根本不需要通過任何驗證層。

結果是：只要向傳輸埠送出一則未經驗證的 ZeroMQ DEALER 訊息，就能以 LMCache 程序的使用者身分執行程式碼。而在專案的官方容器映像中，這個程序是以 root 執行的。漏洞由 JFrog 的 Yuval Moravchick 發現。

誰真正暴露在風險中

一個部署是否可被遠端利用，取決於單一設定。預設情況下，多程序伺服器只綁定在 localhost，外部主機無法連入。只有當維運人員透過 --host 指定可路由位址時，它才會變成遠端可達——而這恰恰是多節點部署讓其他節點連入的標準做法。

令人不安的地方在於：LMCache 官方的範例 Kubernetes 部署就是這樣寫的——伺服器監聽所有網路介面。凡是把這份參考設定直接搬進正式環境的團隊（拿廠商範例來用再正常不過），等於在自己的推論叢集上開了一個 root 級、無需驗證的 RCE。相對地，在單一 vLLM 程序內运行的 LMCache 根本不會開啟這個埠。

在修補版本問世之前，JFrog 的建議是維運層面而非技術層面的：不要給多程序伺服器分配可路由位址；把埠號留在本機或受信任的叢集網路內。用防火牆限制可連入埠號的主機能降低風險，但無法根除——任何還能建立連線的主機都 能執行程式碼。以非 root 使用者執行程序、限縮容器權限可以縮小爆炸半徑，啟用 ZeroMQ 身分驗證（或改用帶簽章的訊息協定）則能補上信任缺口——但這些都不能取代真正的修補。

雪上加霜的是，LMCache 尚未為此漏洞發布安全公告，而 JFrog 的揭露內容也沒有提供維運人員判斷伺服器是否已被攻擊的方法。

更多報告，以及一個已修補的近親

這次揭露並非孤立事件。就在 CVE 公開的前一天（10 月 6 日），一個 GitHub 帳號對 LMCache 提出了六份額外的安全報告，指控存在未經驗證即可讀取不同租戶快取資料的問題，以及多個無需登入即可執行指令的網路服務。這些報告目前仍是未證實的概念性指控，沒有 CVE 編號也沒有修補——不過其中一項指出的預設值已經改變：0.5.5 中監聽所有介面的管理 HTTP 伺服器，在 0.5.6 候選版中已改為只監聽 localhost。

相較之下，vLLM 本身的一個相關漏洞已經修好。在 0.30.0 版（9 月 22 日發布）之前，一則帶有畸形 cache_salt 值的請求就可能讓使用 LMCache 多程序連接器的部署整個引擎當掉——這是一個追蹤編號為 CVE-2026-105756 的阻斷服務漏洞，評分 6.5，無法執行程式碼。

模式重演：ShadowMQ 幽靈再現

把來自未驗證網路 socket 的資料直接交給 pickle——這個核心錯誤，與研究人員在 2025 年 11 月於其他 AI 推論框架中歸類為 ShadowMQ 的一系列漏洞如出一轍。LMCache 的程式碼是否與那些專案有共同來源尚未證實，但重複出現本身就說明了結構性問題：當團隊把高效能 IPC 疊加到推論堆疊上時，過去在單一受信任程序內尚可容忍的序列化格式，正被暴露到從未被設計為可信任的網路上。

時機再諷刺不過。本週 Pwn2Own Ireland 才為 32 個零時差漏洞付出 388,500 美元獎金——其中包括針對 OpenAI Codex 與 LiteLLM 的完整接管攻擊鏈。LLM 閘道器、快取層與程式碼 agent 已不再是假想中的攻擊面；它們是活的，而且上面還掛著賞金。

維運人員今天該做的事

如果你以多程序模式运行 vLLM + LMCache：立刻檢查 --host 綁定。如果伺服器綁在可路由介面上，請將該主機視為潛在已淪陷，把埠號收回 localhost 或隔離的受信任網路。以非 root 使用者執行程序、限縮容器權限、用嚴格的防火牆白名單圍住埠號，並密切注意 LMCache 儲存庫的修補版本動態——因為在修補推出之前，唯一真正的修法就是「連不到」。

對 AI 基礎設施團隊而言，更根本的教訓比這波熱潮還要老：對未驗證輸入做反序列化，就等同於遠端程式碼執行。輸入是 KV-cache 區塊、伺服器是 LLM 加速器，這些事實都不會改變數學——只會改變盯著它的人有多少。