Hugging Face 披露 7 月安全事件：自主 AI 智能体驱动的入侵

本周早些时候，我们检测到并响应了一起对我们部分生产基础设施的入侵。这次事件与我们以往处理过的任何事件在一个重要方面有所不同：它从头到尾由一个自主 AI 智能体系统驱动——而我们主要也是用自己的 AI 来检测和剖析它的。

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

发生了什么

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

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

我们做了什么

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

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

致我们的社区

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

我们感谢 Hugging Face 各团队全天候的响应，也对由此造成的任何中断表示歉意。安全永无止境；我们将继续提高标准。

分析一起 AI 驱动的入侵

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

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

我们可用于此分析的模型选择受到了我们未曾预料到的限制；我们将在下文描述这一点。

不对称问题

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

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

这意味着什么

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