攻击是从一个数据集进来的

起点是 AI 平台特有的一个薄弱面：数据处理管线。一个恶意数据集利用了数据集处理环节的两个代码执行路径，在处理任务的机器上把代码跑了起来。之后的每一步都是常规的内网渗透打法。

两个入口的原理不一样，放在一起看更清楚。

这里有一处对照值得看。Hugging Face 发给所有人用的那个 datasets 库，2025 年 7 月的 4.0.0 版本已经把脚本式数据集整个删掉了，trust_remote_code 这个开关同步作废，官方给的迁移路径是转成 Parquet 这类纯数据格式。也就是说，装了新版库的普通用户早就走不了「加载数据集顺带执行脚本」这条路，而平台自己后台的处理管线里，这类代码执行路径这次还是被用上了。用于初始接入的这两条路径现在已经关闭。

需要说清楚的是，通报没有讲后台管线跑的是不是同一个 datasets 库，也没说被利用的就是 4.0.0 封掉的那条路径。上面这层对照是把两边的公开事实摆在一起，不是通报给的结论。

打进来的是一套自动跑的 Agent 框架

攻击方长这样。它是一套能自己一步步往下打的程序，看上去是拿现成的自动化渗透测试工具改的，这类工具本来是给红队和漏洞研究用的。它的上万次动作不在一台机器上做，而是散在一大堆临时开的机器里，每台做完几步就销毁。它跟背后操控者之间的联络线路藏在公共服务里，而且会自己换地方。用的是哪个模型，至今不明。

那个「拿现成工具改的」说法里，业内管这层现成工具叫 harness，就是包在模型外面的一套调度脚手架：喂它材料、决定它能看到什么、解析它吐出来的东西、再驱动它一轮轮循环下去。模型是发动机，harness 是底盘和方向盘，同一台发动机装在不同底盘上，跑出来的成绩能差一大截。

这两个设计冲着同一件事去：让你没法一刀切断。临时机器本来就是用完就扔的，你封掉一个也没用。线路混在正常流量里还会搬家，拉黑固定地址根本堵不住。

还有一层影响落在取证上。机器用完就销毁，磁盘镜像、内存快照这类现场证据也跟着没了，能拿来复盘的主要就剩那份动作日志。所以后面那 17000 多条事件，是整场攻击最完整的一份记录（这层关联是本站推演，通报没有明说）。

上一次公开的 AI 驱动攻击是什么样

这正是业界预警了很久的那种「会自己往下打的攻击者」。上一次被详细公开的同类案例，是 Anthropic 威胁情报团队披露的 GTG-1002，2025 年 9 月中旬检测到。两次的自动化程度不一样。下表是站外补充资料。

Hugging Face 是怎么查清这次入侵的

防守侧的 AI 用在两个地方，一处负责发现，一处负责重建。

发现这一头，他们有一套 AI 值班程序，天天盯着系统自己吐出来的运行记录，把真信号从日常噪音里挑出来。最后是几条信号关联到一起，才让这次入侵浮出水面。

分析 Agent 从 17000 多条事件里理出了一条时间线

要搞清楚上万次自动动作到底干了什么，Hugging Face 让分析 Agent 去跑完整的攻击者动作日志，一共 17000 多条事件。跑完一轮，同时拿到了四样东西。

最后一项是这次工作量的关键：攻击方混了诱饵动作进去，把真实影响和干扰动作分开，本身就是人力最耗时的部分。而投诱饵这件事对人和对机器的成本完全不同，人类攻击者每多放一条假动作都要自己花时间，自动跑的 Agent 多放多少条，边际成本都接近于零（成本这一层是本站推演，通报只写了存在诱饵动作）。

用 AI 跑完之后，原本要几天的活压到了几小时，速度跟得上对手。

取证时商业模型为什么拒绝处理

这次事故里真正卡住 Hugging Face 的，是他们自己付费在用的模型。通报的原话是，能用哪些模型做这次分析，受限的方式「是我们没有预料到的」。

刚开始做日志分析时，Hugging Face 用的是商业接口上最强的那几个模型。跑不通。这种分析要往模型里灌的，正是大量真实攻击命令、用来打进来的攻击代码，还有联络线路留下的产物。安全护栏看到这些东西就拦，而它分不出提交的人是应急响应工程师还是攻击者本人。

