ShadowMQ：代码复用如何在AI生态系统中传播关键漏洞

影响Meta、NVIDIA、微软、vLLM、SGLang和Modular项目的AI推理服务器存在关键漏洞。

在加快人工智能普及的竞赛中，确保AI基础设施的安全性也至关重要。

过去一年，Oligo Security的研究团队披露了一系列潜藏在一些最广泛使用的AI推理服务器中的关键远程代码执行漏洞，这些服务器包括来自Meta、NVIDIA、微软的框架以及像vLLM和SGLang这样的PyTorch项目。

这些漏洞都可追溯到同一个根本原因：被忽视的不安全的ZeroMQ使用以及Python的pickle反序列化。但最让我们惊讶的不是漏洞本身，而是它的传播方式。

当我们深入研究时，发现代码文件在项目之间被复制（有时是逐行复制），将危险模式从一个代码库带到下一个。

我们称这种模式为ShadowMQ：一种通过现代AI技术栈中的代码复用传播的、隐藏的通信层缺陷。

发现过程

和我们的所有调查一样，事情始于好奇。

2024年，在分析Meta的Llama Stack时，我们注意到了一个奇怪的模式：使用了ZMQ的recv_pyobj()方法——这是一个便捷函数，它使用Python的pickle模块来反序列化传入的数据。

如果你用过Python，就知道pickle并非为安全而设计。它在反序列化过程中可以执行任意代码，这在严格控制的环境中是可行的，但如果通过网络暴露出来，就远非安全了。

Meta的Llama Stack正在做的正是这个。未经身份验证的ZMQ套接字，使用pickle反序列化不受信任的数据。这是远程代码执行的“配方”。

1
2
3

def recv_pyobj(self, flags: int = 0) -> Any:
    msg = self.recv(flags)
    return self._deserialize(msg, pickle.loads)

我们向Meta报告了这个问题，他们迅速发布了补丁（CVE-2024-50050），用基于JSON的安全序列化机制取代了pickle。但我们预感到这不是一个孤立的问题。

模式的浮现

在扫描其他推理框架时，我们发现主要框架中都存在同样的问题。

NVIDIA的TensorRT-LLM、Pytorch项目vLLM和SGLang，甚至Modular Max Server，都包含几乎相同的不安全模式：在未经身份验证的ZMQ TCP套接字上进行pickle反序列化。

不同的维护者和不同公司维护的项目，都犯了同样的错误。

当我们追踪代码谱系时，原因变得显而易见：代码复用，在某些情况下甚至是直接复制粘贴代码。整个文件从一个项目被改编到另一个项目，改动极小。有时文件开头的注释甚至明确说明了这一点。

例如，在SGLang中，存在漏洞的文件开头就写着：“Adapted from vLLM”。

这种“改编”不仅包括了架构和性能优化，也包含了完全相同的不安全反序列化逻辑，该逻辑在vLLM中导致了RCE（由Oligo于2025年5月披露为CVE-2025-30165）。

为了理解这个未修补漏洞的潜在影响，考虑一下信任并已采用SGLang框架的、不断增长的公司名单：xAI、AMD、NVIDIA、Intel、LinkedIn、Cursor、Oracle Cloud、Google Cloud、Microsoft Azure、AWS、Atlas Cloud、Voltage Park、Nebius、DataCrunch、Novita、InnoMatrix、MIT、UCLA、华盛顿大学、斯坦福大学、加州大学伯克利分校、清华大学、Jam & Tea Studios、Baseten，以及其他遍布北美和亚洲的主要技术组织。

同样的模式再次出现在Modular的Max Server中，它借用了vLLM和SGLang两者的逻辑。

这就是ShadowMQ的传播方式：一个安全缺陷被复制和继承，由于维护者直接从其他框架借用功能，导致其在代码库间被复制。

广泛存在的共同风险

ShadowMQ之所以特别危险，是因为这些AI推理服务器构成了企业AI基础设施的支柱。

它们运行关键的工作负载，通常在GPU服务器集群上运行，处理高度敏感的数据，从模型提示到客户信息。

利用单个易受攻击的节点，攻击者可以：

• 在集群上执行任意代码
• 将权限提升到其他内部系统
• 窃取模型数据或密钥
• 为利益安装基于GPU的加密货币挖矿程序，就像ShadowRay攻击活动那样

