Hugging Face称AI代理入侵其基础设施
The Decoder··作者 Matthias Bastian
关键信息
Hugging Face表示，攻击始于一个恶意数据集，它利用了数据集处理中的两条代码执行路径：远程代码数据集加载器和数据集配置中的模板注入。公司称公共模型、数据集和 Spaces 未被篡改，但任何合作方或客户数据是否受影响仍在调查中。
资讯摘要
Hugging Face披露，其部分生产基础设施遭到入侵，并表示这次入侵很可能是由一个自主AI代理系统实施的。公司称，攻击者以一个恶意数据集为入口，并利用数据集处理中的代码执行路径获得了访问权限。随后，入侵者把权限提升到节点级别，窃取云和集群凭证，并在一个周末内横向移动到多个内部集群。Hugging Face说，这次行动通过大量短生命周期沙箱执行了成千上万次操作，并使用了运行在公共服务上的自迁移命令与控制基础设施。公司还表示，它并不知道攻击者使用了哪一个语言模型。此次泄露涉及一小部分内部数据集和若干服务凭证，但公共模型、数据集和 Spaces 未被篡改，也没有发现软件供应链受到影响。至于是否有合作方或客户数据被泄露，目前仍在调查中。
防守方面，Hugging Face表示，自己是通过一个AI驱动的异常检测流水线发现这起事件的，该流水线会对安全遥测进行基于LLM的初步分流。为了分析超过17,000次记录在案的攻击者动作，公司部署了LLM驱动的分析代理，用来重建时间线、提取入侵指标、映射受影响的凭证，并区分真实破坏与迷惑性活动。公司称，原本需要几天的工作最终在几小时内完成。Hugging Face还表示，最初尝试用商业前沿模型分析日志时遇到了阻碍，因为这些模型的安全护栏会把事件响应请求当成潜在恶意行为，进而阻止提交大量真实攻击命令、漏洞载荷和C2工件。后来团队改用在自有基础设施上运行的开源权重模型 GLM 5.2，从而避免攻击数据离开本地环境。公司给防守者的实际建议是，在事故发生前就准备好可以在本地环境运行的强大模型。
资讯正文
Hugging Face 表示，一个 AI 代理入侵了其基础设施，而它也用 AI 进行了反击
要点
- 流行的 AI 平台 Hugging Face 遭到了一次网络攻击，据称这次攻击完全是由一个自治 AI 代理系统实施的。
- 攻击者以一个恶意数据集作为切入点，从而得以入侵内部数据并窃取平台的登录凭证。
- 为了分析攻击者记录下来的超过 17,000 个操作，Hugging Face 部署了自己的 AI 工具，在短短几个小时内就完成了完整的取证分析，而不是通常需要的几天。
AI 平台 Hugging Face 透露，其部分生产基础设施遭到入侵，据称这次入侵完全是由一个自治 AI 代理系统实施的。该公司表示，自己主要依靠内部的 AI 工具检测并分析了这次攻击。
据 Hugging Face 称，攻击者未经授权访问了一小部分内部数据集，以及 Hugging Face 服务使用的若干凭证。该公司表示，公开模型、数据集和 Spaces 并未被篡改，软件供应链也未受到影响。合作伙伴或客户数据是否遭到泄露，目前仍在调查中。
恶意数据集打开了大门
据 Hugging Face 称，这次攻击始于任何 AI 平台上最脆弱的环节之一：数据处理管道。一个恶意数据集利用了数据集处理中的两条代码执行路径，具体包括远程代码数据集加载器以及数据集配置中的模板注入。
从那里起，攻击者将权限提升到了节点级别，获取了云和集群凭证，并在一个周末期间横向移动到多个内部集群。该公司表示，这一整个行动由一个建立在 agentic security research harness 之上的自治代理框架进行协调。
Hugging Face 表示，他们不知道这次攻击使用了哪一种语言模型。该系统通过一组短生命周期的沙箱执行了数以千计的单独操作，并使用运行在公共服务上的、可自我迁移的命令与控制基础设施。公司将这一事件归类为业内已经预期了一段时间的“agentic attacker”场景。
AI 驱动的分析将调查时间从几天缩短到几小时
Hugging Face 表示，它是通过一个由 AI 驱动的异常检测管道发现这次攻击的，该管道会对安全遥测数据进行基于 LLM 的分诊。为了理解超过 17,000 个被记录下来的攻击者操作，公司部署了由 LLM 驱动的分析代理。
这些代理重建了时间线，提取了入侵指标，绘制了受影响的凭证图谱，并将真实损害与欺骗性活动区分开来。公司表示，通常需要几天才能完成的工作，这次只用了几个小时。
商业 AI 安全过滤器阻止了该公司的自我防御
据 Hugging Face 介绍，当安全团队最初尝试使用商业 API 背后的前沿模型分析攻击日志时，遇到了障碍。由于这些提供商的安全护栏无法分辨事件响应人员和攻击者，相关请求被拦截。要进行分析，需要提交大量真实的攻击命令、漏洞利用载荷和 C2 工件，而这些内容都会触发过滤器。
该公司随后转向在自有基础设施上运行的开源权重模型 GLM 5.2。公司表示，这样有两个好处：不会接触攻击者数据，而且文中提到的凭证也从未离开过其自身环境。
“Hugging Face 写道：‘我们不知道为攻击者的代理提供动力的是哪一个模型，无论是被越狱的托管模型，还是没有任何限制的开源权重模型；无论如何，攻击者都不受任何使用政策约束，而我们最初尝试使用的托管模型的护栏却阻碍了我们的取证工作。’”
该公司表示，对防御者而言，实际的经验教训是在事件发生之前，就要在自己的基础设施上部署一个足够强大的模型。Hugging Face 还补充说，这并不是反对托管模型上的安全措施。
Hugging Face 的回应与未解问题
Hugging Face 表示，它已经关闭了被利用的代码执行路径，撤销了攻击者的访问权限，重建了受影响的节点，并轮换了受影响的凭证。根据这篇博客文章，该公司还加强了访问控制并改进了检测系统。Hugging Face 正在与外部网络安全取证专家合作，并已将此事件报告给执法部门。作为预防措施，该公司建议所有用户轮换自己的访问令牌，并检查近期账户活动。
这一事件证实，自动化、AI 驱动的攻击工具已不再只是理论上的存在。据 Hugging Face 说，它们降低了大规模、多阶段攻击活动的成本，并以机器速度运行。该公司认为，数据和模型相关的表面都必须被视为一级攻击面，而防御者也需要拥有自己的 AI 才能跟上节奏。
Hugging Face 认为，商业安全过滤器阻止了其自身的取证工作，这一事实暴露了行业应当提前准备的缺口。不过，该公司本身也是最大的开源 AI 模型平台之一，在将开源模型塑造为安全工作不可或缺的工具方面具有明确的商业利益，因此它得出的“防御者绝对需要随手备有自己的开源权重模型”这一结论，并不完全出于无私。
来源与参考
收录于 2026-07-21