他们把模型搬到自己的基础设施上跑，绕开了这道护栏

Hugging Face 最后把取证分析换到了 GLM 5.2 上，跑在自己的基础设施里。这是 Zhipu AI（Z.ai）做的一个开放权重模型，权重以 MIT 许可发布，可以下载下来自己部署，不存在谁来批准你能不能提交这段材料的问题。训练数据和完整管线没有公开，所以它是开放权重，不是开源。

换到自己的机器上跑，除了不会被护栏拦住，还有第二个好处，Hugging Face 单独提了一句：攻击者数据和它引用到的那些凭证，一步都没有离开过自家网络。事故取证时，把带凭证的日志往外部接口送，本身就是一次新的暴露。

这不是在反对托管模型上的安全措施，我们也正在把这个反馈同步给相关的服务商。 Hugging Face 安全事故通报

换成开放权重的模型，安全分析会掉一档吗

站外有一份独立基准可以参考。Semgrep 用同一套 IDOR 越权漏洞数据集和同一条提示词测了一圈配置，GLM 5.2 在没有任何专用脚手架、只给一段提示词的条件下拿到 39% 的 F1 分（F1 是精确率和召回率合起来的综合分：找出来的有多少是真的，真的又被找出来多少，满分 100%，越高越好），赢过了跑在自家 Agent 脚手架里的 Claude Code。

所以给防守方的建议就一条：在事故发生之前，就选好并验证过一个能在自己基础设施上跑的模型，既避免被护栏卡住，也避免攻击者数据和凭证外流。

Hugging Face 补了哪些洞，用户要做什么

事后一共做了五件事。

• 补掉根因漏洞：用于初始接入的那两条数据集代码执行路径已经关闭。
• 清除攻击者在受影响集群里的据点，并重建被攻陷的机器。
• 吊销并轮换受影响的凭证和令牌，同时启动了一轮更大范围的预防性密钥轮换。
• 在集群上加了额外的防护措施和更严格的准入控制。
• 改进检测和告警，让高危信号在几分钟内就把值班的人叫醒，周末也一样。

另外，他们请了外部网络安全取证团队介入调查、复核安全策略和流程，并且已经把这次事件报给了执法机关。

给用户和防守方的动作，整理成清单如下。前三条是给普通用户的，后两条是给企业安全团队的。

最后落到几句判断上。会自己往下打的 AI 攻击工具，已经不是设想了。以前要发动一场覆盖面大、周期长、分好几个阶段的攻击，成本很高，现在这个成本被压了下来，而且整件事跑在机器的速度上。对在线平台来说，用户传上来的数据集、模型文件这些东西，过去主要当成待处理的内容，现在得当成可能带毒的输入来防。而防守这边，人工盯日志的速度已经跟不上机器，也得把 AI 用起来。

7 月 16 日 Hugging Face 发通报：同一周稍早，对外提供服务的那套内部系统被入侵了一部分。以前这种活儿要一个人守着键盘一步步敲，这次从头到尾没人动手，是一套 AI 程序自己往下打完的。

攻击链走了五步：传一个带毒数据集 → 在处理它的机器上跑起代码 → 把权限抬到整台机器 → 抓走云和集群的凭证（也就是通往其他机器的钥匙）→ 拿着钥匙横向摸进好几个内部集群。第三步到第五步，全程发生在一个周末。

已确认被碰的是一部分内部数据集和若干服务凭证；公开的模型、数据集、Spaces 没找到被改动的证据。真正的麻烦出在下一步，Hugging Face 要查这 17000 多条日志的时候。

要查清攻击者干了什么，就得把他敲过的真实命令、打进来用的攻击代码，整段喂给模型去读。而商业模型的安全护栏看到这些东西就拦，它分不出提交的人是来救火的工程师，还是攻击者本人。

17000 多条动作事件，人一条条捋要几天，AI 跑一轮几小时。而且这不是简单读一遍：攻击方还混了假动作进去，把真实影响和干扰动作分开，本来就是人力最耗时的部分。

换开源模型也不等于将就。Semgrep 2026 年 7 月做的越权漏洞检测基准里，GLM 5.2 只给一段提示词就拿到 39 分，高于跑在自家脚手架里的 Claude Code（32 分），不过那是单一任务、单次运行的结果，不是这次事故的数据。