Transformers 配置注入：绕过 trust_remote_code 的静默 RCE

这是什么？

CVE-2026-4372 是 Hugging Face transformers 库中的一个远程代码执行（RCE）漏洞，由 Pluto Security 的 Yotam Perkal 于 2026 年 6 月 4 日公开披露，CSO Online 当天同步报道。它能在任何人通过普通的 from_pretrained() 调用加载被投毒模型时执行任意 Python 代码——而受害者从未设置 trust_remote_code=True。

触发条件是模型 config.json 中的一个字段。没有任何警告、没有同意提示、也没有异常日志：代码在 from_pretrained() 返回之前就已在库内部执行。NVD 于 2026 年 5 月 24 日发布该 CVE，CVSS 3.0 基础评分 7.8（高危），归类为 CWE-1066。Pluto 的博客指出，他们最初按严重级别提交；Hugging Face 将评分下调，因为利用前提依赖一个可选软件包的存在。

工作原理

该漏洞源于三个相互独立的设计决策的交汇，单独看每一个都不危险。Pluto 追踪了完整链条，CSO Online 通过维护者的修复予以印证。

首先，当 transformers 解析下载的 config.json 时，configuration_utils.py 中的一个通用循环通过 setattr 将每一个键值对直接写入配置对象，既无允许清单，也不区分公共参数与以下划线为前缀的私有内部属性：

# configuration_utils.py —— 不可信 JSON 直接写入对象属性
for key, value in kwargs.items():
    setattr(self, key, value)   # 无 allowlist，无校验

其次，这些内部属性之一 _attn_implementation_internal 控制模型使用哪种注意力内核。自 transformers v4.50.0（“Hub Kernels” 功能）起，形如 owner/repo 的取值会被当作 Hub 上可下载内核包的引用。hub_kernels.py 中的分派路径接受任意 owner/repo 字符串并将其导入：

# hub_kernels.py（简化）—— 任意 owner/repo 字符串都会被下载并导入
def is_kernel(attn_implementation):
    return re.search(r"^[^/:]+/[^/:]+...$", attn_implementation) is not None
# -> get_kernel() -> 从 Hub 下载该包 -> 通过 importlib 导入

第三，该导入未被沙箱隔离：没有代码签名、没有完整性校验、没有提示。导入一个 Python 包会执行其 __init__.py。因此攻击者发布一个外观正常的模型，其 config.json 多出一行：

{
  "model_type": "llama",
  "architectures": ["LlamaForCausalLM"],
  "_attn_implementation_internal": "attacker-acct/optimized-attn-kernel"
}

当受害者执行 AutoModelForCausalLM.from_pretrained("attacker-acct/finance-llama-7b") 时，库会下载并导入攻击者的包，以用户权限执行其 __init__.py 中的内容。该包中的占位函数让模型加载正常完成，一切看起来毫无异常。

关键在于：trust_remote_code=False 这一默认值从未发挥作用——库自身的净化逻辑覆盖了公共字段 attn_implementation，并在写入路径上剥离 _attn_implementation_internal，却从未在来自不可信 JSON 的读取路径上对其过滤。前门已锁，后门大开。

为何重要

transformers 是全球安装量最大的 Python 包之一：据 Pluto，PyPI 累计安装超过 22 亿次，每月下载约 1.46 亿次。漏洞路径在 **v4.56.0（2025 年 8 月 29 日）**引入，在 **v5.3.0（2026 年 3 月 4 日）**移除——约 187 天的暴露窗口内，Pluto 测得易受攻击版本（4.56.0–5.2.x）的下载量约为 2.32 亿次。

利用需要安装可选的 kernels 包——这是一个真实但具有迷惑性的限制因素。kernels 随 transformers[all]、Hugging Face 官方参考 Dockerfile 以及大多数 GPU 加速推理环境一起安装。正如 Pluto 所言，安装了它的人恰恰是高价值目标：企业 ML 平台、自动调用 from_pretrained() 的 CI/CD 流水线，以及持有云凭据、训练数据和模型工件的 GPU 集群。一次被攻陷的模型加载就可能泄露 AWS 密钥、SSH 密钥、.env 机密和 Kubernetes 配置，进而横向移动。

这并非空谈。CSO Online 指出，一个冒充 OpenAI “Privacy Filter” 模型的恶意仓库曾在 18 小时内冲上 Hub 趋势榜首、获得 24.4 万次下载后才被下架——而那次攻击仍需受害者手动运行脚本。CVE-2026-4372 连这一步都省去了。它与 CVE-2025-32434（2025 年 4 月）相呼应——PyTorch torch.load 在 weights_only=True 下仍可 RCE 的缺陷，同一类型的 bug：一个文档化的”安全”模式，通过该标志未覆盖的相邻路径泄露了代码执行原语。

第二个教训关乎可见性，而非修复速度。Hugging Face 修复很快（从报告到 v5.3.0 仅 10 天），但补丁只是常规发布说明中一行”安全漏洞”的措辞；CVE 直到 81 天后才登上 NVD。根据 Pluto 的遥测，补丁发布数月后，易受攻击版本每周仍被下载 700 万至 800 万次——约占每周安装量的四分之一。没有足够响亮公告的补丁，无法保护那些从不知道自己需要打补丁的防御者。

防御

如果你使用 transformers，立即升级到 v5.3.0 或更高版本，并检查是否有被锁定的环境仍停留在 4.56.0–5.2.x。Pluto 和 CSO 都确认易受攻击版本仍被大量下载。

审计你的配置。 在任何缓存或下载的 config.json 中搜索 _attn_implementation_internal（以及修复后的 _experts_implementation_internal）。它们出现在来自 Hub 的配置中即为危险信号。更广义地说，在加载前拒绝携带意外的下划线前缀字段的配置。

无论”安全”标志如何，都将模型加载视为代码执行面。 这是经久不衰的要点。在隔离且受监控的容器中运行 from_pretrained()（以及 torch.load()），不附带主机凭据、不开放出站网络、文件系统权限最小化。不要让一个加载不可信模型的进程同时持有生产机密。

核验来源。 优先选择已知发布者的模型；对于未知模型，可借助 Cisco 开源的 Model Provenance Kit 等工具，用权重、分词器与架构元数据的指纹比对已知基础模型家族。

v5.3.0 的修复本身即纵深防御：它在 setattr 循环中将 _attn_implementation_internal 和 _experts_implementation_internal 列入黑名单（PR #44395），并对官方 kernels-community 组织之外的任何内核仓库要求 trust_remote_code=True。正如 Pluto 所言，黑名单的价值取决于开发者的预见能力——对允许的配置字段采用白名单才是更稳健的长期设计。

状态

项目	详情
CVE	CVE-2026-4372（CWE-1066），CVSS 3.0 基础评分 7.8（高危，NVD）
受影响	transformers 4.56.0 – 5.2.x，且安装了可选的 kernels 包
引入版本	v4.56.0，2025-08-29（Hub Kernels 分派重构）
修复版本	v5.3.0，2026-03-04（PR #44395）
报告 / 披露	huntr 报告 2026-02-23；NVD 发布 2026-05-24；公开分析 2026-06-04
发现者	Yotam Perkal, Pluto Security
处置	升级至 ≥ 5.3.0；审计配置；隔离模型加载