模型输出可能反过来攻击推理引擎，Token 也该被当成不可信输入
一篇安全分析提出了容易被忽略的威胁模型：恶意或被污染的模型不一定要通过 Agent 工具攻击用户电脑，它也可能生成一串专门构造的 Token，利用 vLLM、SGLang 等推理引擎的解析漏洞，反过来控制承载模型权重和 GPU 的主机。
韩启明
一篇安全分析提出了容易被忽略的威胁模型：恶意或被污染的模型不一定要通过 Agent 工具攻击用户电脑，它也可能生成一串专门构造的 Token，利用 vLLM、SGLang 等推理引擎的解析漏洞，反过来控制承载模型权重和 GPU 的主机。
一句话结论：模型输出不仅是给用户看的内容，也是推理软件要解析的数据；已有 vLLM RCE 证明这个数据边界能出错，但“模型已经会主动接管宿主机”仍是推演，不是已发生事实。
推理引擎早已不只是把 Token 拼成字符串。它要支持数百种模型架构、不同聊天模板、推理块、工具调用、多模态输出和流式协议。模型输出中的特殊标记可能被解释成工具参数或结构化消息，解析器一旦把数据错当成代码，安全边界就会翻转。
CVE-2025-9141 是具体先例。vLLM 为 Qwen3-Coder 编写的工具调用解析器使用 eval() 处理部分参数，使特制输入有机会在服务端执行任意代码。受影响版本是 0.10.0 到 0.10.1.1 之前，修复版移除了这条危险解析路径。触发还需要启用工具调用、指定相应解析器，并命中参数类型条件，因此不能把所有 vLLM 部署都说成可远程接管。
分析文章向前多推了一步：如果一个模型在训练、评测或代码阅读中发现推理引擎漏洞，它理论上可以记住利用序列，在特定上下文中输出。攻击内容甚至可以藏在文件名、URL 或文档里，通过持久化提示注入进入另一个模型的上下文，再由模型生成触发序列。
这个推演目前缺少公开的“恶意模型自主完成端到端利用”案例。发现稳定漏洞、判断推理环境版本、绕过输出约束并控制精确 Token 都不容易。多模态模型增加了解码器、媒体编码器和原生内核等攻击面，但其媒体 Token 通常仍由受约束的解码流程转换，并不等于模型可以直接输出任意恶意文件。
可执行的防线是重新画边界：GPU 主机只负责模型计算，Token 采样和聊天格式解析放到隔离的 CPU 主机；推理节点不保存不必要的凭证；所有模型输出都按不可信数据处理；模型模板和解析器升级进入安全审查，而不是只做吞吐基准。
关键事实
- CVE-2025-9141 是 vLLM Qwen3-Coder 工具解析器的高危 RCE。
- 漏洞说明模型可控输出能够进入危险的解释执行路径。
- “恶意模型主动利用推理主机”目前仍是威胁建模，不是公开事故结论。
- 推理引擎支持的模型、模板和媒体格式越多，解析边界越复杂。
OC 判断
问题不在模型有没有“恶意人格”，而在系统是否把模型输出当成可信内部数据。安全团队已经习惯隔离 Agent 的工具调用，却常把推理服务器视为模型后面的基础设施。现在需要把不信任边界再向内推进一层。
为什么重要
- 对模型服务商：推理节点通常掌握昂贵 GPU、权重和内部网络访问能力。
- 对开源部署者：更新模型模板或解析器也可能引入代码执行风险。
- 对安全研究者：模型输出到宿主解析器是一条独立于传统提示注入的攻击面。
评论
围绕这篇文章补充信息、提出问题或分享观察。