Hugging Face 被 AI 智能体打进生产集群，又用 GLM-5.2 连夜反查：Agent 攻防第一次撞在同一现场

来源：Hugging Face 官方事故披露 / The Decoder 日期：2026-07-16 披露，2026-07-20 进入今日精选

• 官方披露：https://huggingface.co/blog/security-incident-july-2026
• 补充报道：https://the-decoder.com/hugging-face-says-an-ai-agent-hacked-its-infrastructure-and-it-used-ai-to-fight-back

Hugging Face 本周确认，部分生产基础设施遭到入侵。入口是一份恶意数据集，攻击者利用数据处理链里的两条代码执行路径进入 worker，随后拿到节点级权限，搜集云端与集群凭证，并在周末横向移动到数个内部集群。

这起事故麻烦的地方，不只是“AI 平台被黑”。Hugging Face 根据动作模式判断，整场攻击由自主智能体框架端到端编排：短命沙箱组成的群体执行了数万次动作，命令与控制节点会在公共服务之间自行迁移。攻击用的具体模型仍然未知，可能是越狱的托管模型，也可能是无限制的开源权重模型。公司没有给出可独立验证的归因证据，因此“完全自主”目前仍属于 Hugging Face 的事故判断，不该写成司法意义上的定论。

周末发生了什么

初始漏洞在数据处理面。一条远程代码数据集加载路径，加上一处数据集配置模板注入，让上传的数据不再只是数据，而能在处理节点上执行代码。攻击者随后拿到云和集群凭证，跨多个内部集群移动。

确认受到影响的是一部分内部数据集，以及若干 Hugging Face 服务凭证。公开模型、公开数据集、Spaces、容器镜像和已发布软件包没有发现被篡改，软件供应链被核验为干净。合作伙伴或客户数据是否受影响仍在调查，公司承诺如确认会直接通知相关方。

这条边界很重要。现在能说的是“生产基础设施受侵入，内部资产与凭证受影响”，不能扩大成“整个 Hugging Face 模型仓库遭投毒”。

Hugging Face 已关闭两条初始代码执行路径，清除攻击者落点并重建受影响节点，吊销和轮换凭证，收紧集群准入控制，还把高危告警改成全天候数分钟内通知响应人员。公司同时引入外部取证团队，并向执法机构报告。对普通用户，它给出的建议是轮换 access token、检查近期账户活动。

17,000 条动作，人工取证会被拖垮

攻击日志记录了超过 17,000 个事件。Hugging Face 的安全团队让 LLM 分析代理重建时间线、提取入侵指标、映射触达过的凭证，并把真实破坏与诱饵动作分开。官方说，通常需要数天的工作被压到数小时。

这不是让模型自己宣布“查完了”。合理的用法更像批量阅读员：模型先在海量命令、遥测和凭证关系中归并线索，人类再复核高风险判断。官方披露没有给出误报率、漏报率或人工复核工时，所谓“数小时”仍是公司自报，值得参考，不能当成通用 benchmark。

还有一段很有意思。团队最初把真实攻击命令、漏洞载荷和 C2 痕迹交给商业 API 分析，安全护栏把请求拦了，因为模型无法区分防守方和攻击者。最后他们在自有基础设施上运行开源权重 GLM 5.2，既绕开误拦，也让攻击数据与凭证不离开内部环境。

Hugging Face 当然有推广开源模型的商业立场。即便如此，这个场景很难反驳：事故现场不能临时申请“请相信我是好人”的白名单。安全团队需要一套预先验证、能离线运行、日志不出域的模型，而不是出事后才发现供应商的内容策略不允许你分析真实攻击。

回到 AI coding 团队，这起事故的提醒很直接。

数据集、模型权重、代码仓库正在变成同一类攻击面。Coding Agent 会自动拉依赖、执行测试、处理 issue、读取环境变量；它接触的任何“内容”都有机会变成指令或代码路径。传统做法把仓库看成可信输入，把上传数据看成被动对象，这个假设已经不成立。

更棘手的是速度不对称。攻击智能体可以不停试错、换节点、拆任务；防守方若仍靠人逐行读 17,000 个事件，周一开工时对方早走了。Hugging Face 这次用 AI 把取证压到小时级，至少证明防守端不能继续只靠人工队列。

后面要等三项信息：外部取证能否确认“自主智能体”的归因，伙伴或客户数据是否实际泄露，以及这些恶意数据处理路径过去是否已被其他攻击者利用。现在下结论还早。

但有一点已经落地：Agent 安全不再只是“模型会不会误删文件”。攻击者也在用代理，而且速度、耐心与使用政策都不对称。以后每个能自动执行代码的 AI 平台，都得同时准备两支队伍——一支跑业务，一支盯着前一支和外面那支。