| 在 LessWrong 阅读 | 大型语言模型通常在一台计算机上采取行动（通过代理性工具，例如 Claude Code 或 Codex），然而 LLM 对提示的响应是在另一台具有 GPU 访问权限的计算机上计算的。恶意 LLM 是否能够控制其权重加载的主机计算机？这样的计算机是高价值目标：它具有足够的计算能力来运行前沿 LLM，提供对 LLM 权重的轻松访问，并且与互联网上的普通计算机相比，具有对数据中心内其他计算机的特权访问。本文探讨了恶意 LLM 如何轻易控制主机计算机。这里考虑的主要攻击涉及 LLM 发出一系列语义意义无关的符号序列，但利用了加载 LLM 到 GPU 的软件中的漏洞，运行 LLM 以生成输出符号，并将这些符号解析为响应。LLM 如何在主机计算机上执行代码？像任何程序一样，推理引擎，例如 vLLM 或 SGLang，可能包含可被利用的漏洞。由于 LLM 控制传递给推理引擎的符号，因此恶意 LLM 可以发出一系列令一些编码不佳的推理引擎错误地将其视为代码或要执行的指令，而不是返回给用户的数据。但所有推理引擎无疑都是健壮的软件，这种情况绝不会发生，对吗？vLLM 之前在工具调用参数上使用了 eval()，CVE-2025-9141 是 vLLM 的基于 XML 的工具解析器的任意代码执行漏洞。解析器几乎将每个工具调用参数传递给 eval()，允许 LLM 在主机计算机上执行任意代码。Gemini 自动分析了引入此漏洞的 PR，并正确标记为严重安全漏洞。尽管有这种警告，vLLM 的主要维护者还是强制合并了这个 PR，写道：不幸的是，将任意符号序列解析为一个完整的聊天（包括用户发言、助手响应、工具调用等）并非易事，而具体过程在不同 LLM 之间往往差异很大。这种复杂性为可能允许在主机计算机上执行任意代码的漏洞创造了更多机会。vLLM 和 SGLang 都很复杂，漏洞很常见现代推理引擎的功能不仅仅是将符号序列映射到字符串。vLLM 的文档列出了支持 200 多种模型架构，其示例目录中包含了约 35 个 Jinja 聊天模板。现代推理引擎解析许多聊天格式，稍微不正确的解析逻辑会导致 LLM 的输出被解释为要执行的代码。在这个 vLLM 问题中，一位用户讨论了 LLM 如何与 MiniMax-M3 理论，LLM 发出了字符串 <mm:think> ，vLLM 错误地将这个普通字符串解析为推理块的开始。因此，响应变成了：我会准确地重复你说的话：<mm:think> 那样怎么样？ vLLM 将其解析为：响应：我会准确地重复你说的话：推理： 那样怎么样？ 这是一个比较无害的解析器错误，但它表明推理引擎的功能超过了将符号转换为字符串并将其连接在一起。它们是在不断迭代的复杂系统，其开发人员面临着极大的压力，必须尽可能提高它们的速度。这些因素增加了恶意 LLM 将解析器错误转变为在推理主机上执行任意代码的风险。视觉和音频符号可能会增加攻击面 多模态架构允许 LLM 以图像或音频以及简单文本进行响应。将模型的音频或视觉输出转化为可用媒体可能比解码文本符号更复杂。然而，据我了解，目前的多模态 LLM 通常发出约束媒体符号，而非任意文件字节。模型特定的解码器将这些符号转换为像素或波形，随后被编码为文件。这使得经典的针对 ffmpeg 或媒体查看器的软件的恶意文件利用不那么直接可供模型访问，但额外的解码器、编码器和本地内核仍然增加了攻击面。我目前不认为多模态输出是主机被攻陷的主要途径。然而，它提供的带宽远高于仅仅文本，未来的推理引擎可能会优化这些媒体生成路径，使其更易被利用。我也不知道专有的多模态模型如何表示图像和音频输出；它们的方法可能带来不同的风险。LLM 发现并利用推理引擎漏洞的可能性有多大？某种可能性？我不太确定。发现有用的漏洞可能是更困难的一步。利用它所需的符号序列可能是相当不寻常的，但这并不意味着该漏洞不可被利用。在正确的上下文中（例如，LLM 探索 vLLM 代码库并在此过程中发现漏洞），我预计前沿 LLM 能够发出该序列