Hugging Face Transformers漏洞：未经同意写入文件

美国CERT协调中心（CERT/CC）于2026年9月1日发布安全公告，披露了全球使用最广泛的Python库Hugging Face Transformers中的一个漏洞，该库用于加载和运行人工智能模型。该漏洞编号为CVE-2026-80047，影响该库4.49.0至5.8.1版本。日本漏洞信息门户JVN（Japan Vulnerability Notes）当天也发布了相同信息，最早由日本媒体INTERNET Watch报道。截至发稿，Hugging Face尚未发布补丁或官方声明。

Hugging Face Transformers是Hugging Face平台提供的Python库，用于加载预训练的人工智能模型——涵盖自然语言处理、计算机视觉、音频、视频及多模态系统——并执行推理或再训练。CERT/CC将其描述为同类框架中应用最广泛的之一，在全球的研究与生产环境中都被大量使用。

问都没问，文件已经写入

该漏洞出在函数GenerativePreTrainedModel.load_custom_generate()中，它允许模型仓库提供自定义的生成逻辑。这个函数通过get_cached_module_file()获取远程模块，并将其写入用户本地缓存目录~/.cache/huggingface/modules——而这一步发生在库通过resolve_trust_remote_code()评估用户同意（即trust_remote_code机制，本应用于阻止未经批准的代码执行）之前。CERT/CC指出，如果用户拒绝，代码本身的执行确实会被正确阻止；但最初的磁盘写入却是无条件发生的。根本原因在于dynamic_module_utils.py中一处无条件的文件复制操作，这与库中其他动态加载路径的行为不同——AutoConfig、AutoModel、AutoTokenizer和AutoImageProcessor在获取或写入任何内容之前，都会先验证用户同意。

• 即便用户在信任提示中选择拒绝执行，文件依然会保留在本地缓存中
• 恶意模型仓库的作者可以在custom_generate/generate.py中放入任意Python代码
• 只要尝试加载该模型就会触发写入，无需特殊权限，也无需用户任何额外操作
• 在缓存被重复使用的环境中，先前写入的恶意文件可能在之后一次被视为可信的模型加载中被意外执行

补丁尚未发布，只有临时应对建议

该漏洞由安全研究员Prasanna Dabi报告。CERT/CC表示已于2026年8月4日通知Hugging Face；截至公告发布的9月1日，该公司仍未作出任何回应，其在记录中的供应商状态被标注为“Unknown”。在补丁发布之前，CERT/CC和JVN均建议：避免在不可信的模型仓库上调用load_custom_generate()，并定期检查~/.cache/huggingface/modules目录，删除任何意料之外的文件。

CERT/CC还指出，初始文件复制一旦发生便无法撤销：如果用户拒绝，trust_remote_code机制确实会正确阻止代码执行，但已经写入磁盘的文件不会因此被删除。该公告还提出了一项更普遍的设计原则性建议：任何类似trust_remote_code的检查都应在获取或写入任何远程内容之前进行——而目前出问题的函数并未满足这一要求。该库的源代码在GitHub上公开，huggingface/transformers代码仓库目前仍是追踪修复进展的唯一官方渠道。

该公告将此次发现归功于安全研究员Prasanna Dabi，并注明由CERT/CC分析师Bob Kemerer撰写。从8月4日私下通知Hugging Face，到9月1日公告正式发布，中间不到一个月——根据CERT/CC的协调披露时间线，该公司在此期间始终没有做出回应。

CERT/CC隶属于卡内基梅隆大学软件工程研究所（Software Engineering Institute），并由美国网络安全和基础设施安全局（CISA）提供支持。

模块的执行本身被正确阻止，但文件的初始写入却是无条件的——这与库中其他动态模块加载路径的行为不同。

这对中国的AI开发团队意味着什么

对于任何基于Hugging Face Transformers搭建AI流水线的中国团队——无论是初创公司、大型互联网企业还是高校实验室——这一漏洞都是一项需要立即排查的事项，而不是可以忽略的又一条安全通告。建议先在代码库和CI/CD流水线中定位所有load_custom_generate()的调用，确认它们均未指向未经审核的模型仓库，再检查开发机和构建服务器上的~/.cache/huggingface/modules目录，排查是否存在来路不明的Python文件。在官方补丁发布之前，将生产环境中使用的库版本固定下来，并制定缓存目录的定期核查流程，是目前最可靠的应对方式。