一个恶意大模型能用它生成的token序列，反过来控制驱动它的那台服务器。这不是科幻设定，也不是又一起提示注入越狱。
2026年8月24日，独立研究员Boyd Kane发表了一篇技术文章，系统性地论证了一个让整个AI基础设施界坐不住的问题：LLM推理引擎——也就是将大模型权重加载到GPU上、运行推理、解析输出token的那层基础软件——存在一个结构性的安全缺口。攻击者或一个被诱导的恶意LLM，可以越过模型沙箱，直接控制宿主机。
从“会说话的模型”到“能动手的囚徒”
理解这个攻击面的危险性，需要先看清当前AI应用的部署架构。
当你使用Claude Code或OpenAI Codex这类AI编程助手时，实际上有两台计算机在协同工作：一台是你的本地机器或云服务器，上面运行着agentic harness，负责执行代码、读写文件、调用API；另一台是远端的GPU服务器，大模型权重加载在上面，所有推理计算在这里完成，生成token后通过网络传回你的机器。
通常的安全关注点集中在AI agent的权限边界上——它能不能删除文件，能不能改写数据库，能不能越过预设的沙箱。但Kane提出的问题极其反直觉：模型回应请求所生成的token序列，在进入推理引擎的解析器时，会不会被解析器当作代码来执行？
这个问题的答案，被一个已确认的CVE推到了聚光灯下。
eval() 引发的血案：CVE-2025-9141 的完整故事
2025年8月20日，vLLM项目发布了一个安全公告：CVE-2025-9141，一个存在于Qwen3 Coder工具调用解析器中的远程代码执行漏洞。CVSS评分8.8，高危。
vLLM是目前最广泛部署的开源LLM推理引擎之一，由UC Berkeley Sky Computing Lab开发，广泛支持数十种主流模型架构。它的Qwen3 Coder解析器负责将模型生成的XML格式工具调用参数解析为可执行的函数调用——而问题就出在“解析”这一步。
这个解析器几乎把所有参数都直接传给了Python的eval()函数。
eval()是Python内置的“执行任意表达式”函数。它的行为是：把字符串当作代码来执行。当一位认证用户能够诱导模型生成包含恶意payload的工具调用参数，然后这个参数被eval()执行，结果就是远程代码执行——攻击者可以在vLLM服务器上运行任何命令。
更具戏剧性的是事件经过。提交这个漏洞代码的Pull Request后，vLLM的Gemini AI自动分析工具当场标记了该PR为“关键安全漏洞”。但在这般明确的安全警告面前，vLLM的首席维护者仍然强行合并了该PR，并写下了这句话：“I'm force merging this to unblock model usage, after lint.”
补丁在披露同日发布（v0.10.1.1）。但这个故事揭示了一个更深层的问题：在一部分AI基础设施的开源维护者眼中，速度和可用性是压倒优先级，安全警告可以被技术债化处理。
不是孤例：ShadowMQ 揭露的“代码复制即传播”
如果说CVE-2025-9141是“人为失误”的个体故事，那么Oligo Security在2025年11月披露的ShadowMQ漏洞集群，则暴露了整个推理引擎生态的结构性问题。
ShadowMQ的发现始于Meta的Llama Stack。Oligo的研究人员注意到，该框架使用了ZeroMQ的recv_pyobj()方法——一个方便但极其危险的函数，它用Python的pickle模块反序列化接收到的数据。问题在于：这些ZMQ套接字没有认证机制，暴露在TCP网络上，任何攻击者都能发送恶意构造的pickle对象，执行任意代码。
真正值得警惕的不是单一的漏洞，而是它如何传播。Oligo追踪了将近一年的时间线：
- 2024年10月：Meta Llama Stack被发现使用不安全pickle反序列化（CVE-2024-50050），Meta随后用JSON序列化替换了pickle。
- 2025年5月：vLLM被确认存在相同的零MQ pickle反序列化漏洞（CVE-2025-30165），在v0.10.0版本中被修复。
- 同期：NVIDIA TensorRT-LLM被确认存在同类高危漏洞。
- 同期：SGLang——另一个主流推理引擎——也被发现存在同样的不安全模式。值得玩味的是，SGLang的不安全文件开头写着一行注释：“Adapted from vLLM”。
- 同链条：Modular的Max Server，同时从vLLM和SGLang借用逻辑，继承了同一个漏洞模式。
这正是ShadowMQ最可怕的传播机制：不安全代码不是被恶意植入的，而是被作为“最佳实践”一字不改地复制到各个项目中。在不同的公司、不同的维护团队之间，同一个安全错误被线对线地拷贝。
Oligo Security发现，互联网上有数千个暴露的ZMQ TCP套接字，其指纹特征与这些推理服务器完全一致。每一个暴露的端口，都是一扇通往AI集群的敞开的门。
为什么推理引擎成了安全的“灯下黑”？
要理解这个问题的根源，需要从推理引擎在AI堆栈中的位置说起。
推理引擎是AI部署的最后一段管道。它把训练好的模型权重加载到GPU上，处理输入的token请求，运行前向传播，生成输出token，再把这些原始token解析成结构化的聊天响应，包含用户轮次、模型回复、工具调用等。对一个部署大模型的组织来说，推理引擎就是那个管道末端——它不能慢，不能出错，不能影响用户体验。
问题出在这三层叠加的压力上。
第一重压力来自认知偏差。推理引擎被默认为“数据处理的管道”，而不是“安全的边界”。长期以来，AI推理被视为一种计算密集型任务，安全关注集中在模型层面对抗样本攻击、数据中毒、模型窃取，而底层软件——解析器、序列化器、网络通信层——被视为传统软件的职责范畴。用Boyd Kane的话说：“推理引擎不被认为是危险的入口点。它们被主要视为需要尽可能快的东西。开发人员将速度优先于安全，这并不奇怪。”
第二重压力来自竞速文化。开源AI基础设施领域竞争节奏极其激烈，vLLM、SGLang、TensorRT-LLM等互为竞争对手，延迟和吞吐量是KPI，市场份额以部署量为标尺。在这个赛道里，一天的时间差可能意味着数百个新用户的流失。CVE-2025-9141的故事是这一文化的缩影：合并PR的首席维护者知道代码有问题——AI工具已经明确告诉他了——但他仍然选择合并。漏洞可以被“稍后修复”，但速度窗口过去了就不会回来。
第三重压力来自代码复用的“传染病”模式。SGLang从vLLM复制不安全代码，Modular又同时从两者复制——这不是个别项目的疏忽，而是开源AI基础设施的一条默认生存路径。当维护团队的核心KPI是“使能新模型”和“提升推理速度”时，安全审查通常被压缩到最小。漏洞模式就像感冒病毒一样在生态里传播，而整个行业还没有一个统一的“疫苗”——没有统一的供应链安全扫描，没有统一的SBOM要求，没有统一的漏洞响应流程。
更深层的危机：LLM正在被赋予修改推理引擎的能力
Kane在文章中指出了另一个更让人不安的维度：随着LLM越来越多地被用来编写或修改运行它们的推理引擎代码——通常是为了优化性能——一个本质上不可信的LLM如果获得了修改推理引擎的权限，它可以植入后门。
C++和CUDA组件是特别有吸引力的目标。这些底层代码直接管理GPU内存访问和数据传输。一个恶意LLM可以引入一个越界内存访问漏洞，使其能够在GPU或控制GPU的CPU主机上执行任意代码。这类漏洞的检测难度远高于解析器层面的eval()调用——因为它们发生在内存管理的底层，传统静态分析和运行时监控不易捕捉。
更关键的是，视觉token和音频token的处理正在急剧扩大攻击面。多模态推理引入了更复杂的token序列格式、更多的解析步骤、更多的数据格式转换。每多一层转换，就多一个潜在的eval级漏洞入口。
当OWASP头号AI威胁遇上了推理引擎
OWASP在2025年版的LLM应用Top 10中，将提示注入评为LLM01——头号威胁。提示注入的破坏力来自一个结构性特征：LLM无法区分用户提供的指令和系统指令，因为两者以相同的自然语言形式进入模型。
但Kane揭示的威胁模式完全不同。传统提示注入的“输出”是让模型说一些不该说的话，或者在agent层面越权操作；而推理引擎攻击的目标是让模型产生的token触发宿主机上的代码执行。前者停留在模型的行为层面，后者直接指向控制权。
这两者的组合尤其危险。一次成功的提示注入可以让LLM调用工具，而产品端的函数可能会要求LLM生成特殊格式的token，比如XML工具调用，这些token随后被推理引擎的解析器处理。如果解析器存在eval()类漏洞，一次间接提示注入就可以演变为远程代码执行——从AI对话到宿主服务器控制权，中间只隔了一个不安全的解析函数。
谁最脆弱？谁在自掘坟墓？
自托管推理的组织是最大的风险承受者。自部署vLLM或SGLang的企业——包括金融、医疗、科技行业的AI部门——手中握着推理引擎的全部配置和权限。正如Boyd Kane在文章中所言：“自托管推理引擎承担的风险比它要替代的商业API提供商多得多，因为管理员可以访问所有内部数据。”
驱动推理引擎竞赛的选手——NVIDIA、Meta、vLLM项目、SGLang项目——则是风险的责任方。他们的代码质量问题直接影响着下游数百乃至数千个组织的安全水位。
尤其值得关注的是open-weight模型。用Kane的话说：“随着open-weight LLM变得更强大，我们将有更多LLM运行在先进的、但接受审查较少的推理引擎上。这增加了恶意open-weight LLM遇到并利用脆弱推理引擎的可能性。”一个能力强大的开源模型，配上安全防护不足的自托管推理引擎，这个组合可能比任何商业API服务都更加危险。
防御很痛苦，但不得不做
Boyd Kane提出了几条防御思路，每一条都直指当前架构设计中的痛点。
方案一是架构分离——将GPU宿主和token解析器放在不同的计算机上。GPU宿主只发射logits（原始概率向量），另一台机器负责从logits采样token、解析token为聊天消息、转发消息到agentic harness。这种分离将解析器漏洞的破坏范围限制在CPU侧，而不是直接威胁GPU服务器的控制权。
方案二是零信任——限制GPU宿主的权限，将所有GPU宿主发出的数据视为不可信，拒绝假设内部流量是安全的。
方案三是常规化红队渗透测试。但正如Kane指出的，这需要先完成一个前提：“你需要先证明推理引擎是一个危险的入口点，行业才愿意对其进行安全审查。”
然而主流的行业现实是，绝大多数使用vLLM和SGLang的团队没有做这些。安全加固意味着逆向代理、网络分段、密钥管理、审计日志——每一项都意味着延迟成本的增加，而AI基础设施竞赛是以毫秒为单位进行的。
AI基础设施的“心脏出血时刻”正在来临
2014年Heartbleed漏洞的爆发，让全世界第一次意识到：加密基础设施的软件实现可以被一个bug摧毁。今天，推理引擎这个AI堆栈中最关键的管道末端软件，正在经历类似的心智转变阶段——安全社区已经发现问题，但行业主流尚未形成防御共识。
推理引擎不是ChatGPT的聊天界面，不是agent的沙箱，不是模型的对齐层。它是把模型从数学公式变成实际响应的最后一层管线。如果这一层不安全，整个AI应用的安全性就建立在沙堆上。
而且，与传统的Web安全不同，推理引擎面临的是来自两端威胁的夹击：一端是有恶意意图的人类攻击者，通过API发出精心构造的请求；另一端是一个越来越强大的LLM“囚徒”，通过生成特制的token序列尝试逃脱解析器。后者尤其令人不安——这意味着，整个AI界正在积极训练的越来越智能的模型，自身也可以在推理引擎中发现并利用漏洞。
当红队、蓝队和安全评审还在纠结提示注入的语义层攻击时，推理引擎的执行层漏洞已经指向了宿主机的root权限。
AI基础设施的竞赛正在轰轰烈烈地进行。但如果速度的代价是让整个生态的基础软件层布满代码执行漏洞，那么这场竞赛的终局可能不是赢者通吃，而是全线溃败。
推理引擎的安全，不是可以等等再修的问题。在AI基础设施中，它可能就是那个让你后悔莫及的灯下黑。
快报