根因与利用链。漏洞位于 LMCache 的 multiprocess（多进程）模式：该模式下缓存作为独立服务运行，各 LLM worker 通过 ZeroMQ 套接字连接它、注册并共享 KV cache 块。这个 socket 没有任何认证（无 CURVE、无 ZAP、无逐消息认证）；服务端在读取消息参数的阶段就用 Python 原生 pickle 对载荷反序列化，在任何"消息类型校验"之前就已触发执行。消息用 msgpack 编码，扩展码 1 注册给了 DeviceIPCWrapper，解码器一遇到该扩展码就对 payload 调 pickle.loads——因此一条精心构造的网络报文即可在 LMCache 进程权限下执行任意代码。
放大器：官方提供的容器镜像里，该进程默认以 root 运行——容器化部署一旦被打穿，攻击者直接拿到容器内 root；而 GPU 推理主机上通常放着模型权重、API Key 与云凭据。
是否暴露只取决于一个设置。JFrog 与 NVD 均指出，multiprocess 服务的默认绑定是 localhost:5555；只有当运维用 --host 传了可路由地址（JFrog 称这正是"文档化的多节点部署方式"）时，该缺陷才变为网络可达。因此 9.8 分对应对可路由配置；只在本机跑默认绑定的单机安装不被远端触达。但 LMCache 官方示例 K8s DaemonSet 默认监听所有网卡——很多团队为先把推理跑起来直接照抄该示例。
无补丁下的处置（JFrog 建议）：不要把 multiprocess 服务绑定到可路由地址，把端口留在本机或可信集群网络内；防火墙限制谁能连到该端口可降低但不能消除风险（任何仍能连上的主机都能执行代码）；官方容器降权运行，不要用 root。长期修复方向（给维护者）：停止把网络数据喂给 pickle、换成安全序列化格式、给 ZeroMQ 传输加上认证（如 CURVE 或逐消息 HMAC），并要求未配置认证时拒绝绑定可路由地址。
关联项：vLLM 侧 CVE-2026-105756（6.5） 是另一枚相关缺陷——在 0.30.0（9-22 发布）之前，使用 LMCache multiprocess 连接器的部署收到畸形 cache_salt 值的单条请求即可让引擎核心抛未捕获异常，造成 DoS。vLLM 已修复；LMCache 的 pickle 问题仍无补丁。
为何值得关注：
- "内部协调 socket + pickle + 默认信任网络"是 AI 推理栈的系统性病灶：2025-11 研究者把这族缺陷命名为 ShadowMQ，此后 LightLLM 的 config server（同为 pickle）、AutoAgent 的未认证 TCP socket、Langflow 的 MCP handler 接连中招——约七周内第 3 个开源 LLM/AI 工具链的未认证 RCE
- 代价最大的位置：LMCache 卡在推理服务器与 KV cache 之间，对支撑活跃推理任务的缓存状态有写权限，影响远超缓存服务本身
- 无补丁 + 无检测手段：JFrog 的公告没有给运维"是否已被攻击"的判别方法，缓解完全落在操作者手上