SGLang 的 ZMQ broker：pickle 反序列化导致未授权 RCE

这是什么？

2026 年 3 月 12 日，Orca Security 研究员 Igor Stepansky 与 CERT 协调中心（CERT/CC）联合披露了 SGLang 中的三个漏洞。SGLang 是一个被广泛使用的开源框架，用于部署大语言模型和多模态模型（它在 OpenAI 兼容 API 之后承载 Qwen、DeepSeek、Mistral、Skywork 等）。其中两个——CVE-2026-3059 与 CVE-2026-3060，在 GitHub 安全公告库中均评为 CVSS 9.8——可对任何将相关功能暴露到网络的 SGLang 部署实现未授权远程代码执行。第三个 CVE-2026-3989（CVSS 7.8）是崩溃转储回放脚本中的一个本地/社会工程变体。三者根因相同：将不可信数据交给了 Python 的 pickle 模块。修复随版本 0.5.10 发布。

它与 LightLLM 的 pickle RCE 属于同一漏洞类别，并与 LiteLLM 的预认证 SQLi 和 LMDeploy 的 SSRF 一道，构成 2026 年 AI 基础设施 CVE 浪潮的一部分。我们报道它，是因为这一模式不断重演，而缓解措施是结构性的，而非表面的。

工作原理

Python 的 pickle 格式不仅存储数据，还存储重建对象的指令，而这些指令会在反序列化期间执行。因此，对攻击者可控的字节调用 pickle.loads()，按定义就是任意代码执行。经典原语是一个 __reduce__ 方法返回对 os.system 或 subprocess 调用的对象；无需任何花哨手法，这也是本文不复现任何 payload 的原因。

SGLang 在可从网络访问的路径上暴露了 pickle.loads()，且无任何认证：

CVE        组件                               向量 / 前提条件
---------  ---------------------------------  ----------------------------------------
3059       多模态生成模块                     经 ZMQ broker 的未授权 RCE；
(9.8)                                          需启用多模态生成
3060       编码器并行解聚（disaggregation）   经解聚模块的未授权 RCE；
(9.8)                                          需启用该功能
3989       replay_request_dump.py             对攻击者提供的 .pkl 执行 pickle.load()；
(7.8)                                          需本地文件/目录控制

据 CERT/CC，对于两个严重漏洞，「如果攻击者知道 ZMQ broker 监听的 TCP 端口并能向服务器发送请求，就可以通过向 broker 发送恶意 pickle 文件来利用该漏洞，broker 随后会将其反序列化」。无需 prompt、无需与模型交互、无需凭证——在 ZeroMQ 套接字上发送一条构造好的消息即可。该弱点被归类为 CWE-502，不可信数据反序列化。CVE-2026-3989 范围更窄：replay_request_dump.py 工具在未校验的情况下对转储文件调用 pickle.load()，因此能够写入转储目录的攻击者（或通过社会工程诱使运维人员回放恶意 .pkl）即可在运行该脚本的主机上执行代码。

为何重要

推理服务器并非低价值目标。它通常运行在内网可达范围很广的 GPU 主机上，保存着模型权重，并处理你的应用发送给它的 prompt 和文档。在 SGLang 进程中的代码执行可能导致主机被攻陷、横向移动、数据外泄或拒绝服务。由于两个严重漏洞均为预认证，且由套接字上的原始消息触发，任何把 ZMQ broker 置于可达接口上的部署，都可被任何能向其路由数据包的人利用。

有两种模式值得关注。其一，分布式推理的 ZMQ/IPC 管线是一条未经认证的信任边界，团队常常忘记它的存在——它的设计目标是集群内通信，而非面向敌对网络。其二，pickle 在 AI 技术栈中反复出现，因为它是在进程之间搬运 Python 对象（张量、请求、转储）阻力最小的途径。截至披露时尚无野外利用报告，但其 EPSS 评分和利用原语的简易程度，使它们成为机会性互联网扫描的理想目标。

防御

• 升级到 SGLang v0.5.10 或更高版本，CERT/CC 将其列为修复版本。注意存在滞后：GitHub 安全公告库仍将 <= 0.5.9 标记为受影响且未记录已修复版本，因此请以上游发布版本为准核对，而非依赖该公告库字段。
• 切勿将 ZMQ broker 暴露给不可信网络。 将推理内部套接字绑定到 127.0.0.1 或私有接口，并在 broker 端口与任何可路由目标之间部署网络分段与访问控制。无论版本如何，单这一步即可消解 CVE-2026-3059 与 CVE-2026-3060。
• 把套接字上的 pickle 当作 RCE 对待。 在你能控制序列化的地方，用纯数据格式——JSON 或 msgpack——替换 pickle，使畸形 payload 无法夹带代码。这正是 CERT/CC 推荐的结构性修复。
• 收紧崩溃转储处理（针对 CVE-2026-3989）：限制转储目录的写入权限，绝不对并非自己生成的 .pkl 运行 replay_request_dump.py。
• 监控推理主机。 留意指向 ZMQ 端口的异常入站 TCP 连接、SGLang Python 进程派生的异常子进程、异常位置的文件创建，以及指向陌生目的地的出站连接——这些都是 CERT/CC 与 Orca 指出的指标。
• 盘点你的部署层。 SGLang、vLLM、LightLLM、LMDeploy 及类似工具常由 ML 团队在标准安全审查之外搭建。在扫描器之前，先找出那些暴露在网络上的实例。

状态

项目	日期	状态
CERT/CC 漏洞通告（VU#665416）	2026-03-12	公开
Orca Security 披露博客	2026-03-12	公开
GitHub 安全公告库条目（CVE-2026-3059/3060）	2026-03-12	公开，CVSS 9.8
CERT/CC 通告最后修订	2026-04-07	列出 v0.5.10 为修复版
媒体报道（The Hacker News）	2026-03-17	公开
野外利用	—	披露时无报告

结论很直白：在可从网络访问的套接字上调用 pickle.loads()，不是一次性修补的 bug，而是应当被移除的反模式。修复是 v0.5.10；教训是：任何在端口上监听的 AI 推理组件，从第一天起就应被视为认证与反序列化的边界。