PoC 公开了，9.8 分漏洞还没补

10 月 7 日，JFrog 发布安全公告，并附上可直接使用的 PoC。被点名的，是 LMCache——一个在大模型推理场景里越来越常见的缓存组件。漏洞编号 CVE-2026-105192，CVSS 9.8，未认证远程代码执行。比漏洞本身更扎眼的，是公告里的那句话：目前没有可用的修复版本。

PoC 已经躺在公开渠道里，补丁却还没影。对任何跑着 AI 推理业务的团队来说，这都不是一个可以慢慢消化的议题。

⚠️ PoC 先到，补丁未到

先看事实。安全圈最怕的不是高危漏洞，而是「高危 + 无补丁 + 公开利用代码」三件事同时发生。这一次，三件事全齐了。

2026 年 10 月 7 日，JFrog 发布安全公告，同步公开了漏洞编号 CVE-2026-105192 和可用的概念验证代码。漏洞存在于 LMCache 中，允许未认证攻击者对可达的多进程部署执行任意代码，根因是不安全的 Python pickle 反序列化，CVSS 评分 9.8，落在 Critical 区间的顶端。公告明确指出：截至披露时，没有可用的修复版本发布。

• 10 月 7 日：JFrog 发布安全公告，附公开 PoC
• 同日：官方确认无可用修复版本
• 此后：处于「PoC 公开、补丁缺位」的暴露窗口期

注意措辞里的一个关键限定：multi-process deployments（多进程部署）。这不是说所有部署形态都中招，而是攻击者需要能触达特定的多进程部署面。换句话说，暴露面积取决于你的架构——但一旦可达，后果就是满级 RCE。

从攻击链视角看，整条路径并不复杂：

没有认证绕过，没有复杂的堆喷射，攻击门槛低到只需要一份公开的 PoC 和一台能连上目标的机器。这也是 9.8 分的分量所在：利用复杂度低、影响范围大。

🔬 pickle：Python 生态三十年没拆掉的雷

老坑，但永远是新坑。

pickle 是 Python 标准库里的序列化机制，设计初衷是方便地保存和恢复对象。问题在于，反序列化一段 pickle 数据，本质上是在执行数据里内嵌的对象重建逻辑——如果这段数据可以被攻击者控制，重建过程就等于执行任意代码。这不是新发现，Python 官方文档里白纸黑字写着：不要对不受信任来源的数据使用 pickle。

传统 Python Web 生态为此踩过十几年的坑，社区形成了基本共识：面向外部的数据交换用 JSON，pickle 只用于可信内部通道。但 AI 栈把这套共识冲淡了。

原因很现实：模型张量、KV 缓存这类大块头数据，用 pickle 序列化的性能远好于 JSON，加上 AI 新组件的开发节奏快、数据面大，pickle 在「性能理由」下被大量沿用。安全问题就这样在性能优化的掩护下重新上岸。

一位做 AI 基建安全评估的同行的说法很有代表性：审 AI 项目代码，先搜 pickle.load，命中率比十年前审 Python 网站还高。

产业层面的判断是：AI 组件正在把上一代 Web 时代的安全教训原样重踩一遍。框架新、代码新、团队新，但漏洞模式全是旧的——反序列化、未授权访问、内网默认可信。技术栈在换代，攻击面逻辑没有换代。

🧠 为什么偏偏是缓存层

看位置，不看名字。

LMCache 的定位是大模型推理场景中的缓存管理层，公开资料显示它常与主流推理引擎搭配使用，用来在多实例之间共享 KV 缓存、提升推理效率。也就是说，它 sits 在推理集群的咽喉位置——所有需要缓存共享的进程，都要跟它打交道。

这带来两个安全上的结构性问题。

第一，缓存层通常部署在内网推理集群里，被默认划入「可信区域」。安全团队会把 WAF、认证、限流都堆在 API 网关上，但推理集群内部的东西向流量往往没有像样的隔离。一旦攻击者能触达缓存服务端口——无论是通过暴露的调度接口、配置失误，还是先攻陷了集群内一台节点——认证缺位的反序列化漏洞就是敞开的大门。

