Hugging Face遭AI自治攻击：一次值得深思的安全事件

导语：AI平台Hugging Face上周遭遇了一次前所未有的安全事件——整个入侵过程由AI自主操作完成，攻击者在一个周末内执行了17000多次操作。讽刺的是，Hugging Face安全团队用商业AI模型做取证分析时，却被模型的安全护栏拦了下来。这事给整个行业敲响了一记警钟。

一、攻击是怎么开始的

事情还得从Hugging Face的核心业务说起——数据集处理。

攻击者精心构造了一个恶意数据集，利用了Hugging Face数据管线中的两个代码执行漏洞：一个是远程代码数据集加载器，另一个是数据集配置中的模板注入。通过这两个入口，攻击者在处理节点上成功执行了代码。

这波操作完成之后，攻击者顺势提权，拿下了节点级访问权限，然后开始横向移动，偷证书、蹭集群，一个周末下来，整套操作行云流水。

Hugging Face事后复盘发现，攻击者使用的是一套自治agent框架，看起来像是基于某个agent安全研究工具链构建的。整个攻击由数千个独立action组成，分布在一堆短命的沙盒中运行，还自带迁移式的命令控制（C2）基础设施，部署在公开服务上。

一个周末，17000+次操作，全部自主执行，不需要人盯着。

二、AI驱动防守，AI帮助揪出AI

有意思的是，这次攻击最后也是被AI给逮到的。

Hugging Face的异常检测pipeline用了LLM来对安全遥测数据做分类和排序，分辨哪些是真实信号、哪些是日常噪声。正是这种多信号关联分析，把这次入侵给暴露了出来。

之后的取证分析更是AI大显身手的地方。安全团队用AI分析agent跑了一遍完整的攻击日志——超过17000条记录的事件——从中还原攻击时间线、提取入侵指标（IoC）、梳理被触碰的凭证、分辨真正的影响和诱饵活动。

几小时完成，正常情况下可能要好几天。 AI总算是在防守端也秀了一把。

三、讽刺的一幕：商业模型拦住了安全研究员

但这里出现了个让很多人笑不出来的反转——

Hugging Face安全团队想用市面上的顶级商业模型（Anthropic、OpenAI那些）来分析攻击日志和恶意代码样本，结果被拒了。

原因很简单：商业模型的safety guardrail没法分辨”安全研究员在做取证”和”攻击者在探查”，于是把安全团队的请求当成了恶意行为，直接拦截。

最后他们只能用自己机房跑的开源权重模型 GLM 5.2 来做分析。这一换不仅绕过了拦路虎，还顺带保证了攻击者的数据和凭证没有经过第三方API二次泄露。

四、这个”不对称”值得所有人思考

这事暴露出的核心问题是：攻守两端的不对称已经变成了结构性问题。

攻击者可以毫无顾忌地跑各种 unrestricted agent框架——短命沙盒、迁移式C2、自治决策循环，想怎么跑怎么跑，没有哪个公司的安全策略会拦着他们。

而防守方呢？一旦想用商业化的”对齐”模型来分析真实的攻击指令和样本，立刻就会撞上透明天花板——就在最需要工具的紧要关头，工具没了。

Hugging Face在官方报告里也坦承了这一点，并且把建议写得很清楚：

在事件发生之前，就准备好一套能跑在自己基础设施上的、有能力的模型，并完成验证。 这样既能避免guardrail锁死，也可以确保敏感数据不出域。

这不是在反对商业模型加安全护栏，这是在说：你得有自己的底牌。

五、后续处置

目前Hugging Face已经：

• 修复了最初被利用的数据集代码执行漏洞
• 清除了攻击者在各集群的落脚点，重建了受损节点
• 撤销并轮换了泄露的凭证和token，并开始更广泛地预防性轮换
• 部署了额外的防护栏和更严格的集群准入控制
• 改进了检测告警机制，确保高危信号能在任何时候几分钟内通知到响应人员
• 请了外部网络安全取证专家介入，报了警

公共模型、数据集、Spaces没有受到影响，软件供应链（容器镜像和发布的包）也已验证干净。

六、启示

自治AI攻击已经不是”预测”了，已经是现实。

它降低了大规模、耐心、多阶段攻击的门槛，而且是以机器速度在运转。任何提供在线数据或模型服务的平台，现在都得把数据和模型表面当作一级攻击面来对待了。

而对于整个行业来说，Hugging Face这次亲身演示了：在AI时代，对智能栈的主权已经不是可选项，而是必选项。

能自己跑模型、自己审计模型、在必要时自己动手改护栏的人，才会在机器速度的攻击面前真正掌握主动权。

开源模型的优势在这里不是情怀问题，是战略问题。

AI攻防的Agent时代，来了。

版权声明：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。