开源大模型缓存组件 LMCache 被披露存在未认证远程代码执行漏洞，编号 CVE-2026-105192，CVSS 评分 9.8，截至披露时官方没有任何修复版本。LMCache 是当前主流的 LLM 推理加速层，常与 vLLM 搭配使用，通过共享 KV 缓存避免重复计算；一旦多进程模式的缓存服务被暴露到可路由网段，攻击者只需发送一条特制消息即可在缓存服务器上执行代码，而该进程在官方容器镜像中以 root 身份运行。
事件概述
该漏洞由 JFrog 安全研究员 Yuval Moravchick 发现并于 2026 年 10 月 7 日公开。同日发布的还有第二个编号 CVE-2026-107204，指向另一条完全不同的未认证代码执行路径——LMCache 0.5.5 及之前版本接受对 /run_script 端点的未认证 POST 请求并直接执行提交的 Python 代码，CVSS 3.1 评分同为 9.8，CVSS 4.0 为 9.3，归类为缺失认证（CWE-306）。此外，10 月 6 日还有一个 GitHub 账号一次性提交了六份 LMCache 安全报告，声称存在跨租户缓存数据读取与未认证命令执行，但这些报告既没有 CVE 编号，也未获维护者确认。
技术细节
CVE-2026-105192 的根因在 LMCache 的多进程模式。该模式下缓存作为独立服务运行，LLM 工作进程通过 ZeroMQ 套接字与之通信，而这条套接字没有任何认证机制。其中一类消息在解码时使用 Python 的 pickle 格式，pickle 本身可以携带可执行代码；问题在于服务端在读取参数阶段就完成了反序列化，此时尚未校验消息类型，因此构造的消息在类型判断之前就被执行。攻击者无需登录，只要网络可达即可触发。
受影响范围为 0.3.9（2025 年 10 月发布）至 0.5.5 的全部版本，0.5.6 的候选版本和开发分支同样受影响。CVE-2026-107204 则是另一个问题：它不是 pickle 反序列化，而是一个直接执行提交脚本的 HTTP 端点，攻击者可借助暴露的 FastAPI 应用对象恢复 Python 内置函数、绕过受管导入限制并调用 os 模块执行系统命令。
影响评估
CVE-2026-105192 的 9.8 分是在缓存服务器网络可达的前提下给出的。默认配置下多进程服务只监听本机，但如果运维人员为跨节点共享缓存而将其绑定到可路由地址——LMCache 官方的 Kubernetes 示例部署就把服务监听了所有网卡——端口就会暴露。由于代码以 root 权限执行，成功利用等于缓存服务器完全失陷；而推理服务器往往还能触达提示词、输出结果乃至其他服务的 API 密钥，横向移动价值不低。目前没有公开的检测手段可判断是否已被入侵。
修复建议
- 不要把 LMCache 多进程服务绑定到可路由地址，保持仅监听 localhost 或仅供可信主机加入的集群内网；防火墙只能缩小暴露面，不能堵住漏洞本身。
- 排查
/run_script端点是否对外可达，非必要直接关闭或前置认证网关。 - 审计 vLLM 部署的容器构建来源，确认是否使用了官方镜像的默认 root 运行模式。
- 关注维护者是否发布修复版本以及 CISA 是否发布公告，在补丁落地前以网络隔离作为唯一有效缓解手段。