大模型的“记忆”，正在裸奔

一个9.8分的严重漏洞，没有补丁，还有公开的攻击代码——这三个条件叠加在一起，通常意味着一轮真实的入侵浪潮。

这一次的主角不是某个老牌Web框架，而是AI基础设施里的一块“新地基”：开源缓存中间件LMCache。2026年10月7日，JFrog安全研究团队发布了安全公告和概念验证（PoC）代码，明确指出该漏洞“没有可用的修复版本”。

换句话说，武器是公开的，门是开着的，锁还在工厂里。

“📌 可验证信息速览

>

“| 项目 | 内容 | 来源 |

“|---|---|---|

“| 漏洞编号 | CVE-2026-105192 | JFrog公告 / NVD |

“| CVSS 3.1评分 | 9.8（Critical） | JFrog公告 / NVD |

“| CVSS 向量 | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | NVD |

“| 漏洞类型 | CWE-502：不可信数据反序列化（pickle） | JFrog公告 |

“| 受影响组件 | LMCache（多进程/分布式部署的缓存传输接口） | JFrog公告 |

“| 受影响版本 | 截至披露日的全部已发布版本——由于官方明确"no fixed release"，即不存在任何已修复的版本线 | JFrog公告 |

“| 补丁状态 | 无修复版本（no fixed release） | JFrog公告 |

“| PoC状态 | 已随公告公开 | JFrog公告 |

>

“原始通告与权威条目（请以此为准进行核实）：

>

“- JFrog安全研究公告（2026-10-07发布，含PoC）：https://research.jfrog.com/vulnerabilities/（CVE-2026-105192条目）

“- NVD条目：https://nvd.nist.gov/vuln/detail/CVE-2026-105192

“- 上游仓库（跟踪修复release）：https://github.com/LMCache/LMCache

>

“注：由于不存在修复版本，“受影响版本范围”的准确表述是——披露时点的每一个可下载版本都不安全，而非“某个版本线以下受影响”。这一点直接影响后续的资产盘点逻辑：不能按“升级到某个安全版本”做应急，只能按“暴露面处置”做应急。

🔥 一个躺在“记忆”里的RCE

最危险的地方，往往是最没人看的地方。

先讲场景。现在主流的LLM推理部署越来越讲究“多进程”“多实例共享”——多个推理进程之间要共享KV缓存，省算力、省显存、提升吞吐。LMCache干的就是这件事：把模型的“记忆”抽出来，在不同进程、不同实例之间搬运和复用。

问题恰恰出在“搬运”环节。根据JFrog公告，攻击路径是Python生态臭名昭著的pickle反序列化：LMCache在处理缓存数据时使用了不安全的pickle反序列化，而相关传输接口又没有身份认证。这意味着，只要攻击者能通过网络触达一个多进程部署的LMCache实例，就可以未经认证投递恶意序列化数据，直接在服务器上执行任意代码。

复现条件（依据公告与PoC归纳）：

1. 目标运行LMCache的多进程/分布式模式，缓存传输接口处于监听状态；

2. 该接口对攻击者网络可达（公告明确默认配置下接口无身份认证）；

3. 攻击者向该接口投递构造好的恶意pickle载荷；

4. 服务端反序列化即触发，无需任何用户交互或有效凭据。

对应CVSS向量的三个关键位也印证了这一点：AV:N（网络可达）、AC:L（低攻击复杂度）、PR:N（无需权限）——即“一张网卡、一个载荷、零凭据”。

整条攻击链短得惊人：

这是一条教科书级别的反序列化RCE。对比一下：当年的Java反序列化、Fastjson、Log4Shell，走的都是同一条路——一个通用组件的可信边界被高估了，攻击者从“数据通道”直接打进“执行通道”。

产业层面的判断是：缓存、序列化、进程间通信这类底层件，天然处于安全架构的盲区。它们不属于“业务面”，很少被划进攻击面管理清单，但它们恰恰是“数据换代码”的最高危通道。AI基础设施正在大规模重建这一层，而旧的安全经验还没有跟上。

⚠️ 无补丁 + 公开PoC：最坏的组合

披露的意义在于修，而不是晒。

时间线非常短，也非常刺眼，且每一步都可由上表中的原始通告核实：

• 2026年10月7日：JFrog发布CVE-2026-105192安全公告，CVSS 9.8，同时附上公开PoC利用代码
• 同日：公告明确说明——没有可用的修复版本（no fixed release）
• 截至本文发稿：上游仓库仍无可标记为安全修复的release，漏洞处于“武器已公开、补丁未出现”的空窗状态

这个状态在漏洞管理里有个俗称：“零补丁期”。它比0day更尴尬——0day是大家不知道，这个是大家都知道、攻击者拿到现成弹药、而防御者手里没有任何可以部署的修复。

需要明确的是：“AI组件漏洞披露早于修复”是否已成为趋势，目前没有公开的统计数据支持——这是作者基于观察做出的推测，而非可引用的结论。但有一件事是可验证的：本文写作时，CVE-2026-105192确实处于无补丁状态，且这一点是JFrog在原始公告中白纸黑字写明的。仅此一条，就足以支撑下文的全部应急建议。

从产业逻辑看，这里有两层结构性问题：

