Hugging Face 披露 7 月安全事件：自主 AI 智能体入侵生产基础设施

本周早些时候，我们检测到生产基础设施的一部分遭到入侵并做出了响应。这一次与我们此前处理过的任何情况都有一个重要区别：它从头到尾由一个自主 AI 代理系统驱动——而我们主要也是用自己的 AI 来检测和剖析它的。

我们发现了对一组有限的内部数据集以及我们服务所使用的若干凭据的未授权访问。我们仍在完成对任何合作伙伴或客户数据是否受到影响的评估，并将按要求直接联系任何受影响方。我们未发现任何证据表明面向公众、用户可见的模型、数据集或 Spaces 遭到篡改，我们的软件供应链（容器镜像和已发布软件包）也经核实完好无损。

发生了什么

入侵始于 AI 平台独有的暴露面：数据处理流水线。一个恶意数据集滥用了我们数据集处理中的两条代码执行路径（一个远程代码数据集加载器和一个数据集配置中的模板注入），从而在处理工作节点上运行代码。攻击者由此升级到节点级访问权限，收集云和集群凭据，并在一个周末内横向移动到多个内部集群。

此次攻击活动由一个自主代理框架运行（似乎构建在一个代理式安全研究测试框架之上——所使用的 LLM 仍未知），在一群短生命周期沙箱中执行了数千次单独操作，并在公共服务上部署了可自我迁移的命令与控制。这与业界一直预测的“代理式攻击者”场景相符。

我们做了什么

• 修复了根本漏洞：用于初始访问的数据集代码执行路径已被关闭。
• 清除了攻击者在受影响集群中的据点，并重建了被入侵的节点。
• 撤销并轮换了受影响的凭据和令牌，并开始对机密进行更广泛的预防性轮换。
• 在我们的集群上部署了额外的防护措施和更严格的准入控制。
• 改进了我们的检测和告警机制，使高严重性信号能在几分钟内呼叫响应人员，无论一周中的哪一天。

我们正在与外部网络安全取证专家合作调查此问题，并审查我们的安全政策和流程。最后，我们已就此事件向执法机构报告。

致我们的社区

作为预防措施，我们建议轮换任何访问令牌，并查看您账户上的近期活动。如果您认为自己受到影响，或想报告安全问题，请通过 [email protected] 联系我们。

我们感谢 HF Mirror 各个团队夜以继日的响应，也对由此造成的任何中断深表歉意。安全永远没有终点；我们将继续提高标准。

分析一次 AI 驱动的入侵

此次攻击最初是通过 AI 辅助检测发现的。我们的异常检测流水线使用基于 LLM 的研判来处理安全遥测数据，以将真实信号与日常噪声区分开来，正是这些信号的关联标记出了此次入侵。

为了理解由数万个自动化操作组成的集群究竟做了什么，我们在完整的攻击者操作日志上运行了由 LLM 驱动的分析代理，该日志包含超过 17,000 条记录事件。这使我们得以重建时间线、提取入侵指标、梳理被触及的凭据，并将真实影响与诱饵活动区分开来。得益于这种方法，我们能在数小时内完成通常需要数天的工作，并跟上对手的速度。

可用于此次分析的模型选择受到了我们未曾预料到的限制；我们将在下文对此进行说明。

不对称性问题

当我们开始日志分析时，最初使用的是商业 API 背后的前沿模型。但这行不通：分析需要提交大量真实攻击命令、漏洞利用载荷和 C2 制品，而这些请求被提供方的安全护栏拦截，这些护栏无法区分事件响应人员与攻击者。于是，我们转而在自己的基础设施上，使用开放权重模型 zai-org/GLM-5.2 进行取证分析。这带来了第二个好处：没有任何攻击者数据，也没有其引用的任何凭据，离开我们的环境。

这一经历指向了一个值得提前规划的缺口。我们不知道攻击者的代理由哪个模型驱动，是被越狱的托管模型，还是不受限制的开放权重模型；无论如何，攻击者不受任何使用政策约束，而我们自己的取证工作却被我们最初尝试的托管模型的护栏所阻断。对防御者的实际教训是：在事件发生之前，就要准备好一个可在自有基础设施上运行的能力足够的模型，既要避免被护栏锁死，也要防止攻击者数据和凭据离开你的环境。这并非反对托管模型上的安全措施，我们正在将这一反馈分享给相关提供方。

这意味着什么

自主的、AI 驱动的攻击工具已不再是理论。它降低了发动一场范围广泛、耐心十足、多阶段战役的成本，并以机器速度运行。如今，防御一个在线平台意味着要将数据和模型面视为一等攻击面，并在防御侧使用 AI 以跟上节奏。我们将继续在那里投入，并持续分享我们的所学。