一、核心漏洞概览

网络安全研究机构Oligo Security发现了一组严重的远程代码执行（RCE）漏洞，这些漏洞通过代码复用机制在主流AI推理框架之间传播，影响了Meta、英伟达、微软等科技巨头的核心AI基础设施。

核心漏洞特征

• 漏洞名称： ShadowMQ (CVE-2024-50050及相关系列)
• 技术本质： 不安全的反序列化漏洞，源于ZeroMQ的recv_pyobj()与Python的pickle模块组合使用
• CVSS评分： 基础分6.3/10，特定场景可达9.8(高危)
• 攻击特点： 无需身份验证即可远程触发，攻击者可执行任意系统命令，获取服务器完全控制权
• 影响范围： 已确认影响Meta Llama Stack、英伟达TensorRT-LLM、微软Sarathi-Serve、vLLM、SGLang等主流推理框架

二、漏洞技术深度解析

2.1 漏洞根源: 致命的代码模式

ShadowMQ漏洞的核心在于一段被广泛复制的危险代码片段:

# 危险代码示例
import zmq
import pickle
context = zmq.Context()
socket = context.socket(zmq.REP)
socket.bind("tcp://*:5555")
while True:
    data = socket.recv_pyobj()  # 使用ZeroMQ接收Python对象
    result = process_data(pickle.loads(data))  # 直接反序列化接收到的数据
    socket.send_pyobj(result)
    

这段代码存在双重安全缺陷:

• recv_pyobj()方法： 直接通过网络接收Python对象，不进行任何安全检查
• pickle.loads()函数： 反序列化任意数据，可执行隐藏在数据中的恶意代码

Python的pickle模块设计初衷并非安全通信，它在反序列化过程中会执行代码对象，这在网络环境中是极其危险的。

2.2 代码传播路径: 从Meta到整个AI生态

漏洞传播呈现清晰的链式反应:

传播节点	漏洞版本	传播方式
Meta Llama Stack (CVE-2024-50050)	早期版本	原始漏洞点
vLLM (CVE-2025-30165)	v0.8.0前	代码直接复制(文件注释:“Adapted from Meta”)
SGLang	多版本	从vLLM复制(注释:“Adapted from vLLM”)
英伟达TensorRT-LLM (CVE-2025-23254)	0.18.2前	从SGLang/vLLM借鉴架构
微软Sarathi-Serve	当前版本	类似设计模式
Modular Max Server (CVE-2025-60455)	25.6前	同时借鉴vLLM和SGLang

Oligo研究发现，多个项目中存在完全相同的代码行，甚至保留了相同的注释，证实了"复制-粘贴"式传播是漏洞扩散的主要途径。

三、受影响产品与风险评估

3.1 主要受影响框架详情

1. Meta Llama Stack
   • 漏洞编号: CVE-2024-50050
   • 影响版本: 所有低于v0.0.41的版本
   • 风险级别: 高(远程无认证RCE)
2. 英伟达产品线
   • TensorRT-LLM: CVE-2025-23254，0.18.2版本前受影响
   • 其他产品: Merlin Transformers4Rec(CVE-2025-23298)、NeMo(CVE-2025-23303/23304)、Triton推理服务器等也存在类似反序列化漏洞，形成"漏洞矩阵"
3. 微软AI推理服务
   • Sarathi-Serve: 已确认存在ShadowMQ模式，但官方尚未发布补丁
   • Azure AI推理服务: 虽未直接受ShadowMQ影响，但存在类似的"模型命名空间重用"漏洞(CVE-2025-XXXX)
4. 开源生态系统
   • vLLM: CVE-2025-30165，广泛用于高性能推理服务，CVSS评分8.0
   • SGLang: 被xAI、AMD、英伟达、LinkedIn等企业采用，存在不完全修复
   • 其他框架: 如Modular Max Server、Hugging Face生态中的部分推理服务

