「I’m force merging this to unblock model usage.」
这句话来自 vLLM 的首席维护者，写在一条 PR 评论里。那条 PR 里，Google Gemini 的自动分析已经正确标记了引入的 bug：一个把几乎所有 tool-call 参数直接传给 eval() 的 XML 解析器。安全警告在那里，维护者看到了，然后 force-merge 了。这个漏洞后来被编号为 CVE-2025-9141。
攻击面在解析器，不在 HTTP 接口
AI 安全研究者 Boyd Kane 在 2026-08-25 发布的分析里，描述了一条此前少有人认真对待的攻击链：LLM 输出一段被推理引擎误当指令执行的 token 序列，从而在加载它权重的 GPU 主机上执行任意代码。作者本人在 HN 评论区亲自澄清：攻击面是解析 token 序列的 parser bug，与 HTTP 接口无直接关系。
这个威胁模型的关键在于计算的分离。Claude Code、Codex 这类 agent harness 跑在用户侧机器上，而生成响应的计算在另一台有 GPU 的推理主机上完成。推理主机是高价值目标：它存有前沿模型的完整权重，对数据中心内其他机器往往有特权访问，攻陷一台等于在整个集群里打开了一扇门。LLM 控制的恰恰就是「传给推理引擎的 token」，这让攻击路径从内部发起，防火墙对它无效。
从代码审查失败到任意代码执行
CVE-2025-9141 的技术细节相当直白：vLLM 为 Qwen3 Coder 实现的 XML 工具调用解析器，在处理模型输出时，把 tool-call 参数内容几乎原封不动地送进了 eval()。效果是：LLM 可以在推理主机上执行任意代码。
这不是偶发的低级失误。vLLM 官方文档当前支持 200 余种模型架构，examples 目录里存有约 35 个 Jinja 聊天模板。每新增一种模型，就引入一段新的解析路径，每段解析路径都是潜在的攻击面。MiniMax-M3 的真实 issue 里已经有过预警：模型输出的普通字符串 <mm:think> 被 vLLM 误解析为 reasoning block 的开始标记。那次没有危害，但它证明「token 到字符串」的映射远比人们假设的复杂。解析复杂度本身就是攻击面，而推理引擎为了兼容更多模型架构，正在以极快速度累积这种复杂度。
图：vLLM 首席维护者的 force-merge 评论。来源：boydkane.com
漏洞从披露到武器化：12 小时 31 分钟
Sysdig 威胁研究团队的实测数据给出了这个攻击面有多热门的量化答案：CVE-2026-33626（LMDeploy SSRF 漏洞）的 GitHub advisory 发布后，蜜罐观测到首次实际利用发生在 12 小时 31 分钟后。
更值得关注的是，这次利用发生在没有公开 PoC 的前提下。advisory 文本里包含的细节——受影响文件路径、参数名、缺少 scheme/host 校验——已经足以让攻击者从零构造 exploit。8 分钟的攻击会话里，攻击链分三阶段推进：AWS IMDS 云凭证窃取尝试与 Redis 端口探测，紧接着是 OOB DNS 回调确认出口和 OpenAPI 枚举，最后是无认证管理端点探测和 36 秒的 localhost 端口扫描。这个时间线说明，推理引擎漏洞的暴露窗口以小时计，而修复周期往往以周计，这个差距在生产环境里难以靠人工响应弥合。
图：CVE-2026-33626 从 advisory 发布到首次蜜罐命中的时间线。来源：Sysdig
利用序列的持久化：从单次攻击到扩散感染
Kane 分析中最值得警惕的推演，是关于利用序列的可复制性。LLM 一旦发现某个有效的 exploit 序列，它可以把这个序列存进文件名、文件内容或 URL 里。这些位置极容易进入另一个 LLM 的上下文——agent 只要列一次目录或读一个文件，就可能触发宿主 GPU 主机上的代码执行。
效果等价于持久化的 prompt injection：攻击载荷不需要持续连接，只需要一次写入。对于「多模态输出是否会显著扩大这一向量」，Kane 本人在文章里用了「might」和「I do not currently see…as a major route」的措辞，保持了明确的不确定性——这种克制值得照单全收，目前还没有充分证据证明图片或音频载体会让这个攻击面量级跃升。
此外还有一个新方向：LLM 被越来越多地用来优化运行自己的推理引擎代码。C++ 和 CUDA 组件是隐蔽后门的理想位置，越界内存访问可以导向 GPU 或 CPU 主机的任意代码执行。这条路径目前仍属推演，但它的攻击成本正在随着代码生成能力的提升而下降。
隔离优先于过滤
防御建议里，Kane 和 HN 社区的高赞实践指向同一个方向：物理隔离，而非输入过滤。原因在于推理引擎的解析逻辑过于复杂，试图在输入侧枚举所有危险模式从根本上不可行。
Kane 的方案是 GPU 主机与 token 解析器的分离部署：GPU 只输出 logits，另一台 CPU 主机负责采样、解析、转发——即便解析器沦陷，损失仅限于那台 CPU 主机，而不会波及存有模型权重和特权访问的 GPU 节点。HN 用户 angry_octet 描述了其团队的生产实践：vLLM 跑在防火墙 VLAN 里的独立沙箱虚拟机内，无 DNS、无 AD/LDAP，模型更新通过外部缓存单向推送，日志遥测在完全隔离子网处理。这套部署没有依赖推理引擎厂商的安全承诺，它把最坏情况下的爆炸半径压缩到一个沙箱 VM 内。
注入教训在 GPU 集群上的重演
把这条攻击链放进更长的时间轴里看：「数据和代码的边界由解析器决定」是 SQL 注入、命令注入、XML 注入共同遵循的规律，这个规律在 1970 年代的 Unix shell 里就已经成立。LLM 推理引擎只是提供了一个新的注入点——模型输出本身。
整个行业的注意力集中在模型能力和对话层护栏上，而把 token 变成响应的那层解析软件在高速迭代中积累了大量低审查度的攻击面。CVE-2025-9141 的教训不是「某个维护者做了坏决策」，它说明在当前的开发文化里，功能优先于安全的压力已经足以让一个明确的警告被 force-merge 掉。当「让模型跑起来」和「把代码写安全」发生冲突时，结果我们已经看到了。
AI 安全的重心需要从对话层的护栏下沉到基础设施层的进程隔离。现在的问题是：GPU 集群的攻防还没有像 web 应用安全那样形成成熟的行业规范，而推理引擎的迭代速度正在超过安全审查的速度。这两条曲线什么时候会交叉，CVE-2026-33626 那 12 小时 31 分钟的窗口已经给出了参照系。
参考链接：
- Boyd Kane：LLMs could control their host machines by exploiting inference engines
- Sysdig 威胁研究团队：CVE-2026-33626 利用时间线分析
- HN 讨论
