一句话看懂：全球知名 AI 平台 Hugging Face 确认遭遇一次由完全自主的 AI 智能体系统发起的网络攻击，攻击者通过恶意数据集入侵了内部基础设施。而 Hugging Face 正是利用自身 AI 工具，在数小时内完成了原本需要数天的取证分析，上演了一场“以 AI 攻、以 AI 守”的攻防实战。
事件核心：发生了什么
根据 Hugging Face 官方披露，攻击者通过一个恶意数据集，利用数据集处理流水线中的两处代码执行漏洞（一个远程代码数据集加载器和一个数据集配置中的模板注入），成功进入平台内部。随后，攻击者以节点级权限横向移动，窃取了云服务及集群的访问凭证。整个攻击行为由一套基于智能体安全研究框架构建的自主智能体协调执行。Hugging Face 判断这是行业此前预期的“智能体攻击者”场景从理论变为现实的案例。公司表示，公共模型、数据集和 Spaces 服务未遭篡改，软件供应链也未受影响，但合作伙伴或客户数据是否泄露仍在调查中。
为什么重要
此次事件标志着 AI 驱动的网络攻击已不再只是理论推演，而是具备了实际破坏力。攻击者利用短生命周期沙箱集群执行了超过 17,000 次操作，并使用自迁移的命令与控制（C2）基础设施运行在公开服务上，展现了机器速度、多阶段、低成本的特点。更值得关注的是防御层面的不对称：Hugging Face 安全团队最初尝试使用商业 API 中的前沿模型（如 GPT 系列）分析攻击日志时，遭到供应商安全护栏的拦截——模型无法区分安全分析师与攻击者，因请求包含了真实攻击负载、利用代码和 C2 痕迹而被阻止。最终，Hugging Face 只能使用自家的开源权重模型 GLM 5.2 在私有基础设施上完成全部取证分析，确保攻击数据和凭证从未离开自有环境。这表明，对于安全防御方而言，拥有一个在自有基础设施上运行、不受外部使用政策限制的模型至关重要。
对用户/开发者/创作者的影响
对于普通用户和开发者，最直接的行动是立即旋转（重置）Hugging Face 账户的访问令牌（Access Tokens），并检查近期账户活动记录。此次攻击是利用数据集处理链路中的代码执行缺陷完成入侵，这意味着任何依赖 AI 平台处理公开数据集的团队，都需要重新审视自己的数据流水线安全。对于企业安全团队来说，这一案例也给出一个明确的实践教训：不能完全依赖第三方 API 模型做安全取证，因为商业模型的安全护栏会阻止威胁情报分析这类“敌对”输入，而必须提前储备可在内部运行的开源或私有大模型。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
首先，Hugging Face 表示攻击使用的 AI 智能体框架是基于“智能体安全研究工具”构建的，但目前公开信息显示尚未确认具体由哪个大模型驱动。这一细节可能随着外部网络安全取证调查或执法机构介入而进一步披露。其次，事件中暴露的远程代码执行路径是否影响其他 AI 平台（如数据集托管或模型托管平台）值得关注，类似漏洞可能并非 Hugging Face 独有。最后，Hugging Face 强调这不是反对对托管模型施加安全措施，但平衡安全护栏与安全分析需求之间的冲突，将是 AI 安全领域下一个需要解决的核心议题。
