Hugging Face 披露 2026 年 7 月生产基础设施遭自主智能体入侵

本周早些时候，我们检测并应对了针对部分生产基础设施的入侵。这次与我们以往处理过的任何事件都有一个重要不同：它从头到尾由自主 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 以保持同步。我们将持续在这方面投入，并持续分享我们的所学。