3.2 行业影响评估

行业领域	风险程度	影响特点
云计算/AI基础设施	极高	攻击者可劫持GPU集群，窃取模型权重，植入挖矿程序
金融服务	高	交易系统运维权限被窃取，客户数据泄露，合规风险
医疗健康	高	患者隐私泄露，医疗AI系统被篡改，影响诊断准确性
智能制造	中高	工业控制系统被入侵，生产线瘫痪，产品质量受损
科研机构	中高	研究成果被窃取，计算资源被滥用，论文数据造假风险

四、漏洞危害全景分析

4.1 直接技术危害

• 服务器接管： 攻击者可执行任意命令(如创建root账户、删除关键文件)
• 数据灾难：
  • 模型权重窃取(价值可达数百万美元)
  • 客户敏感数据(如医疗记录、金融信息)泄露

运维日志篡改与服务可用性破坏

攻击者可能通过篡改运维日志来掩盖其攻击痕迹，使得安全人员难以追踪攻击源头。此外，攻击者还可能通过消耗服务器的CPU或GPU资源，或者执行删除命令等方式导致服务中断。

持久化控制

攻击者会植入后门程序，建立长期控制通道，这些通道通常能够绕过常规的安全检测，从而实现长时间的隐蔽控制。

产业链安全风险

1. 推理即服务(RaaS)平台的风险

在一个RaaS平台上，单一的安全漏洞可能会波及多个租户，导致“租户隔离失效”。攻击者可以通过一个客户的推理请求窃取另一个客户的敏感信息，或者在多租户环境中植入恶意代码，影响所有使用该服务的客户。

2. AI开发工具链污染

如果开发新模型所用的框架受到感染，这将把漏洞引入下游应用。攻击者还可以通过污染训练数据，在模型中植入后门，从而在模型部署后发动攻击。

3. 供应链攻击

攻击者 → 攻破推理框架 → 控制模型训练/推理 → 污染AI输出 → 影响依赖AI决策的业务系统

供应链攻击是指攻击者通过污染供应链中的某个环节（如开发工具、库文件等），将恶意代码或漏洞引入最终产品中，从而对用户造成危害。

官方修复与临时防护方案

5.1 厂商修复进展

厂商	产品	修复版本	修复措施
Meta	Llama Stack	v0.0.41+	移除pickle，改用基于JSON的安全序列化技术
英伟达	TensorRT-LLM	0.18.2+	重构通信模块，增加安全验证层
vLLM团队	vLLM	v0.8.0+	默认切换到更安全的V1引擎，移除潜在的危险代码
Modular	Max Server	v25.6+	实现安全的反序列化替代方案
微软	Sarathi-Serve	尚未发布	正在评估修复方案（截至2025年11月）

5.2 紧急防护措施（无法立即升级时）

1. 网络层面防护

• 立即隔离：将推理服务从公共网络隔离，仅允许通过虚拟专用网络(VPN)或堡垒机访问。
• 端口限制：关闭所有不必要的端口，尤其是ZeroMQ默认使用的5555-5559端口。
• 防火墙规则：

  # 示例: 仅允许特定IP访问推理服务
  iptables -A INPUT -p tcp --dport 5555 -s <trusted_ip> -j ACCEPT
  iptables -A INPUT -p tcp --dport 5555 -j DROP

2. 应用层面加固

• 禁用危险函数：在框架配置中禁用与pickle相关的函数，改用安全的替代品（如json、protobuf）。
• 输入验证：对所有网络输入实施严格的格式检查，拒绝任何可疑数据。
• 认证增强：为所有通信通道添加TLS加密和双向认证。
• 权限降级：以非root用户身份运行推理服务，限制潜在损害范围。

3. 监控与检测

• 在推理服务前部署Web应用防火墙(WAF)，配置规则检测包含pickle特征的恶意请求。
• 启用详细的日志记录，特别是命令执行和异常网络活动的日志。
• 定期进行漏洞扫描，使用Oligo等安全研究机构提供的检测工具。