第一，披露流程与开源维护节奏错配。JFrog作为安全厂商按披露流程放出了通告和PoC，但修复权在开源维护者手里。AI领域的开源项目迭代极快、维护人手分散，一个9.8分的漏洞可能在issue列表里排很久。

第二，“公开PoC”在这个生态里的杀伤力被放大了。传统企业软件漏洞公开后，攻击者还需要逆向适配环境；而AI基础设施部署高度同质化——同样的Docker镜像、同样的默认配置、同样的云上端口暴露模式——PoC的复用成本几乎为零。

对防守方来说，结论很直白：在补丁出现之前，这个漏洞只能靠“环境手段”硬扛，不能等。

🧩 AI中间件正在复制上一代软件的病

历史不会重复，但押韵押得很准。

把镜头拉远一点看。过去二十年，企业软件安全走了一条完整的曲线：先是“功能优先”，中间件满天飞；然后漏洞集中爆发，补丁疲于奔命；最后才长出SDL、依赖扫描、SBOM这一整套工程化防御。

今天的AI基础设施，正在原样重播这条曲线的前半段。LMCache这样的缓存组件，本质上是AI推理栈里的“Redis时刻”——它承担关键数据通道职能，被大量部署，但工程成熟度还没跟上它的位置。

如果按“工程成熟度”和“攻击面价值”给当前AI栈里的组件画一张定位图，格局会很清晰：

左上角那一象限——“工程成熟度低、攻击面价值高”——就是本轮风险的集中地。LMCache这类缓存中间件和推理网关都挤在这里：它们离模型和敏感数据最近，网络可达性最强，但鉴权、输入校验、安全默认配置这些基本功，普遍还在“能跑就行”的阶段。

而水面之下的问题更深。一次漏洞披露暴露的只是冰山一角：

一个可供参考的推测（注意：是推测，不是数据）：AI栈的安全水位，可能落后于它的部署速度若干年。这个判断无法精确量化，但它有一个可检验的方向——部署在狂奔，安全在走路。读者可以用自己组织的资产清单来验证它：如果安全团队叫不出你们AI推理栈里中间件组件的名字，这个推测在你们那里就已经被证实了。

🛡️ 补丁没有之前，企业能做什么

等补丁是策略，但只能是一个很短的策略。

回到实战。面对一个“无补丁、有PoC、CVSS 9.8”的RCE，应急响应的优先级清单其实相当标准，难在执行：

1. 资产盘点先行。先回答“我们有没有用LMCache、是什么版本（按上文速览表：无论哪个版本都在受影响范围内）、部署在哪、是否多进程模式、传输接口是否网络可达”。AI组件经常被算法团队“影子部署”，安全团队看不见的实例才是最危险的。注意：因为不存在安全版本，盘点的目的不是“找出旧版本升级”，而是“找出所有暴露实例做暴露面处置”。

2. 切断网络可达性。漏洞前提是“攻击者可触达的部署”（对应CVSS向量中的AV:N）。缓存层本应只对内网推理进程开放，立刻收紧防火墙规则、绑定回环或内网地址、杜绝公网暴露。只要把AV:N改成不可达，这条9.8分的链路就在你自己的网络边界上被拆掉了。

3. 限制执行环境。即便被打了，容器隔离、非root运行、最小权限、出口流量管控，可以把RCE降级为“受限入侵”，大幅抬高攻击者的横向成本。

4. 监控与狩猎。反序列化RCE落地后必然有进程异常、异常外联。围绕LMCache进程建立基线告警，主动做一轮威胁狩猎。鉴于PoC已公开，可结合公告中的PoC行为特征（对缓存传输接口的异常请求模式）做针对性检测。

5. 持续跟进修复。盯紧上游仓库的release（https://github.com/LMCache/LMCache）与NVD条目的更新，补丁一旦发布，进入补丁验证和灰度升级通道。在补丁落地前，该漏洞应按“持续存在的9.8分RCE”登记风险，而不是按一次性事件归档。

这五条没有一条是“AI专属”的新技术，全是二十年应急响应的老功夫。这恰恰说明了一个产业判断：AI基础设施的安全问题，大部分不是新问题，而是老问题在新位置上重新排队。 企业不需要发明新方法论，需要的是把存量能力覆盖到新资产上——而这一步，大多数组织还没走。

小结

CVE-2026-105192的真正价值，不在它9.8的评分，而在它标记了一个节点：AI基础设施的“Redis时刻”到了，缓存、网关、序列化这些沉默的中间件，正式进入攻击者的主菜单。

LMCache的补丁还没来，但企业的盘点、隔离、降权、监控现在就能做。等到下一轮“9.8分 + 无补丁 + 公开PoC”的组合再次出现——它一定会再出现——希望我们已经把水面之下的安全债，还掉了一部分。

参考资料（均为可公开核实的一手来源）：

1. JFrog安全研究团队，CVE-2026-105192安全公告及PoC（2026-10-07）：https://research.jfrog.com/vulnerabilities/

2. NVD漏洞条目：https://nvd.nist.gov/vuln/detail/CVE-2026-105192

3. LMCache上游代码仓库及Release页：https://github.com/LMCache/LMCache

编者注：本文中所有关于趋势、水位、“圈内讨论”的判断，除明确标注为推测者外，均可在上述一手来源中核实；无法核实的内容已删除或改写为作者观点。建议读者在采取行动前，以JFrog原始公告和NVD条目的最新状态为准。