大模型没塌，中间件先塌了

模型再强，也可能死在一行 pickle 上。

2026 年 10 月 7 日，JFrog 发布安全公告，同时放出了公开 PoC：LMCache 存在一个 CVSS 9.8 分的未认证远程代码执行漏洞（CVE-2026-105192），根因是不安全的 Python pickle 反序列化，且——官方彼时没有可用修复版本。几乎同一时间窗口，AWS 为其 AI Agent 编排平台 Loom 连发三个漏洞的修复，涉及未认证管理员接管、OAuth2 凭据泄露和内网服务访问，紧急版本号 1.7.0。

两个事件叠加，指向同一个判断：AI 安全当前最大的暴露面，既不是模型本身，也不是花哨的提示词攻击，而是缓存、编排这些没人盯着的中间层。攻击者已经明白这一点了。

🧨 两个漏洞，同一个位置

先把两件事放在一起看。

LMCache 是大模型推理侧的 KV 缓存中间件，常见于多进程部署的推理集群，作用是复用计算结果、降低推理延迟。JFrog 研究人员发现：任何能触达部署端口的攻击者，无需任何认证，就可以通过构造的 pickle 数据触发任意代码执行——CVSS 9.8，满分级别的严重性。更棘手的是，公告发布当天没有修复版本可用，PoC 已公开。这意味着从披露到补丁之间存在一段「人人都能打、无解可修」的裸奔期。

AWS 的 Loom 则是另一类角色的代表：AI Agent 编排平台。三个漏洞组合起来威力不小——未认证的管理员接管、OAuth2 凭据泄露、访问内部服务。AWS 的处置态度算是负责任的：发布安全公告，强烈要求升级所有部署版本和 fork 分支到 1.7.0。

产业逻辑很清晰：AI 技术栈的安全投入严重倾斜于「离模型最近」和「离用户最近」的两端，中间的缓存层、编排层成了真空地带。而恰恰是这两层，握着模型权重、会话数据、Agent 凭据这些最值钱的东西。

⚙️ pickle，一个二十年的老毛病

安全圈流传一句老话：pickle 不是数据格式，是代码格式。

Python 的 pickle 在反序列化时会执行内嵌的字节码，这意味着「加载数据」和「执行代码」在 pickle 这里是同一件事。Python 官方文档多年来的措辞是「永远不要反序列化不受信任来源的数据」——不是警告，是禁令。但 LMCache 恰恰在最高危的位置用了它：一个默认面向内网、常被直接暴露或配置宽松的缓存端口，收到什么就反序列化什么。

为什么 AI 新栈还在犯二十年前的老错？三个原因。

第一，性能优先的文化。推理中间件的一切设计都围绕延迟展开，pickle 序列化张量数据快、省事、和 PyTorch 生态天然兼容，安全审查在性能对比面前往往一票否决都不用投。

第二，默认信任内网。缓存层的开发者默认「只有自己集群的东西会连上来」，认证和输入校验因此被视作可选件。但现实是，K8s 环境里一次横向移动、一个 SSRF、一个配置失误，内网边界就形同虚设。

第三，责任链条断裂。开源中间件通常是某个大项目（比如推理框架生态）的附属品，维护者精力有限，安全响应没有 SLA。无修复版本加公开 PoC 的组合，本质上是把风险单方面转移给了所有部署方。

从攻击链视角看，这个漏洞几乎是教科书式的低成本高回报：

一句话总结：在 AI 基础设施里，性能优化点的反面往往就是安全沦陷点。pickle 只是最近的一次显形，不是最后一次。

🤖 编排层正在变成新的域控

如果说 LMCache 是老毛病的新病灶，Loom 漏洞揭示的则是更结构性的问题：Agent 编排层正在成为企业里新的「域控」。

道理不难理解。一个 AI Agent 要干活，就得有身份：访问数据库的凭据、调用内部 API 的令牌、读文档的权限、发邮件的账号。编排平台把这些身份集中管理、统一调度——这正是当年 Windows 域控的角色。而 Loom 的三个漏洞恰好打在这条脊柱的三个关节上：未认证管理员接管（拿到控制面）、OAuth2 凭据泄露（拿到所有 Agent 的身份）、访问内部服务（拿到横向移动的起点）。

三点成线，等于一次入侵同时完成「夺权、偷钥匙、开门」。

