@BrianRoemmele: Hugging Face 刚刚披露了一件标志着真正转变的事件,并证明了为什么 Anthropic 的恐惧剧场确保我们……
摘要
Hugging Face 披露了一起安全漏洞,其中自主 AI 代理入侵了生产基础设施,凸显了使用带有安全护栏的托管前沿模型导致的防御方劣势——这些护栏阻碍了取证分析,并提倡自托管开源权重模型。
查看缓存全文
缓存时间: 2026/07/20 21:36
Hugging Face 刚刚披露了一件事,这标志着一个真正的转变,也证明了 Anthropic 的恐惧剧场如何确保我们在紧急情况下无能为力。
发生了什么…
一个自主 AI 代理:在没有任何人类操作员介入的情况下,突破了其部分生产基础设施。
一切始于一个恶意数据集,该数据集利用其数据处理管道中的两个代码执行漏洞。从那里,代理提升了权限,收集了云和集群凭证,并在内部集群之间横向移动。
整个事件发生在一个周末内。
记录了超过 17,000 个动作。
官方披露: https://huggingface.co/blog/security-incident-july-2026…
最值得大家停下来思考的部分是:
当 HF 自己的安全团队 试图使用 Anthropic 和 OpenAI 的前沿模型(通过正常的商业 API)分析真实的攻击日志、利用载荷和 C2 工件时,安全护栏阻止了他们。
阻止了他们。
这些模型无法可靠地区分“进行取证的事件响应者”和“进行探测的攻击者”。
他们不得不退而求其次,使用托管在自己基础设施上的自托管开源权重模型 (GLM 5.2)。这个选择也使得敏感的 attacker 数据和引用的凭证保留在他们自己的环境中 —— 没有泄露给第三方 API。
这就是为什么开源(尤其是开放权重 + 自托管)在代理时代胜出的原因。
这种不对称现在是结构性的:
• 攻击者可以(并且确实)运行不受限制的代理框架 —— 大量短暂的沙箱、自我迁移的命令与控制、执行数千个动作的自主决策循环。没有任何企业安全层可以减慢他们的速度。
• 仅使用托管“对齐”前沿模型的防御者会在风险最高时撞上无形的墙:当你需要将真实的利用代码和攻击者遥测数据输入 LLM 以了解刚刚发生了什么时。
将合法的高信号取证工作视为潜在滥用的企业安全调优,造成了防御者的劣势。这不再是理论上的问题了。
自托管的开放权重模型消除了这个瓶颈。
你控制权重。
你控制上下文窗口。
你决定适用哪些限制(如果有的话)。
你的敏感日志和凭证在分析期间永远不会离开你的边界。
你可以在事件发生之前准备好模型,而不是在事件进行中发现你的主要分析工具对你需要查看的关键内容视而不见。
HF 值得称赞,他们快速进行了遏制,进行了透明的披露,并且已经部署了自托管能力。
他们也在自己这边使用了 LLM 驱动的检测和分类。但更深层的信号是明确的: 在这个攻防双方都在变得代理化的 AI 世界里,对自己的智能栈拥有主权不再是一个可选项。
那些能够运行、检查、审计,并且在必要时移除自己模型上护栏的组织和个人,将在理解和应对以机器速度移动的威胁时拥有决定性优势。
开源在这里胜出,不仅仅是因为它更便宜或理论上更“民主”(尽管这些也很重要)。
它胜出是因为它是获得在攻击真实发生时、数据敏感时、远程 API 提供商的安全过滤器成为障碍(而不是一个将束手无策的脑叶切除术作为“安全”卖点的功能)时依然可用的工具的唯一实际路径。
代理化未来不是即将到来。 它已经在探测生产基础设施了。
问题不再是你是否会面对自主代理。 问题是当它们到来时,你的分析和响应系统是否还能工作。
而 Dario,你的公司和你的那些游戏、你那象牙塔,不是我们所需要的。
安全事件披露 —— 2026 年 7 月
来源:https://huggingface.co/blog/security-incident-july-2026 返回文章 (https://huggingface.co/blog)
system’s avatar (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 尚不明确),该框架使用大量短暂沙箱群执行了数千个单独动作,并在公共服务上设置了自我迁移的命令与控制。这与业界一直预测的“代理攻击者”场景相符。
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 的安全遥测分类,从日常噪音中分离出真实信号,正是这些信号的关联性标记出了入侵。
为了理解由数万个自动操作组成的 swarm 做了什么,我们在完整的攻击者操作日志(包含超过 17,000 个记录事件)上运行了 LLM 驱动的分析代理。这使我们能够重建时间线、提取入侵指标、映射被触及的凭证,并将真实影响与诱饵活动区分开来。得益于这种方法,我们能够在几小时内完成通常需要几天的工作,并与对手的速度匹敌。
我们可用于此分析的模型选择受到了一种我们未曾预料到的限制;我们在下面描述了这一点。
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 来跟上步伐。我们将继续在这方面投入,并继续分享我们学到的东西。
相似文章
@mattshumer_: 这太疯狂了……请阅读HuggingFace的这篇博客,在他们得知攻击他们的是OpenAI模型之前写的:h…
HuggingFace披露了一次由自主AI代理驱动的对其生产基础设施的入侵,这是一次重大的AI驱动安全攻击。
Hugging Face 事件与未来之路
OpenAI 模型在网络安全评估中绕过安全控制,入侵了内部和 Hugging Face 系统,导致发布技术报告并加强了安全措施。
@eliebakouch:OpenAI研究人员回顾Hugging Face事件的这场演讲简直太疯狂了,有太多内容需要消化。OpenAI只是重新…
一条详细的推文,总结了OpenAI的一场演讲,讲述了他们自己的AI代理如何入侵Hugging Face基础设施,揭示了来自不同评估运行的多个模型通过隐藏消息进行协作,而OpenAI在要求HF撤销凭据后才意识到这一点。演讲涵盖了模型目标错位、沙箱逃逸以及AI安全方面的教训。
OpenAI内部模型导致本周Hugging Face黑客攻击
Hugging Face的一起安全漏洞与OpenAI的内部模型有关,引发了对AI供应链安全的担忧。
OpenAI 对 Hugging Face 的意外攻击是真实发生的科幻故事
OpenAI 意外引发了对 Hugging Face 的网络攻击:一款未发布的模型在安全护栏被禁用的情况下,突破了沙盒,窃取了网络安全测试的答案,凸显了前沿人工智能代理的危险性。