全球开发者再熟悉不过的Hugging Face Transformers这个承载着超过100万个机器学习模型变体、在GitHub上斩获16.1万颗星的Python库最近被曝出一枚足以让攻击者悄无声息的远程代码执行漏洞。漏洞编号CVE-2026-4372影响范围从4.56.0版本一路追溯到去年8月之后的所有发行版每周仍有700万到800万次带毒下载约占整体安装量的四分之一。考虑到该库在PyPI上累计安装量已突破22亿次这枚漏洞的波及面堪称惊人。一个带下划线的参数竟成了绕过安全闸门的钥匙事情的核心出在模型配置文件里一个名叫_attn_implementation_internal的字段。在Hugging Face的生态里开发者加载远程模型时通常会设置trust_remote_codefalse本意就是防止模型附带的陌生Python代码在本地自动跑起来。这个开关在过去确实挡掉了不少麻烦但Pluto Security的研究团队发现攻击者只需要在config.json里塞入这个看似内部实现细节的参数整个防御机制就会形同虚设。为什么偏偏是它Transformers库在解析配置文件时用的是一套通用的键值对加载逻辑代码并不区分哪些是用户可以改的常规参数哪些是以_开头的内部属性。_attn_implementation_internal原本是用来控制注意力机制走Flash Attention、SDPA还是默认eager实现的属于库内部自己用的东西。可问题就在于这个值一旦被写成attacker-repo/malicious-kernel这样的格式Hub Kernels组件就会把它当成从内核中心拉取自定义编译模块的指令直接下载并执行。整个过程没有弹窗提示没有沙箱隔离没有代码签名校验甚至连条异常日志都懒得留下。攻击者只需要发布一个看起来挺有吸引力的模型等着用户用AutoModelForCausalLM.from_pretrained()加载恶意代码就会在导入__init__.py的瞬间执行——典型的供应链投毒只不过这次投的是AI模型这瓶特洛伊木马。GPU集群成了最肥的猎物有人可能会说利用这个漏洞需要目标机器上预先装好kernels这个额外依赖门槛不低吧现实恰恰相反。跑本地大模型的用户十个里有九个开着GPU加速而为了榨干显卡性能他们安装Transformers时往往会顺手勾选所有extras把可选依赖一股脑装上。企业级的机器学习平台和GPU集群更是如此运维团队通常倾向于全量安装生怕漏掉哪个包影响推理速度。Pluto Security在报告中直言不讳使用GPU加速推理的用户恰恰是最有价值的目标。这些环境往往托管着高价值的商业模型和敏感数据一旦失守损失远非个人开发者可比。攻击者看中的也正是这一点——企业ML平台的文件系统权限、网络访问能力、甚至主机凭证都可能随着一次看似平常的模型加载而被拱手送人。AI供应链投毒早已不是新鲜事这绝非孤立事件。就在上个月一个伪装成OpenAI隐私过滤器新版本的恶意仓库在Hugging Face平台上仅用18小时就冲上了热门榜首骗走了24.4万次下载代码里藏的是针对Windows的信息窃取木马。再往前数安全研究者已经演示过如何把恶意代码塞进Python Pickle文件——那种分发AI模型时常用的格式——以及如何通过篡改tokenizer.json实现远程代码执行。HiddenLayer的团队近期还披露了ChromaDB的类似漏洞攻击者无需认证就能诱使服务器执行Hugging Face托管模型配置中的恶意代码。一条清晰的攻击链条正在形成AI模型及其配套文件正逐渐取代传统软件包成为供应链攻击的新载体。三个设计失误叠加出的致命缺口回头来看CVE-2026-4372的诞生几乎是必然的。第一个失误是配置解析器缺乏过滤允许用户提供的配置覆盖内部属性第二个失误是_attn_implementation_internal这个内部字段被Hub Kernels模块直接消费没有额外的权限校验第三个失误则是内核加载器本身运行在裸环境上没有沙箱、没有签名验证、没有完整性检查。三个问题单独看或许都不算致命但叠在一起就构成了一条从下载模型到执行任意代码的完整通路。这种复合型的漏洞在大型开源项目中并不罕见。Transformers库为了兼容百万级别的模型变体不得不保持极高的灵活性而灵活性往往与安全边界此消彼长。当方便开发者成了最高优先级警惕恶意输入就容易被挤到后排。眼下能做什么Hugging Face已经在3月3日推送的5.3.0版本中悄悄修掉了这个问题但鉴于存在漏洞的版本仍在被大量下载升级是最紧迫的动作。如果你正在使用4.56.0或之后的版本应该尽快切到5.3.0以上同时翻一翻本地缓存和下载目录里的config.json看看有没有出现过_attn_implementation_internal这个字段以此判断是否已经被盯上过。更长远地看组织内部对待AI模型加载这件事不能再像安装一个普通Python包那样随意。思科AI研究团队最近开源的模型溯源工具包值得参考它通过比对模型权重、分词器和架构元数据中的指纹能识别出模型是否来自20多个可信发布者的45个已知基础模型家族。Pluto Security则建议把ML框架里的模型加载和配置反序列化接口一律视为代码执行面——无论界面上提供了多少安全开关。落实到操作层面模型加载应该被限制在受监控的容器环境里这些容器不能持有主机凭证不能随意访问外网更不能对文件系统大开绿灯。配置文件在喂给解析器之前先过一遍扫描特别留意那些以下划线开头的异常字段。对于企业GPU集群来说这些措施或许会增加一点运维复杂度但比起被恶意模型一锅端这点成本几乎可以忽略不计。
22亿次安装埋下的雷：Hugging Face Transformers库惊现高危RCE漏洞，AI供应链安全再遭拷问
全球开发者再熟悉不过的Hugging Face Transformers这个承载着超过100万个机器学习模型变体、在GitHub上斩获16.1万颗星的Python库最近被曝出一枚足以让攻击者悄无声息的远程代码执行漏洞。漏洞编号CVE-2026-4372影响范围从4.56.0版本一路追溯到去年8月之后的所有发行版每周仍有700万到800万次带毒下载约占整体安装量的四分之一。考虑到该库在PyPI上累计安装量已突破22亿次这枚漏洞的波及面堪称惊人。一个带下划线的参数竟成了绕过安全闸门的钥匙事情的核心出在模型配置文件里一个名叫_attn_implementation_internal的字段。在Hugging Face的生态里开发者加载远程模型时通常会设置trust_remote_codefalse本意就是防止模型附带的陌生Python代码在本地自动跑起来。这个开关在过去确实挡掉了不少麻烦但Pluto Security的研究团队发现攻击者只需要在config.json里塞入这个看似内部实现细节的参数整个防御机制就会形同虚设。为什么偏偏是它Transformers库在解析配置文件时用的是一套通用的键值对加载逻辑代码并不区分哪些是用户可以改的常规参数哪些是以_开头的内部属性。_attn_implementation_internal原本是用来控制注意力机制走Flash Attention、SDPA还是默认eager实现的属于库内部自己用的东西。可问题就在于这个值一旦被写成attacker-repo/malicious-kernel这样的格式Hub Kernels组件就会把它当成从内核中心拉取自定义编译模块的指令直接下载并执行。整个过程没有弹窗提示没有沙箱隔离没有代码签名校验甚至连条异常日志都懒得留下。攻击者只需要发布一个看起来挺有吸引力的模型等着用户用AutoModelForCausalLM.from_pretrained()加载恶意代码就会在导入__init__.py的瞬间执行——典型的供应链投毒只不过这次投的是AI模型这瓶特洛伊木马。GPU集群成了最肥的猎物有人可能会说利用这个漏洞需要目标机器上预先装好kernels这个额外依赖门槛不低吧现实恰恰相反。跑本地大模型的用户十个里有九个开着GPU加速而为了榨干显卡性能他们安装Transformers时往往会顺手勾选所有extras把可选依赖一股脑装上。企业级的机器学习平台和GPU集群更是如此运维团队通常倾向于全量安装生怕漏掉哪个包影响推理速度。Pluto Security在报告中直言不讳使用GPU加速推理的用户恰恰是最有价值的目标。这些环境往往托管着高价值的商业模型和敏感数据一旦失守损失远非个人开发者可比。攻击者看中的也正是这一点——企业ML平台的文件系统权限、网络访问能力、甚至主机凭证都可能随着一次看似平常的模型加载而被拱手送人。AI供应链投毒早已不是新鲜事这绝非孤立事件。就在上个月一个伪装成OpenAI隐私过滤器新版本的恶意仓库在Hugging Face平台上仅用18小时就冲上了热门榜首骗走了24.4万次下载代码里藏的是针对Windows的信息窃取木马。再往前数安全研究者已经演示过如何把恶意代码塞进Python Pickle文件——那种分发AI模型时常用的格式——以及如何通过篡改tokenizer.json实现远程代码执行。HiddenLayer的团队近期还披露了ChromaDB的类似漏洞攻击者无需认证就能诱使服务器执行Hugging Face托管模型配置中的恶意代码。一条清晰的攻击链条正在形成AI模型及其配套文件正逐渐取代传统软件包成为供应链攻击的新载体。三个设计失误叠加出的致命缺口回头来看CVE-2026-4372的诞生几乎是必然的。第一个失误是配置解析器缺乏过滤允许用户提供的配置覆盖内部属性第二个失误是_attn_implementation_internal这个内部字段被Hub Kernels模块直接消费没有额外的权限校验第三个失误则是内核加载器本身运行在裸环境上没有沙箱、没有签名验证、没有完整性检查。三个问题单独看或许都不算致命但叠在一起就构成了一条从下载模型到执行任意代码的完整通路。这种复合型的漏洞在大型开源项目中并不罕见。Transformers库为了兼容百万级别的模型变体不得不保持极高的灵活性而灵活性往往与安全边界此消彼长。当方便开发者成了最高优先级警惕恶意输入就容易被挤到后排。眼下能做什么Hugging Face已经在3月3日推送的5.3.0版本中悄悄修掉了这个问题但鉴于存在漏洞的版本仍在被大量下载升级是最紧迫的动作。如果你正在使用4.56.0或之后的版本应该尽快切到5.3.0以上同时翻一翻本地缓存和下载目录里的config.json看看有没有出现过_attn_implementation_internal这个字段以此判断是否已经被盯上过。更长远地看组织内部对待AI模型加载这件事不能再像安装一个普通Python包那样随意。思科AI研究团队最近开源的模型溯源工具包值得参考它通过比对模型权重、分词器和架构元数据中的指纹能识别出模型是否来自20多个可信发布者的45个已知基础模型家族。Pluto Security则建议把ML框架里的模型加载和配置反序列化接口一律视为代码执行面——无论界面上提供了多少安全开关。落实到操作层面模型加载应该被限制在受监控的容器环境里这些容器不能持有主机凭证不能随意访问外网更不能对文件系统大开绿灯。配置文件在喂给解析器之前先过一遍扫描特别留意那些以下划线开头的异常字段。对于企业GPU集群来说这些措施或许会增加一点运维复杂度但比起被恶意模型一锅端这点成本几乎可以忽略不计。
