安全事件披露——2026年7月

来源：https://huggingface.co/blog/security-incident-july-2026 返回文章列表 (https://huggingface.co/blog)

系统头像 (https://huggingface.co/system)

• 发生了什么 (https://huggingface.co/blog/security-incident-july-2026#what-happened)
• 我们做了什么 (https://huggingface.co/blog/security-incident-july-2026#what-we-did)
• 致我们的社区 (https://huggingface.co/blog/security-incident-july-2026#for-our-community)
• 分析一次AI驱动的入侵 (https://huggingface.co/blog/security-incident-july-2026#analyzing-an-ai-driven-intrusion)
• 不对称问题 (https://huggingface.co/blog/security-incident-july-2026#the-asymmetry-problem)
• 这意味什么 (https://huggingface.co/blog/security-incident-july-2026#what-this-means)

本周早些时候，我们检测并响应了一起针对部分生产基础设施的入侵。这次事件与我们之前处理过的任何入侵有一个重要区别：它从头到尾是由一个自主AI代理系统驱动的——而我们主要依靠自己的AI技术检测并分析了它。

我们识别出对一组有限的内部数据集以及我们服务使用的几个凭据的未授权访问。我们仍在评估是否有合作伙伴或客户数据受到影响，如需要，我们将直接联系所有相关方。我们没有发现任何用户可直接使用的公开模型、数据集或Spaces被篡改的证据，并且我们的软件供应链（容器镜像和已发布软件包）已确认是干净的。

https://huggingface.co/blog/security-incident-july-2026#what-happened发生了什么

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

此次攻击由一个自主代理框架（看起来基于一个智能体安全研究工具构建，所用的LLM尚不清楚）执行，该框架在一个由短期沙盒组成的集群中执行了成千上万次独立操作，并将自迁移的命令与控制（C2）设施部署在公共服务上。这与业界一直预言的“智能体攻击者”场景完全吻合。

https://huggingface.co/blog/security-incident-july-2026#what-we-did我们做了什么

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

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

https://huggingface.co/blog/security-incident-july-2026#for-our-community致我们的社区

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

我们感谢 Hugging Face 的多个团队昼夜不停地响应，并对由此造成的任何中断深表歉意。安全永远没有终点；我们将持续提升标准。

https://huggingface.co/blog/security-incident-july-2026#analyzing-an-ai-driven-intrusion分析一次AI驱动的入侵

这次攻击最初是通过AI辅助检测浮出水面的。我们的异常检测流水线使用基于LLM的优先级分类对安全遥测数据进行处理，以从日常噪声中分离出真正信号，而正是这些信号的关联性标记出了这次入侵。

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

我们可用于此分析模型的选取受到了一种未曾预料到的限制；下文将进行描述。

https://huggingface.co/blog/security-incident-july-2026#the-asymmetry-problem不对称问题

当我们开始日志分析时，首先尝试了通过商业API使用前沿模型。但这行不通：分析需要提交大量真实的攻击命令、利用载荷和C2工件，而这些请求被提供方的安全防护措施阻止了——因为它们无法区分事件响应者和攻击者。我们转而使用开放权重模型 GLM 5.2，在自己的基础设施上运行取证分析。这带来了第二个好处：没有任何攻击者数据以及日志中引用的凭据离开我们的环境。

这一经历揭示了一个值得规划的安全缺口。我们不知道攻击者的代理是由哪个模型驱动的——是越狱的托管模型还是不受限制的开放权重模型；无论哪种，攻击者不受任何使用策略约束，而我们自己的取证工作却首先被我们尝试使用的托管模型的防护措施阻挡。对防御者来说的实际教训是：在事件发生之前，就要准备好一个经过审查且能在自己基础设施上运行的高性能模型，以避免被防护措施锁定的同时，确保攻击者数据和凭据不会离开你的环境。这不是反对托管模型上的安全措施，我们正在向相关提供方分享这一反馈。

https://huggingface.co/blog/security-incident-july-2026#what-this-means这意味什么

自主的、AI驱动的攻击工具不再是理论上的。它降低了实施广泛、耐心、多阶段攻击的成本，并以机器速度运作。如今，保护一个在线平台意味着将数据和模型表面视为第一类攻击面，并使用AI进行防御以保持同步。我们将持续在此领域投入，并分享我们的经验。