PyTorch torch.load高危漏洞解析：权重安全模式遭绕过，8.8分CVE危及AI模型供应链

近日，支撑现代深度学习研究与应用的PyTorch框架曝出一项严重安全漏洞。这个漏洞的特别之处在于，它绕过了PyTorch官方专门设计、用于防范恶意模型文件的安全加载机制。漏洞编号为CVE-2026-24747，CVSS评分为8.8，属于高危等级。攻击者可以利用该漏洞，在用户进程中执行任意代码，即使受害者已经启用了官方推荐的安全防护选项。

“安全模式”为何失守？

在PyTorch的日常使用中，开发者最常使用的函数之一就是 torch.load()，它用于加载训练好的模型文件。由于Python内置的pickle反序列化机制本身存在安全风险，可能导致任意代码执行，PyTorch很早就引入了 weights_only=True 这个参数。这个设计的初衷很好：当启用这个“安全模式”时，torch.load() 承诺只加载纯数据（即模型权重），并阻断pickle中任何潜在的可执行代码路径，让用户能够放心地加载来自外部的模型文件。

然而，安全研究人员的最新发现表明，这一道安全防线并没有我们想象中那么可靠。漏洞的根本原因在于，这个“仅加载权重”的反序列化器，未能对pickle的操作码（opcode）和存储的元数据（metadata）进行充分且严格的验证。

具体来说，攻击者可以通过精心构造一个恶意的 .pth 模型文件，来触发以下两类问题：

1. 堆内存破坏：对非字典类型的数据结构错误地应用了 SETITEM 或 SETITEMS 这类操作码，从而破坏了正常的内存结构。
2. 存储数据不匹配：文件声明的存储元素数量与实际归档的数据大小不一致，这会导致系统在处理时抛出异常。

想象一下这个场景：一位研究员或工程师自信地启用了 weights_only=True 参数，以为万无一失，然后加载了一个从开源平台下载的“最新SOTA模型”。殊不知，这个模型文件可能暗藏恶意构造，触发上述内存破坏，进而可能被利用来劫持整个Python进程的控制权。

AI供应链安全面临现实威胁

这个漏洞对当前火热的AI开源生态构成了非常现实的威胁。无论是学术界的研究者，还是工业界的算法工程师，都习惯于从Hugging Face、GitHub等公共开源平台下载、测试和微调他人发布的模型检查点（checkpoint）。这些平台已成为AI模型分发的核心“供应链”。

一旦有攻击者将精心伪装的恶意模型文件上传到这些平台，就很容易被其他用户广泛下载和加载。由于 torch.load 函数应用极其普遍，且很多人信任 weights_only=True 提供的保护，其潜在影响范围非常广。

根据PyTorch官方的安全通告，所有运行PyTorch 2.9.1及之前版本的环境均受此漏洞影响。攻击链非常简单：攻击者只需诱骗目标用户加载一个恶意构造的模型检查点文件（.pt 或 .pth 等格式），即可在受害者进程的上下文中执行任意代码，可能导致数据泄露、系统被控等严重后果。

紧急修补方案已发布

面对这一高危漏洞，PyTorch开发团队反应迅速，已在最新的 2.10.0版本 中完成了修复。因此，最直接、最有效的应对措施就是立即升级。

我们强烈建议所有使用PyTorch的开发者、研究人员以及企业IT安全团队，尽快将生产环境和开发环境中的PyTorch升级至2.10.0或更高版本。这是确保模型加载过程真正安全可靠的根本方法。

对于因某些原因暂时无法立即升级的用户，则需要采取严格的缓解措施：

• 谨慎对待来源不明的模型文件：不要随意加载从不可信渠道获取的模型。
• 坚持可信来源：尽可能仅从官方认证或信誉良好的渠道（如知名研究机构、大厂官方发布）获取模型检查点。
• 隔离运行：在沙箱或隔离的容器环境中运行模型加载和测试代码，以限制潜在攻击造成的破坏范围。

本文基于PyTorch官方安全公告及相关技术分析撰写，漏洞详情可参阅PyTorch官方发布的安全更新说明。AI技术的快速发展也带来了新的安全挑战，保持对基础框架安全性的关注并及时更新，是每个开发者必修的功课。关于此类技术漏洞的更多深度讨论，欢迎访问云栈社区的安全板块进行交流。