值得注意的还有 AWS 公告里的一个细节：要求升级「所有部署和 fork 分支」。这个措辞很诚实，也很残酷——开源编排平台被大量公司二次开发后内部使用，这些 fork 往往没有跟随上游升级的机制，漏洞修复对它们来说是永远到不了站的末班车。据多位做过企业 Agent 项目落地的同行反馈，不少公司连自己环境里跑的是哪个版本的编排组件都说不清，更别说追踪 fork 的血缘。

产业判断是：随着 Agent 从演示走向生产，编排平台的攻击价值会超过很多传统核心系统。安全团队过去管「人的权限」，现在还得管「AI 的权限」，而后者数量更多、变化更快、几乎没有成熟的审计体系。身份与访问管理（IAM）的下一个主战场，大概率就在这里。

📊 谁来填这个坑：安全责任的四象限

漏洞摆在那，问题是：谁负责修，谁负责防？

现状是一条断裂的责任链。开源中间件维护者——比如 LMCache 背后的社区——有意愿但缺资源和流程，漏洞披露时连修复版本都拿不出来；下游商业发行版和云厂商，倾向于等上游、观望事态；企业用户则默认「用了开源就该自己兜底」，却大多没有对应的工程能力。PoC 公开到补丁落地之间的这段真空期，就是产业里最贵的窗口。

把生态里的各方放到一个坐标系里看，谁在真正解决问题，一目了然：

云厂商安全团队目前站在领跑者象限：有工程能力、有资产可见性、有直接的商业动机（客户被打了云厂商也疼）。Agent 编排平台厂商紧随其后——AWS 这次为 Loom 出公告、催升级，本质是把安全当成产品责任而不是社区义务，这个姿态值得同行效仿。传统应用安全厂商技术门槛不够，还在用扫描器时代的思路碰运气；开源社区有价值但缺闭环，是典型的潜力股待激活。

我认为接下来两年会出现的格局是：AI 中间件的安全能力，要么被云厂商以托管服务的形式收编，要么被专门的安全厂商以「AI 栈安全检测」的新品类承接。独立开源中间件继续裸奔的成本，会随着 Agent 大规模落地而指数级上升。

🛡️ 防御清单：现在就能做的五件事

聊完逻辑，回到一线。针对这类 AI 中间件风险，以下是部署了 LMCache、Loom 或同类组件的团队现在就该做的事：

`infographic

{"type":"problemsolution","title":"AI中间件防御对照","items":[{"problem":"LMCache披露时无修复版本且PoC公开","solution":"立即收敛网络暴露面，缓存端口置于认证网关之后，禁止公网可达，多进程部署逐一排查"},{problem":"Agent编排平台持有大量OAuth2凭据","solution":"按最小权限重签凭据，缩短令牌有效期，管理后台强制认证并限制来源"},{problem":"fork分支无人跟随上游修复","solution":"建立开源组件SBOM台账，fork纳入与上游同步的升级机制"},{problem":"pickle反序列化边界不可控","solution":"在不需要pickle的接口禁用该协议，必须使用时限制反序列化入口并隔离运行环境"}]}

`

再补三条经验之谈。其一，缓存层和编排层在多数企业的资产台账里根本不存在——先盘点，否则一切防御无从谈起。其二，对 Loom 这类平台，升级到 1.7.0 只是起点，重点是审计 OAuth2 凭据在漏洞窗口期内有没有被泄露的迹象，必要时全量轮换。其三，把「AI 组件不暴露公网」写成硬性策略，而不是施工建议——这次 LMCache 的 9.8 分 RCE，前提条件只有一个：端口可达。

小结

LMCache 的未修复 RCE 和 Loom 的三个漏洞，是 AI 基础设施安全欠账的两次集中显形：性能文化压倒安全设计，身份资产集中却缺乏治理，开源责任链断裂在关键处。模型层的安全竞赛已经卷起来了，但真正决定一家企业 AI 系统生死的，是缓存怎么配、编排层谁在管、Agent 凭据有没有过期。接下来的看点有两个：一是 AI 中间件安全会不会成为云厂商和创业公司的下一个品类之争，二是 Agent 身份治理会不会催生一套类似当年 AD 安全的标准体系。塌的既然是中间件，修的也必须是中间件——别再等模型替你背锅了。