设备 IPC 反序列化漏洞修复已合并至 dev 分支
2026 年 10 月 7 日，JFrog Security Research 公开披露了 LMCache 多进程（MP）模式中的一个反序列化远程代码执行（RCE）漏洞（CVE-2026-105192，CVSS 3.1 评分 9.8）。我们于 10 月 7 日收到报告，并于当天开始着手修复。修复补丁（PR #5644）已于 10 月 12 日合并至 dev 分支，并将随 0.5.6 版本发布，预计本周推出。
本文将介绍该漏洞及其修复方案、如何保护和排查您的部署，以及后续仍需完成的工作。
1.1. 漏洞说明
该问题存在于多进程（分布式）模式所使用的 ZeroMQ 传输层中。传输端口（默认 5555）未启用身份认证，且在消息解码过程中使用 pickle.loads 对设备 IPC 描述符进行反序列化。攻击者只需发送一条精心构造的消息，即可以 LMCache 进程的权限执行任意代码。
受影响版本： 0.3.9 至 0.5.5、0.5.6 的各候选发布版本（RC），以及修复之前的开发分支。
暴露范围： 默认情况下，传输层仅绑定到 localhost，且单进程/进程内（IP）模式不会开放该端口。当传输层绑定到可路由地址时（多节点部署通常如此），部署即处于暴露状态。
- 有一点会增加许多用户的风险：我们提供的 Kubernetes 部署示例绑定了所有网络接口。如果您的部署基于此，请假定您的部署已暴露。我们已将该示例更新为默认绑定 localhost。
2. 修复方案
本次修复以带版本号、类型化的 MessagePack 描述符取代了 pickle。描述符会先经过校验，随后从本地固定的白名单（allowlist）中选取对应的设备封装类型。类名绝不从网络输入中获取，也不存在回退到 pickle 的路径。ZeroMQ 和 gRPC 两条传输路径均已覆盖，格式错误的描述符将被拒绝。
我们针对多种不同的攻击消息测试了该修复，包括原始 CVE 报告中的那条消息，以及一个试图在主机上执行自定义脚本的极端测试场景。修复前能够成功执行的恶意代码，在修复后均被拦截。正常请求均可正常处理，116 项回归测试全部通过。
请同时升级 worker 和服务端。 由于传输格式（wire format）已发生变化，新旧版本混用将不受支持。
3. 当前应采取的措施
如果您正在使用多进程模式，在 0.5.6 发布之前请采取以下措施：
- 不要将传输层绑定到可路由地址。 请将其限定在 localhost，或仅在受信任的集群网络中使用。
- 限制对传输端口的访问。 通过网络策略或主机防火墙规则，限制对传输端口（默认 5555，或您配置的其他端口）的访问。
- 以非 root 用户身份运行。 官方非 root Docker 镜像将随 0.5.6 一同发布。如需在 0.5.6 发布前使用 Docker 镜像，请使用我们提供的 Dockerfile 自行构建定制镜像。
- 请检查基于我们 Kubernetes 示例的部署。该示例此前绑定了所有网络接口。
4. 入侵排查
如果您的传输端口曾在任何时间点可被不受信任的网络访问，请将该主机视为可能已被入侵。漏洞利用发生在消息处理之前，因此即使日志中显示请求被拒绝或格式错误，也不代表攻击未能得逞。
我们建议：
- 检查来自异常来源的传输端口连接记录。
- 排查 LMCache 进程是否产生了异常的子进程、shell 或出站连接。
- 轮换受影响容器可访问的凭据和密钥，并使用干净的镜像重新部署。
5. 后续工作
本次修复针对的是设备 IPC 描述符的反序列化路径。另有两项相关工作有待完成：
- RPC 传输层身份认证。 目前，LMCache 服务端与 MP 协调器（coordinator）或前端之间的 RPC 通信不要求身份认证。我们计划在 0.5.7 中加入 RPC 身份认证支持。
- 引擎驱动路径中的 pickle 使用。 我们还发现引擎驱动路径（CPU 数据/检索响应处理）中存在 pickle 的使用。该路径默认处于禁用状态，且无法从网络访问。我们计划在 0.5.8 之前移除该处的 pickle 使用。
6. 致谢
感谢 JFrog Security Research 的 Yuval Moravchick 报告此问题并提供详尽的分析。我们欢迎社区通过 GitHub Security Advisories 提交安全报告。