第二，多进程部署意味着一条共享数据通路被打通。打下一个进程，缓存里流转的数据通路就可能成为横向移动的通道，影响范围从单实例放大到整个推理集群。这是把「触发条件」限定在 multi-process deployments 的原因，也是它真正危险的原因。

熟悉的面孔是 Redis 和 Memcached。当年这两类组件的未授权访问 RCE，吃掉了一整代疏于内网隔离的互联网公司。AI 推理基础设施正在重演同一剧本：组件出现在架构深处，默认可信，暴露面靠运维自觉来兜底。

📉 「没有修复版本」暴露的开源安全真空

披露即武器化，这不是修辞。

传统漏洞处理流程里，厂商和研究者之间有个默契：协调披露，给用户留出打补丁的时间窗。但这一次的时序是——公告、PoC、无补丁状态在同一天成立。从 10 月 7 日起，所有可达的部署都处在一个理论上「任何人都可以打、防御者却无补丁可打」的窗口里。这个窗口会持续多久，取决于上游的修复节奏，而这恰恰是开源 AI 组件最不确定的部分。

把行业里常见的几类基础设施放在同一坐标系下看，问题会更清楚：

左上角就是这次的处境：业务暴露度高，安全维护成熟度低。AI 新组件往往由小团队或研究项目维护，社区热度和工程成熟度不对等——GitHub 上星标几千，安全响应流程可能只有一个人兼着。企业侧却已经把这些组件接进了生产链路，当业务关键系统在用。

据多位接近开源供应链审计的人士观察，过去一年企业 AI 栈的依赖清单膨胀速度，远超安全团队建立 SBOM 和漏洞响应流程的速度。选型时看性能基准、看社区活跃度，很少有人把「漏洞披露后的修复响应能力」当成评估项。这次的「无修复版本」就是学费。

判断是：未来一段时间，「AI 组件高危无补丁」不会是孤例，而是常态化的风险类别。对使用方而言，与其等上游长大，不如在选型和部署阶段就把安全成熟度当硬指标。

🛡️ 补丁没来之前，能做什么

应急的价值在于快，不在于全。

无补丁期的防御没有银弹，但有几件事是确定性高的。首先是资产盘点——应急响应的第一课永远是：你得先知道自己有没有在用。很多团队对推理集群的依赖清单并不完整，等漏洞爆出来才去翻 requirements 文件。

其次是压缩暴露面。漏洞触发条件是「攻击者可达的多进程部署」，可达性是防御者唯一能直接控制的变量。缓存服务的访问来源应收窄到推理集群内部，不该有任何公网或跨信任域的直连。

再次是检测补偿。既然反序列化行为没有原生的输入校验，可以在网关和流量侧做特征监测，对异常的序列化载荷告警，把「发现被打了」的时间从几天压到几分钟。

最后是跟踪与预案。持续关注 JFrog 和上游项目的公告，等修复版本发布后第一时间安排升级；同时准备好降级或替换方案——如果一个组件的不可替代性高到出了 9.8 分漏洞也没法摘掉，这本身就是架构风险。

一线应急圈里流传一句话：漏洞是别人的，暴露面是自己的。补丁什么时候来不由你决定，但攻击者能不能够到你的缓存端口，完全由你决定。

小结

CVE-2026-105192 是一个技术上并不新鲜的漏洞——pickle 反序列化 RCE，社区讨论了十几年。它真正的信号在于时序：CVSS 9.8、PoC 公开、无修复版本同时成立，而受影响的又是 AI 推理基础设施的关键位置。这说明 AI 开源组件的安全维护体系，已经明显落后于它的生产采用速度。对企业而言，眼下是盘点、隔离、加监测；对产业而言，把维护响应能力纳入组件选型的硬指标，是这次事件应该留下的制度记忆。无补丁窗口不会是最后一次，下一个爆雷的，大概率还是左上角那个象限里的新成员。