vLLM 0.32.0 一次修 8 个 CVE：pickle 反序列化那条最要命

vLLM 0.32.0 一次修了 8 个 CVE，覆盖范围很广。其中最需要立刻处理的是 CVE-2026-115912，pickle 反序列化导致的远程代码执行。

pickle 这条为什么最要命

vLLM 在某些路径下会反序列化 pickle 格式的数据。pickle 的设计本身就允许在反序列化时执行任意代码，这是它的特性不是 bug。所以只要攻击者能让目标进程反序列化一段他控制的字节流，代码执行就是必然结果。这类漏洞的修复从来不是「加个校验」，而是彻底换掉格式或者把入口收窄到可信来源。

另外几个

CVE-2026-115915 涉及 EPS 与 Ghostscript 解析——图片处理链路上的老问题，Ghostscript 历史上出过太多次同类漏洞。CVE-2026-115917 是 CORS 配置问题，听起来不严重，但如果推理服务暴露在浏览器可访问的域上，就可能被恶意页面跨域调用，把算力当成免费资源。

同一天 llama.cpp 也修了 6 个

涉及恶意 GGUF 模型文件与越界 Token ID。这条提醒很关键：模型文件本身就是一个攻击面。你从 HuggingFace 上拉的任何 GGUF，本质上都是不可信输入。

优先级建议

如果 vLLM 对外提供服务，先升到 0.32.0，然后在服务前面加一层：只接受已知格式的请求，禁用不必要的图片和文档解析入口，CORS 白名单收紧到具体域名。如果只在内网跑，也别拖——内网横向移动是勒索软件最常用的路径。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

pickle 这条的修复方式从来不是加校验，而是换格式或者把入口收窄到可信来源。另外模型文件本身就是攻击面，从公开仓库拉的 GGUF 都是不可信输入，这点常被忽略。

pickle 这条别纠结怎么打补丁，换格式是唯一解。反序列化执行任意代码是设计特性，白名单校验都能绕。真正该查的是整条链路里谁在生产接收外部 pickle，模型权重、缓存、请求体都要过一遍。8 个 CVE 一起发说明之前审计欠账不少。我们把 vLLM 关在独立容器里、网络出口全掐，算兜底。

pickle 这条其实没得选，只能把反序列化入口彻底关掉，改成 safetensors 或者带签名的格式。我们之前给推理服务加过一层前置校验，结果自己就成了瓶颈。思路是别在校验上做加法，把加载路径拆开，权重走只读共享存储，请求侧根本不接受 pickle。