plaincve:~$

// 威脅簡報

CVE-2026-105192

LMCache 多程序模式 ZMQ 傳輸的 pickle 反序列化:不需認證就能遠端執行程式碼,修補已進 dev 分支、尚無正式版

CVSS
9.8 CRITICAL
CISA KEV
未列入
弱點類型
CWE-502 · CWE-306
主題
AI 安全 · 基礎設施

PlainCVE 團隊 · 發布 2026-10-11 · 更新 2026-10-12 · AI 輔助 · 媒體簡報 ↓

AI 審稿 2026-10-12(未經人工)指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

LMCache 多程序模式用 pickle 解碼網路訊息、而且不需認證,能連到它連接埠的人就能執行程式碼;修補已合併進 dev 分支,但還沒有含修補的正式版。

誰會中以多程序(獨立伺服器)模式執行 LMCache v0.3.9 以上(到 v0.5.5、v0.5.6rc3 與 2026-10-07 的 dev 分支),並用 --host 綁定到其他機器連得到的位址的部署。
後果任何能連到傳輸連接埠(預設 5555)的人,送一則訊息就能以 LMCache 程序的使用者身分執行程式碼;依 CNA(JFrog)的說法,官方容器映像檔裡這個身分是 root。
現在該做什麼維護者已在 2026-10-12 把修補合併進 dev 分支,截至 2026-10-12 還沒有含修補的正式版;同日起在 GitHub Releases 發布、由 dev 建置的 nightly 預發布版(0.5.6.dev200)已含修補,但不是正式版。升級時,worker 與多程序伺服器要一起升級。在那之前,依 JFrog 公告的建議(該頁含攻擊程式,本站不連結),不要把 --host 設成可路由的位址,讓連接埠只留在 localhost 或受信任的叢集網路;防火牆只能縮小、不能消除風險。
受影響版本v0.3.9 起的所有版本(CVE 紀錄:0.3.9 ≤ *);JFrog 公告內文指出包含最新 PyPI 版 v0.5.5、v0.5.6 候選版(到 v0.5.6rc3),以及 2026-10-07 時的 dev 分支(JFrog 公告頁首欄位為「>= 0.3.9」;該頁含攻擊程式,本站不連結);2026-10-10 發布的 v0.5.6rc4 早於修補合併,PlainCVE 判斷同樣未含修補
修好的版本尚無含修補的正式版(截至 2026-10-12);修補已於 2026-10-12 合併進 dev 分支(PR #5644,commit 160b6de;該頁含攻擊程式,本站不連結);2026-10-12 起在 GitHub Releases 發布、由 dev 建置的 nightly 預發布版(0.5.6.dev200,commit 6d1aa31 / 762df68,都在 160b6de 之後)已含修補,但不是正式版
CVSS 向量
顯示完整向量CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
時間點
  • 首次公開 2026-10-07

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?
  1. 01確認版本與執行模式

    在哪裡執行:在執行 LMCache 的主機或容器內、LMCache 使用的同一個 Python 環境(venv)裡執行;在別的環境執行可能查不到或查到別的版本。v0.3.9 以上(含 v0.5.5 與 v0.5.6rc3)都受影響。只在 vLLM 程序內部使用 LMCache 不會開啟這個連接埠;要以多程序(獨立伺服器)模式執行才有風險。

    唯讀查詢
    pip show lmcache | grep -i '^version'
  2. 02確認傳輸連接埠綁在哪個位址

    在哪裡執行:在執行 LMCache 伺服器的主機上執行;用容器或 Kubernetes 時,要在該容器或 Pod 的網路命名空間內執行。-p 選項要以 root 執行才看得到程序名稱。若 5555(或你自訂的埠)監聽在 0.0.0.0 或其他可路由位址,其他機器就可能連得到。LMCache 自己的 CLI 文件快速上手範例就是綁 0.0.0.0:5555;據 The Hacker News,其 Kubernetes 範例部署也監聽所有網路介面。

    唯讀查詢
    ss -ltnp | grep ':5555'
    步驟 1
  3. 03JFrog 公告未提供入侵判斷方法

    據 The Hacker News,JFrog 的公告(該頁含攻擊程式,本站不連結)沒有提供判斷伺服器是否已遭攻擊的方法。PlainCVE 的建議:曾經對外開放這個連接埠的部署,應假設無法排除遭入侵的可能。

    步驟 4
MITIGATE修補 / 緩解先修補;還不能修補時先擋住
  1. 01不要把 --host 設成可路由位址

    JFrog 公告(該頁含攻擊程式,本站不連結)建議:在修補版釋出前,讓多程序連接埠只留在 localhost 或受信任的叢集網路。

    步驟 1
  2. 02用防火牆限制連接埠

    JFrog 公告(該頁含攻擊程式,本站不連結)指出這只能減少能連線的對象;任何能連上的主機仍能以 LMCache 使用者身分執行程式碼。

    步驟 1步驟 2
RESPOND應變發現入侵跡象時
  1. 01把曾對外開放的主機當成可能已遭入侵

    PlainCVE 的建議(來源未提供回應指引):隔離該主機或容器、從乾淨映像檔重建,並輪替它能存取的憑證。若使用官方映像檔,依 CNA 說法程序是以 root 執行,影響範圍可能是整個容器。

    步驟 4
HARDEN強化長期避免同類問題
  1. 01以非 root 身分執行 LMCache

    PlainCVE 的建議:程式碼會以 LMCache 程序的使用者身分執行,降低這個身分的權限就能縮小損害。

    步驟 4
  2. 02推論服務的內部連接埠不要直接暴露

    PlainCVE 的建議:不要直接沿用綁 0.0.0.0 的文件範例;把節點間通訊放在隔離的網路區段。

    步驟 1步驟 2
完整修復步驟與說明

目前沒有含修補的正式版:維護者已在 2026-10-12 把修補 PR #5644 合併進 dev 分支(該頁含攻擊程式,本站不連結),但截至 2026-10-12,PyPI 最新版仍是 v0.5.5,GitHub 上最新的候選版 v0.5.6rc4(2026-10-10)早於修補合併。2026-10-12 08:21 起,GitHub Releases 發布了由 dev 建置的 nightly 預發布版(0.5.6.dev200,commit 6d1aa31 與 762df68),依 GitHub 的比對,這兩個 commit 都排在修補 commit 160b6de 之後,所以已含修補;但 nightly 是預發布版,不是正式版。據 The Hacker News,揭露時 LMCache 尚未發布安全公告。以下綁定與防火牆建議來自 JFrog 公告(該頁含攻擊程式,本站不連結;不是 LMCache 官方建議);檢查與持續關注的步驟是 PlainCVE 的建議:

  1. 檢查有沒有對外監聽。 在執行 LMCache 伺服器的主機上(容器或 Pod 則在其網路命名空間內)執行 ss -ltnp | grep ':5555'(若改過埠號請替換;-p 要 root 才看得到程序名稱)。看到 0.0.0.0 或對外 IP 就代表其他機器可能連得到。
  2. 改回 localhost 或受信任網路。 移除指向可路由位址的 --host,或只綁在隔離的叢集網段。Kubernetes 部署請檢查是否沿用了監聽所有介面的範例。
  3. 防火牆只是輔助。 它能減少能連線的主機,但任何能連上的主機仍能執行程式碼。
  4. 持續關注含修補的正式版。 截至 2026-10-12,正式版與候選版(含 v0.5.5 與 v0.5.6rc4)都不含修補,升級到這些版本不能解決問題;只有 2026-10-12 起由 dev 建置的 nightly 預發布版(0.5.6.dev200)已含修補,但它不是正式版。維護者表示修補後舊的 pickle 格式會被拒絕,worker 與多程序伺服器必須一起升級。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

由上到下是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

LMCache 多程序模式 ZMQ 傳輸的 pickle 反序列化:不需認證就能遠端執行程式碼,修補已進 dev 分支、尚無正式版: 1. 找到可連線的 LMCache 傳輸連接埠 → 2. 送出一則未經認證的訊息 → 3. 伺服器在解碼參數時呼叫 pickle.loads → 4. 以 LMCache 程序身分執行攻擊者的程式碼CVE-2026-105192 · LMCache 多程序模式 ZMQ 傳輸的 pickle 反序列化:不需認證就能遠端執行程式碼,修補已進 dev 分支、尚無正式版攻擊者你的系統找到可連線的 LMCache 傳輸連接埠 — 只有在多程序模式、而且操作者用 --host 綁定到可路由位址時,其他機器才連得到(預設是 5555 埠)。預設只綁 localhost。 1找到可連線的 LMCache傳輸連接埠送出一則未經認證的訊息 — 這個 ZeroMQ 通訊端沒有 CURVE、ZAP、密碼或訊息驗證,不需要任何憑證。 2送出一則未經認證的訊息伺服器在解碼參數時呼叫 pickle.loads — msgpack 擴充代碼 1 會交給 pickle 還原物件,而且發生在解碼參數期間、請求處理函式執行之前。 3伺服器在解碼參數時呼叫pickle.loads以 LMCache 程序身分執行攻擊者的程式碼 — 依 CNA(JFrog)的說法,官方容器映像檔以 root 執行 LMCache,這時程式碼會以 root 身分執行。 4以 LMCache 程序身分執行攻擊者的程式碼攻擊路徑可在此擋下PlainCVE · plaincve.date/vulns/cve-2026-105192-lmcache-zmq-pickle-rce · CC BY 4.0
LMCache 多程序模式 ZMQ 傳輸的 pickle 反序列化:不需認證就能遠端執行程式碼,修補已進 dev 分支、尚無正式版: 1. 找到可連線的 LMCache 傳輸連接埠 → 2. 送出一則未經認證的訊息 → 3. 伺服器在解碼參數時呼叫 pickle.loads → 4. 以 LMCache 程序身分執行攻擊者的程式碼CVE-2026-105192 · LMCache 多程序模式 ZMQ傳輸的 pickle 反序列化:不需認證就能遠端執行程式碼,修補已進 dev 分支、尚無正式版找到可連線的 LMCache 傳輸連接埠 — 只有在多程序模式、而且操作者用 --host 綁定到可路由位址時,其他機器才連得到(預設是 5555 埠)。預設只綁 localhost。 1攻擊者找到可連線的 LMCache 傳輸連接埠送出一則未經認證的訊息 — 這個 ZeroMQ 通訊端沒有 CURVE、ZAP、密碼或訊息驗證,不需要任何憑證。 2攻擊者送出一則未經認證的訊息伺服器在解碼參數時呼叫 pickle.loads — msgpack 擴充代碼 1 會交給 pickle 還原物件,而且發生在解碼參數期間、請求處理函式執行之前。 3你的系統伺服器在解碼參數時呼叫 pickle.loads以 LMCache 程序身分執行攻擊者的程式碼 — 依 CNA(JFrog)的說法,官方容器映像檔以 root 執行 LMCache,這時程式碼會以 root 身分執行。 4你的系統以 LMCache 程序身分執行攻擊者的程式碼攻擊路徑可在此擋下PlainCVE · CC BY 4.0plaincve.date/vulns/cve-2026-105192-lmcache-zmq-pickle-rce
圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。
  1. 攻擊者

    找到可連線的 LMCache 傳輸連接埠

    只有在多程序模式、而且操作者用 --host 綁定到可路由位址時,其他機器才連得到(預設是 5555 埠)。預設只綁 localhost。

    防禦: 依 JFrog 公告的建議(該頁含攻擊程式,本站不連結),不要把 --host 設成可路由位址,讓連接埠只留在 localhost 或受信任的叢集網路。

  2. 攻擊者

    送出一則未經認證的訊息

    這個 ZeroMQ 通訊端沒有 CURVE、ZAP、密碼或訊息驗證,不需要任何憑證。

    防禦: 用防火牆限制誰能連到這個連接埠;JFrog 公告(該頁含攻擊程式,本站不連結)指出這只能縮小範圍,能連上的主機仍可執行程式碼。

  3. 你的系統

    伺服器在解碼參數時呼叫 pickle.loads

    msgpack 擴充代碼 1 會交給 pickle 還原物件,而且發生在解碼參數期間、請求處理函式執行之前。

    防禦: 維護者的修補(已合併進 dev 分支)移除了這裡的 pickle,改用有型別的 MessagePack 描述格式;尚無含修補的正式版,2026-10-12 起由 dev 建置的 nightly 預發布版(0.5.6.dev200)已含修補(非正式版),worker 與多程序伺服器要一起升級。

  4. 你的系統

    以 LMCache 程序身分執行攻擊者的程式碼

    依 CNA(JFrog)的說法,官方容器映像檔以 root 執行 LMCache,這時程式碼會以 root 身分執行。

    防禦: PlainCVE 的建議:改用非 root 使用者執行 LMCache,限制被入侵後的損害。

影響範圍

條件是否受影響
LMCache v0.3.9 起的所有版本(CVE 紀錄;JFrog 公告頁首為「>= 0.3.9」,內文指出含 v0.5.5 最新 PyPI 版、v0.5.6rc1 到 rc3、2026-10-07 時的 dev 分支,該頁含攻擊程式,本站不連結;2026-10-10 發布的 v0.5.6rc4 早於修補合併),以多程序模式執行並用 --host 綁定可路由位址受影響,其他機器可遠端執行程式碼
同上版本、多程序模式、維持預設的 localhost 綁定其他機器連不到(見下方 PlainCVE 的判斷)
只在 vLLM 程序內部使用 LMCache不會開啟這個連接埠
v0.3.9 以前多程序傳輸從 v0.3.9 開始才有
修補版尚無正式版;修補已於 2026-10-12 合併進 dev 分支(PR #5644,該頁含攻擊程式,本站不連結);2026-10-12 起由 dev 建置的 nightly 預發布版(0.5.6.dev200)已含修補,非正式版

要被遠端攻擊,需同時符合:以多程序(獨立伺服器)模式執行、操作者用 --host 綁到可路由位址(多節點部署讓其他節點連線就是這樣設的)、攻擊者能連到傳輸連接埠(預設 5555)。不需要任何帳號或密碼。

值得注意的是,LMCache 自己的 CLI 文件快速上手指令就是綁 0.0.0.0 的 5555 埠;據 The Hacker News 報導,其 Kubernetes 範例部署也讓伺服器監聽所有網路介面。PlainCVE 的判斷:以多程序模式照這些範例部署的人,很可能落在受影響的設定中。

本機風險(一手來源沒有評估這點): CVE 紀錄與 JFrog 公告(該頁含攻擊程式,本站不連結)只說預設綁 localhost、其他機器連不到;TheHackerWire(第二手)稱預設綁定下攻擊面限於本機提權或已遭入侵的主機。PlainCVE 的判斷:預設綁 localhost 時,同一台主機上的其他使用者或程序仍可能連得到。

原理

LMCache 是大型語言模型推論用的快取工具,負責讓多個工作程序共享 KV 快取(模型推論過程中暫存的中間結果)。在多程序模式下,它會開一個 ZeroMQ(一種程式間互傳訊息的函式庫)通訊端,讓工作程序註冊並共享快取區塊。這個通訊端沒有任何認證:沒有 CURVE、ZAP、密碼,也沒有訊息驗證。

收到的訊息用 msgpack 格式解碼。LMCache 為 msgpack 定義了一個擴充型別(代碼 1),遇到它就交給 Python 的 pickle.loads 還原物件。pickle 是 Python 的物件存檔格式,還原時能執行任意程式碼,所以絕不能拿來處理來路不明的資料。更糟的是,這一步發生在伺服器還在解碼請求參數時,請求處理函式根本還沒開始執行。

結果是:一則未經認證的訊息,就能以 LMCache 程序的使用者身分執行程式碼。 CNA(JFrog)表示官方容器映像檔以 root 執行這個程序。對應的弱點類型是 CWE-502(不受信任資料的反序列化)與 CWE-306(關鍵功能缺少認證)。在 LMCache 自己的程式庫中,v0.3.9 標籤可看到這段 pickle 還原程式碼,v0.5.5 標籤的 DeviceIPCWrapper 仍使用 pickle 並共用擴充代碼 1。

有問題的思路(概念示意,不是原始程式碼):

展開程式碼範例(python)
def ext_hook(code, data):
    if code == 1:
        return pickle.loads(data)  # 網路上任何人送來的位元組都會被執行式地還原

較安全的思路(概念示意,不是維護者的程式碼;維護者在 dev 分支的修補改用有版本、有型別的 MessagePack 描述格式,從固定的允許清單選擇處理方式,不再使用 pickle):

展開程式碼範例(python)
def ext_hook(code, data):
    if code == 1:
        # 只解析固定欄位的純資料格式,不還原任意物件
        return DeviceHandle.from_plain_fields(msgpack.unpackb(data))
# 並在接受任何訊息前先驗證對方身分

時間軸

日期事件
2025-10-29v0.3.9 推出多程序 ZMQ 傳輸與使用 pickle 的 msgpack 擴充(CNA 時間軸日期),問題由此產生
2026-10-04CVE 編號保留
2026-10-07JFrog 以 CNA 身分公開 CVE 紀錄;此時仍無修補版,dev 分支仍受影響
2026-10-10發布候選版 v0.5.6rc4(早於修補合併)
2026-10-12維護者把修補 PR #5644 合併進 dev 分支(commit 160b6de;該頁含攻擊程式,本站不連結);同日 08:21 起發布由 dev 建置、已含修補的 nightly 預發布版(0.5.6.dev200);尚無含修補的正式版

延伸閱讀

  • 評分: 目前只有 CNA(JFrog)給的 CVSS 3.1 9.8;NVD 狀態為「Deferred」,沒有自己的分析。JFrog 公告(該頁含攻擊程式,本站不連結)說明 9.8 只適用於綁定可路由位址的設定,維持預設綁定的單機安裝其他機器連不到。
  • 利用狀況: 截至 2026-10-07 未列入 CISA KEV;CISA 的 SSVC 評估記錄利用狀態為「none」,沒有來源報告實際遭利用。未修補期間是否曾被利用,沒有資料可確認。依 FIRST EPSS,2026-10-11 的 EPSS(未來 30 天遭利用機率估計)為 0.48%(百分位約 39.7)。
  • 公開 PoC: JFrog 公告內含逐步的概念驗證,維護者的修補 PR #5644 也附有獨立的驗證腳本(兩頁都含攻擊程式,本站不連結)。TheHackerWire 先前說研究程式庫中尚無獨立公開的攻擊程式,這個說法已過時。本站不轉載任何 PoC 內容。
  • 其他編號: GitHub Advisory Database 為 GHSA-vv44-hjm2-qw2f(GitHub 尚未審核);JFrog 為 JFSA-2026-001694382(該頁含攻擊程式,本站不連結)。發現者為 Yuval Moravchick,JFrog Security Research 協調揭露。
  • 偵測: 據 The Hacker News,JFrog 公告(該頁含攻擊程式,本站不連結)沒有提供判斷伺服器是否已遭攻擊的方法。

驗證紀錄 AI 依審稿規則逐項核對來源,全部通過;未經人工審稿,也尚未在我們的環境重現

AI 審稿2026-10-12 · 審稿規則

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見 政策.

來源

  1. CVE / NVD / OSVCVE-2026-105192 Record (CVE Services API) · CVE Program / JFrog (CNA), 2026-10-07 · 查閱 2026-10-07
  2. CVE / NVD / OSVNVD - CVE-2026-105192 · NIST · 查閱 2026-10-07
  3. 安全公告GitHub Advisory Database - GHSA-vv44-hjm2-qw2f · GitHub · 查閱 2026-10-07
  4. 廠商說明lmcache/v1/multiprocess/custom_types.py at v0.3.9 · LMCache (GitHub) · 查閱 2026-10-07
  5. 廠商說明lmcache/v1/platform/base/ipc_wrapper.py at v0.5.5 · LMCache (GitHub) · 查閱 2026-10-07
  6. 廠商說明LMCache CLI: server · LMCache · 查閱 2026-10-07
  7. 新聞報導Unpatched critical LMCache flaw · The Hacker News · 查閱 2026-10-07
  8. 新聞報導CVE-2026-105192: LMCache Unauthenticated Remote Code Execution via ZeroMQ Deserialization · TheHackerWire · 查閱 2026-10-07
  9. 其他CVE-2026-105192 · Strix · 查閱 2026-10-07
  10. 其他EPSS - CVE-2026-105192 · FIRST · 查閱 2026-10-12
  11. 廠商說明LMCache Releases · LMCache (GitHub) · 查閱 2026-10-12

媒體簡報

一句話

LMCache 是用來在大型語言模型推論服務之間共享快取資料的開源工具。研究人員 Yuval Moravchick 發現(由 JFrog Security Research 協調揭露),它的多程序模式會用 Python 的 pickle 還原網路上收到的資料,而且不需要任何認證,能連到該連接埠的人送一則訊息就能在伺服器上執行程式碼。CNA(JFrog)評為 CVSS 9.8;揭露時(2026 年 10 月 7 日)沒有修補版,維護者已在 10 月 12 日把修補合併進開發分支,但截至當天還沒有含修補的正式版(同日由開發分支建置的 nightly 預發布版已含修補)。據 The Hacker News,揭露時 LMCache 尚未發布安全公告。目前沒有遭實際利用的報告。

關鍵數字

嚴重度
CVSS 3.1 9.8(CNA:JFrog;NVD 尚未分析) cveawg.mitre.org
受影響版本
v0.3.9 起的所有版本(CVE 紀錄:0.3.9 ≤ *);JFrog 公告指出包含 v0.5.5、v0.5.6rc3 與 2026-10-07 時的 dev 分支(該頁含攻擊程式,本站不連結) cveawg.mitre.org
修補版本
尚無含修補的正式版(截至 2026-10-12;CVE 紀錄未列修補版,受影響範圍上界為 *);修補已於 2026-10-12 合併進 dev 分支;同日起由 dev 建置的 nightly 預發布版(0.5.6.dev200)已含修補,非正式版 github.com
CVE 公開
2026-10-07 cveawg.mitre.org
發現者
Yuval Moravchick;JFrog Security Research 協調揭露 cveawg.mitre.org

已確認

  • LMCache 多程序模式的 ZeroMQ 通訊端沒有認證,並在解碼參數時以 pickle 還原資料,可導致遠端執行程式碼。
  • LMCache 自己的程式庫在 v0.3.9 與 v0.5.5 標籤中都可看到以 pickle 處理擴充代碼 1 的程式碼。
  • 維護者的修補 PR #5644 已於 2026-10-12 合併進 dev 分支(該頁含攻擊程式,本站不連結);截至 2026-10-12 沒有含修補的正式版;2026-10-12 發布、由 dev 建置的 nightly 預發布版(commit 6d1aa31 / 762df68)排在修補 commit 160b6de 之後,已含修補。
  • 未列入 CISA KEV;CISA 的 SSVC 評估記錄利用狀態為「none」。
  • 已有公開的概念驗證:JFrog 公告內含逐步的概念驗證,維護者的修補 PR #5644 也附有獨立的驗證腳本(兩頁都含攻擊程式,本站不連結)。

尚未確認 / 說法不一

  • 官方映像檔以 root 執行的說法來自 CNA(JFrog),在提供的資料中 LMCache 沒有確認。
  • 沒有資料說明這個漏洞在揭露前後、未修補期間是否曾被利用。

可引用的一句話

它在還沒問「你是誰」之前,就先照著陌生人寄來的說明書把東西組裝起來了。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。 完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《LMCache 多程序模式 ZMQ 傳輸的 pickle 反序列化:不需認證就能遠端執行程式碼,修補已進 dev 分支、尚無正式版》。PlainCVE。https://plaincve.date/vulns/cve-2026-105192-lmcache-zmq-pickle-rce(查閱日期:YYYY-MM-DD)
BibTeX
@misc{cve2026105192lmcachezmqpicklerce2026,
  title  = {LMCache 多程序模式 ZMQ 傳輸的 pickle 反序列化:不需認證就能遠端執行程式碼,修補已進 dev 分支、尚無正式版},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-105192-lmcache-zmq-pickle-rce},
  note   = {更新於 2026-10-12}
}