AI框架安全的前瞻性思考

6.1 代码复用安全的系统性挑战

ShadowMQ漏洞揭示了AI生态系统面临的深层次安全困境：

1. 速度与安全的失衡：AI领域追求快速迭代，开发团队倾向于直接复用代码而非从零开始构建。“复制-粘贴”式的开发方式使得一个漏洞可以在几周内感染整个生态系统。
2. 开源共享与安全边界的模糊：开源项目的广泛使用虽然促进了技术的发展，但也带来了安全边界模糊的问题，增加了安全管理和漏洞防范的难度。
3. AI特有的安全复杂性：模型本身可以作为攻击载体（例如包含恶意代码的权重），而推理过程涉及复杂的计算图和数据流，安全审计的难度较大。

开源框架 → 广泛复用 → 单一漏洞影响整个行业 → 修复成本分散但影响集中

6.2 行业安全建设建议

1. 技术架构升级：建立AI框架间通用的安全通信协议，彻底摒弃pickle等不安全机制；设计“默认不信任任何输入”的推理架构，即使来自内部网络；在GPU层面实现租户隔离，防止一个租户滥用其他租户的计算资源。
2. 开发流程安全增强：

   代码审查 → 安全扫描 → 漏洞模拟测试 → 灰度发布 → 持续监控

3. 供应链安全管理：建立框架依赖关系图谱，实时监控第三方组件漏洞；对关键框架实施“安全沙箱”隔离，防止漏洞横向传播；要求框架供应商提供安全审计报告和漏洞响应承诺。

行动清单与风险缓解优先级

7.1 紧急响应步骤（24小时内）

1. 资产清点：列出所有使用受影响框架的服务（包括内部开发和第三方API），按“公网暴露程度×业务重要性”排序，优先处理高风险资产。
2. 版本检查与升级：检查当前使用的框架版本，及时升级到安全版本。

   # 示例: 检查vLLM版本
   pip show vLLM | grep Version
   # 升级命令
   pip install --upgrade vLLM==0.8.0

3. 临时防护部署：对于无法立即升级的系统，实施网络隔离和边界防护，开启所有相关服务的详细日志记录，为可能的攻击溯源做准备。

7.2 中长期安全加固（30天内）

1. 全面代码审计：检查所有内部代码库，搜索类似ShadowMQ的不安全反序列化模式，特别关注使用ZeroMQ、pickle或其他序列化库的代码片段。
2. 安全架构重构：评估并采用安全的通信替代方案（如gRPC+Protobuf），实施“最小权限原则”，限制推理服务的系统访问权限。
3. 建立安全监测体系：部署AI安全监控系统，检测异常的模型加载和命令执行，与安全研究机构（如Oligo Security、奇安信CERT）建立漏洞信息共享渠道。

总结与行业启示

ShadowMQ漏洞危机揭示了AI基础设施安全的脆弱性，以及代码复用带来的系统性风险。在AI快速发展的今天，一个看似微小的实现细节缺陷，可以通过代码复制在短时间内变成整个行业的安全灾难。

核心启示：AI安全不能仅依赖于“打补丁”，需要从架构设计层面重新思考安全问题；代码复用必须伴随严格的安全审查和持续监控，建立“安全优先”的开发文化；跨厂商、跨行业的安全协作至关重要，单一公司难以独自应对生态级安全挑战。

立即行动：检查您的AI基础设施是否使用受影响框架，优先升级公网暴露的推理服务。

为了预防未来可能出现的类似漏洞，建议建立一个常规的框架安全审计机制。

请注意，此分析依据的是截至2025年11月19日的公开资料。微软Sarathi-Serve的官方修复措施可能会有后续更新。因此，强烈建议定期查看各供应商发布的官方安全通告，以便获得最新的修复详情。