Hugging Face模型库的trust_remote_code安全缺陷

一个名为 trust_remote_code 的安全标志，刚刚被它本应防范的东西绕过了。如果这句话没有让你感到不安，那说明你还没有认真想过：你的团队在午饭前究竟会运行多少次 pip install 和 from_pretrained()。

这并不是什么新领域，只不过是老问题换上了更光鲜的 UI。自从 npm 和 PyPI 成为供应链攻击中的知名目标以来，软件包注册中心就一直在对抗通过依赖项植入恶意代码的问题。这里真正不同的是人们看待它的方式：Hugging Face 模型仓库看起来像是数据——一个 .safetensors 文件、一份配置、一些权重。开发者会下意识地把“下载模型”归类为“下载构件”，而不是“执行其他人编写的代码”。trust_remote_code 标志之所以存在，恰恰是因为 Diffusers（Transformers 也是如此）有时需要运行随模型一同提供的自定义 Python 代码。这是业界一次坦诚的尝试，意在提醒你：“嘿，接下来的操作存在风险，请明确选择加入。”但三个漏洞悄无声息地绕过了这层确认机制。

所以，这并不是一种全新的攻击类型。只是 AI 生态系统正在重新发现软件包管理器领域十年前就已经吸取的教训。不同之处在于，如今的构件是体积高达数 GB 的张量，而负责审查它们的是数据科学家，不是那些曾经被 postinstall 脚本坑过的后端工程师。

被夸大的部分是：有人认为这是一种新颖的、“AI 特有”的威胁，需要一套全新的安全范式。事实并非如此。这只是通过不受信任的输入实现任意代码执行，一个已有五十年历史的问题。把它称为“AI 供应链危机”，确实比“安全标志存在绕过漏洞”更适合做吸睛标题，但其底层机制熟悉得近乎乏味。

被低估的部分是：ML 社区在模型 Hub 周围建立了多么深厚的隐性信任。没有人会逐行审计一个 4GB 的 checkpoint 文件，也没有人会对权重做 diff。整个工作流就是“搜索 Hub，找到 benchmark 表现不错的模型，然后加载”。但在这样的日常习惯中，几乎还不存在与 npm audit 对等的环节。用于扫描模型仓库恶意代码的工具生态，成熟度远远不及传统依赖项的 SCA 工具。这个差距才是真正值得关注的问题，而不是具体有多少个 CVE。

谁会从“AI 特别危险”这种叙事中获益？坦率地说，所有想卖东西的人。厂商获得了一个可以推销产品的新市场，研究人员得到了媒体曝光，Hub 则可以在修复漏洞时展现自己的积极主动。这件事在 HN 上零互动同样说明了一些问题：它没能穿透噪声，而这本身也是一个数据点——即便底层漏洞确实非常严重，人们也已经对“AI 安全漏洞”类标题麻木到了什么程度。

如果你正在生产环境中从 Hugging Face 拉取模型，甚至只是在沙箱化的研究环境里这么做，那么 trust_remote_code=False 从来都不是什么神圣不可侵犯的安全保证，它只是一道减速带。对待模型加载时，你应该保持与安装陌生 npm 软件包时同等程度的警惕——尤其是当维护者在 GitHub 上只有三个 star 时。这意味着要使用沙箱；意味着不要直接在持有凭据或能够通过网络访问任何敏感资源的机器上加载任意社区模型；也意味着你的团队中必须有人真正负责模型来源，就像负责依赖项来源一样。

对整个行业而言，这件事是在提醒我们：必须彻底把模型 Hub 当作软件供应链来看待。签名、来源证明、可复现构建，以及软件行业在经历了足够多事故之后，花了二十年才勉强建立起来的整套工具箱，一个都不能少。AI 工具生态正在尝试压缩这段时间，这是好事；但只有从业者不再把“它只是权重”当作一种安全属性，这种时间压缩才会真正奏效。

如果无论如何配置 trust 标志，加载模型都可能执行代码，那么到了什么时候，“下载并运行”会变成 ML 生态系统必须彻底抛弃的反模式——就像大多数理智的工程组织多年前就已经放弃 curl | bash 一样？

Hugging Face Diffusers 漏洞可能允许模型仓库执行任意代码

如需采取进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。