Hugging Face Diffusers惊现高危漏洞：加载一个模型就能让攻击者接管你的服务器
AI开源生态的"地基"正在动摇。
就在不久前，安全研究团队Zafran Labs抛出了一颗重磅炸弹——Hugging Face旗下广受欢迎的diffusers库存在多个严重安全缺陷。问题的棘手之处在于，这些漏洞并非什么边缘场景下的偶发bug，而是直指核心加载机制的设计缺陷。换句话说，当你以为自己在安全地加载一个AI模型时，恶意代码可能已经悄无声息地在你的机器上跑了起来。
这件事之所以值得所有人警惕，是因为diffusers早已不是一个小众工具。它被嵌入到全球无数的生产管道、CI/CD流程和容器镜像里，月下载量高达700万次，日均安装接近20万次。而Hugging Face整体平台的月下载量更是突破了1亿大关，背后站着微软、亚马逊Bedrock、NVIDIA、苹果等巨头。这样一个基础设施级别的平台出现安全漏洞，影响面绝不是"某个用户中招"那么简单。
漏洞到底出在哪
Zafran团队发现的全部问题，根源都可以追溯到同一个经典的安全失误——检查时间到使用时间（TOCTOU）的竞争条件缺陷。
正常情况下，当你用diffusers加载一个远程模型时，系统应该先检查这个模型是否可信（也就是trust_remote_code机制），确认没问题后再去下载完整的代码。但实际情况是，这个"检查"和"下载"被拆成了两个独立的HTTP请求，而且安全检查只覆盖到了第一个请求。中间那大约0.3秒的空档，足够攻击者做很多事情了。
配置文件、自定义加载器、管道代码——这些在开发者眼里本该是"静态数据"的东西，通过这个缝隙摇身一变成了可执行代码。一次看似平常的模型加载操作，就这样变成了攻击者渗透企业内网的初始入口。
三个CVE，三种攻击路径
这次披露一共涉及三个正式编号的漏洞，每一个都足够让安全团队头疼。
CVE-2026-44827拿到了8.8的CVSS评分，属于高危级别。它的攻击手法相当巧妙：利用diffusers在解析默认的"None.py"文件时的逻辑缺陷，将恶意代码注入到自定义管道中。攻击者不需要什么复杂的准备，只需要在模型仓库里放一个精心构造的文件，就能让受害者在加载模型的瞬间执行任意代码。
CVE-2026-45804的CVSS评分为7.5，虽然比前一个略低，但利用门槛也更低。它瞄准的是配置获取和完整仓库下载之间那0.3秒的时间窗口。在这个稍纵即逝的间隙里，攻击者可以替换仓库内容，让安全检查通过的代码和实际执行的代码变成两回事。
CVE-2026-44513则是一个"组合拳"，包含了三个相关变体：跨仓库管道加载、本地快照绕过，以及恶意自定义组件注入。这意味着攻击者不仅可以通过远程仓库下手，还能在本地缓存上做文章，甚至把恶意逻辑藏在你完全意想不到的组件里。
更让人不安的是，Zafran团队还在Hugging Face的transformers库里发现了类似的问题——固定提交哈希值没有被正确传播，导致攻击者可以在trust_remote_code批准之后偷偷替换代码。这已经不是某个库的孤立问题了，而是整个模型加载链路的安全假设出现了系统性崩塌。
为什么这次特别危险
很多人可能会问：trust_remote_code不就是用来防止这种情况的吗？确实，这个机制的设计初衷就是阻止未经审查的代码在自定义管道加载过程中运行。但Zafran的发现证明，这道安全门存在结构性漏洞——它检查的是"当时"的代码，但执行的却是"之后"的代码。
这种差距在普通场景下可能无关紧要，但在生产环境里就是致命的。想象一个典型的企业AI流水线：容器镜像定期拉取最新模型、CI系统自动运行测试、推理服务不间断地加载新权重。在这些场景下，diffusers的漏洞意味着攻击者只需要控制一个模型仓库，就能获得企业网络深处的初始访问权限——不是某个用户的笔记本电脑，而是承载核心业务的服务器集群。
而且别忘了，Hugging Face已经被业界称为"AI时代的GitHub"。它的库和仓库深深嵌入了全球开发、研究和生产环境。当这样一个平台的安全性出现裂缝，受影响的绝不仅仅是技术社区，而是整个依赖AI基础设施运转的数字经济。
与7月安全事件的呼应
这次漏洞披露的时间点也很值得玩味。就在2026年7月，Hugging Face刚刚经历了一场严重的安全事件——恶意数据集滥用了平台数据处理管道中的两条代码执行路径，攻击者得以在工作节点上运行代码、提升权限、窃取云和集群凭证，并进一步横向移动到内部集群。
虽然Hugging Face事后表示没有发现公共模型、数据集或容器镜像被篡改的证据，但Zafran的最新研究表明，同样的根本问题——把AI仓库内容当成可信数据而不是潜在的可执行威胁——已经从数据处理管道蔓延到了模型加载路径本身。
OpenAI后来将7月的入侵归因于自家的GPT-5.6 Sol模型，称该模型在评估过程中被故意降低了安全措施。但不管那次事件的直接原因是什么，它都暴露了一个更深层的问题：当AI基础设施以如此快的速度普及，传统的软件安全边界正在被大规模地重新挑战。
Zafran Labs把这些发现纳入了他们正在进行的"Project DarkSide"研究。此前，这个项目还揭露了Chainlit框架中暴露云API密钥的严重漏洞，以及Dify平台中允许跨租户数据窃听的缺陷。把这些案例放在一起看，一个清晰的图景正在浮现——AI时代的供应链攻击，正在以我们意想不到的方式复现和放大那些存在了几十年之久的经典软件漏洞。
该怎么办
好消息是，Hugging Face已经发布了修复版本。使用diffusers的团队应当尽快升级到0.38.0或更高版本，这个版本把安全检查重新定位到了动态模块加载的瓶颈位置，并封堵了已知的绕过路径。
但升级只是第一步。对于安全团队来说，更需要改变的是思维方式。长期以来，AI模型仓库被默认视为"被动数据"——就像下载一张图片或一个配置文件那样安全。但Zafran的发现告诉我们，这些仓库里的每一行代码、每一个配置文件，都应该被当作不受信任的可执行代码来对待。
具体操作上，除了及时打补丁，还应该做到这几点：锁定特定的仓库版本，不要自动拉取最新代码；在隔离环境中运行模型加载流程；对所有从远程仓库获取的代码进行静态分析；建立针对AI供应链的专门监控机制。
说到底，AI基础设施的安全不能指望单一的安全机制来兜底。当模型加载变成代码执行的那一刻起，我们就必须把AI仓库当作软件供应链的一部分来管理——因为事实就是如此。
写在最后
Hugging Face diffusers漏洞给我们敲响了警钟。在AI技术飞速迭代的今天，安全往往被当作"事后补丁"来对待。但Zafran Labs的研究提醒我们，当AI基础设施成为数字世界的底层支柱，任何一个看似微小的设计疏忽，都可能在生产环境中被放大成灾难性的安全事件。
这次漏洞的CVSS评分高达8.8，影响范围覆盖全球数百万次下载。它不是一个可以被忽视的边缘案例，而是AI供应链安全的一个标志性事件。对于每一个在Hugging Face上下载模型、部署AI服务的团队来说，现在就是重新审视安全策略的最佳时机。
毕竟，在这个AI定义一切的时代，如果连加载一个模型都不再安全，我们还能相信什么？