发帖
雷达卡
一、核心漏洞概览
网络安全研究机构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 主要受影响框架详情
- Meta Llama Stack
- 漏洞编号: CVE-2024-50050
- 影响版本: 所有低于v0.0.41的版本
- 风险级别: 高(远程无认证RCE)
- 英伟达产品线
- TensorRT-LLM: CVE-2025-23254，0.18.2版本前受影响
- 其他产品: Merlin Transformers4Rec(CVE-2025-23298)、NeMo(CVE-2025-23303/23304)、Triton推理服务器等也存在类似反序列化漏洞，形成"漏洞矩阵"
- 微软AI推理服务
- Sarathi-Serve: 已确认存在ShadowMQ模式，但官方尚未发布补丁
- Azure AI推理服务: 虽未直接受ShadowMQ影响，但存在类似的"模型命名空间重用"漏洞(CVE-2025-XXXX)
- 开源生态系统
- 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生态系统面临的深层次安全困境：
- 速度与安全的失衡：AI领域追求快速迭代，开发团队倾向于直接复用代码而非从零开始构建。“复制-粘贴”式的开发方式使得一个漏洞可以在几周内感染整个生态系统。
- 开源共享与安全边界的模糊：开源项目的广泛使用虽然促进了技术的发展，但也带来了安全边界模糊的问题，增加了安全管理和漏洞防范的难度。
- AI特有的安全复杂性：模型本身可以作为攻击载体（例如包含恶意代码的权重），而推理过程涉及复杂的计算图和数据流，安全审计的难度较大。
开源框架 → 广泛复用 → 单一漏洞影响整个行业 → 修复成本分散但影响集中6.2 行业安全建设建议
- 技术架构升级：建立AI框架间通用的安全通信协议，彻底摒弃pickle等不安全机制；设计“默认不信任任何输入”的推理架构，即使来自内部网络；在GPU层面实现租户隔离，防止一个租户滥用其他租户的计算资源。
- 开发流程安全增强：
代码审查 → 安全扫描 → 漏洞模拟测试 → 灰度发布 → 持续监控 - 供应链安全管理：建立框架依赖关系图谱，实时监控第三方组件漏洞；对关键框架实施“安全沙箱”隔离，防止漏洞横向传播；要求框架供应商提供安全审计报告和漏洞响应承诺。
行动清单与风险缓解优先级
7.1 紧急响应步骤（24小时内）
- 资产清点：列出所有使用受影响框架的服务（包括内部开发和第三方API），按“公网暴露程度×业务重要性”排序，优先处理高风险资产。
- 版本检查与升级：检查当前使用的框架版本，及时升级到安全版本。
# 示例: 检查vLLM版本 pip show vLLM | grep Version # 升级命令 pip install --upgrade vLLM==0.8.0 - 临时防护部署：对于无法立即升级的系统，实施网络隔离和边界防护，开启所有相关服务的详细日志记录，为可能的攻击溯源做准备。
7.2 中长期安全加固（30天内）
- 全面代码审计：检查所有内部代码库，搜索类似ShadowMQ的不安全反序列化模式，特别关注使用ZeroMQ、pickle或其他序列化库的代码片段。
- 安全架构重构：评估并采用安全的通信替代方案（如gRPC+Protobuf），实施“最小权限原则”，限制推理服务的系统访问权限。
- 建立安全监测体系：部署AI安全监控系统，检测异常的模型加载和命令执行，与安全研究机构（如Oligo Security、奇安信CERT）建立漏洞信息共享渠道。
总结与行业启示
ShadowMQ漏洞危机揭示了AI基础设施安全的脆弱性，以及代码复用带来的系统性风险。在AI快速发展的今天，一个看似微小的实现细节缺陷，可以通过代码复制在短时间内变成整个行业的安全灾难。
核心启示：AI安全不能仅依赖于“打补丁”，需要从架构设计层面重新思考安全问题；代码复用必须伴随严格的安全审查和持续监控，建立“安全优先”的开发文化；跨厂商、跨行业的安全协作至关重要，单一公司难以独自应对生态级安全挑战。
立即行动：检查您的AI基础设施是否使用受影响框架，优先升级公网暴露的推理服务。
为了预防未来可能出现的类似漏洞，建议建立一个常规的框架安全审计机制。
请注意，此分析依据的是截至2025年11月19日的公开资料。微软Sarathi-Serve的官方修复措施可能会有后续更新。因此，强烈建议定期查看各供应商发布的官方安全通告，以便获得最新的修复详情。
京公网安备 11010802022788号