我们识别出了数千个暴露在公共互联网上、通过未加密方式通信的ZMQ套接字，其中一些明显属于生产推理服务器。在这种设置下，一次错误的反序列化调用就可能暴露整个AI操作。

我们深入研究了ZMQ TCP握手过程。一个成功的TCP握手（用于识别ZMQ套接字）总是在TCP数据中包含以下字节：0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x7f。

通过搜索其TCP握手独有的ZMQ标识头，正如我们所想，有数千个ZMQ TCP套接字暴露在互联网上。

披露与厂商响应

以下是时间线的展开：

• 2024年10月：Meta Llama Stack (CVE-2024-50050) – 不安全pickle使用被修补，改用基于JSON的序列化。
• 2025年5月：vLLM (CVE-2025-30165) – 通过将易受攻击的V0引擎替换为安全的V1默认引擎，修复了关键RCE。
• 2025年5月：NVIDIA TensorRT-LLM (CVE-2025-23254) – 在Oligo报告后实施了HMAC验证。被NVD评为关键（9.3）。
• 2025年6月：Modular Max Server (CVE-2025-60455) – 快速修补，使用msgpack代替pickle。

然而，有些项目没有打补丁。

微软的研究框架Sarathi-Serve仍然存在漏洞。SGLang尽管其维护者承认了我们的分析，但只实施了不完整的修复。

这些就是我们所谓的“影子漏洞”：已知问题在未分配CVE编号的情况下持续存在，悄无声息地等待着被攻击者重新发现。

RCE演示

为了展示ShadowMQ在现实世界中的影响，我们录制了在NVIDIA TensorRT-LLM和Modular Max上利用RCE的实况演示。下面的视频精确地说明了如何在实际中利用该漏洞。

更深层的教训：复制容易，审计难

开发者复制有漏洞的代码并非因为他们粗心。他们这样做是因为整个生态系统鼓励这种行为。在开源AI社区，性能至上。

项目正在以惊人的速度推进，从同行那里借用架构组件是很常见的。但当代码复用包含了不安全的模式时，其后果会迅速向外扩散。

文档很少警告某些方法的安全风险（recv_pyobj()就是一个完美的例子）。

甚至像ChatGPT这样的代码生成工具也倾向于重复常见的示例（无论是否有漏洞），因为它们反映了现实世界的用法。

这就是为什么相同的RCE攻击向量会悄无声息地出现在从Meta到NVIDIA的各种框架中。

我们要感谢Meta、NVIDIA、vLLM和Modular的安全团队负责任地修复了这些漏洞。

如何保持安全

• 立即打补丁。
• 不要将pickle或recv_pyobj()用于不受信任的数据。
• 为任何基于ZMQ的通信添加身份验证（HMAC或TLS）。
• 扫描暴露的ZMQ端点，并限制其从网络的访问，通过绑定到特定的网络接口。避免使用tcp://*，这会将套接字暴露在所有网络接口上。
• 教育开发团队：序列化选择就是安全选择。

Oligo如何防范这些漏洞

Oligo运行时安全平台的关键优势在于，它能够比任何其他技术更深入、实时地洞察运行时行为。以下是这种可见性如何转化为可操作情报来防范构成ShadowMQ的一系列漏洞的示例。

1. 在运行时发现易受攻击的行为

我们的技术可以检测pyzmq何时运行以及何时调用像recv_pyobj()这样的函数。它还会观察同一执行栈中对pickle.loads的后续调用。

2. 识别恶意的pickle载荷

Oligo能够判断被加载的pickle对象是否会导致代码执行、进程创建或任何其他可疑行为——而非pickle的合法使用。

3. 检测利用行为，无论其如何触发

即使攻击者使用ZMQ而不调用recv_pyobj()，或者以其他方式使用pickle，Oligo仍然可以捕获导致ShadowMQ式利用的ZMQ与pickle的组合使用。

最后思考

ShadowMQ不仅仅是一个漏洞。它是一个案例研究，展示了创新与不安全性如何共同传播。

单个库中的单个函数最终在多个框架中造成了一系列关键缺陷，影响了世界上一些最受欢迎的AI系统。这一切仅仅是因为一个项目在未完全理解其含义的情况下复制了另一个项目的代码。

安全，尤其是在AI基础设施中，必须有意识地进行。当我们复制性能优化时，我们也继承了它们的风险。