Hugging Face 2026年7月安全事件披露
Security incident disclosure — July 2026
Hugging Face 披露,恶意数据集利用两条代码执行路径入侵处理 Worker,攻击者随后获取节点权限并横向进入多个内部集群。公司已修复漏洞、重建受影响节点并轮换凭据;其分析智能体使用 GLM-5.2 处理逾 17,000 条攻击事件,在数小时内完成通常需数天的取证工作。
推荐理由
精选AI 评分 85
这份一手复盘呈现智能体攻击与防御的实战链路,并给出本地部署模型用于事件响应的可迁移经验。
主题
正文
当前显示原文,中文全文译文尚未就绪。
What happened
The intrusion started where AI platforms are uniquely exposed: the data-processing pipeline. A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker. From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.
The campaign was run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known) executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services. This matches the "agentic attacker" scenario the industry has been forecasting.
What we did
Fixed the root vulnerability: the dataset code-execution paths used for initial access are closed.
Eradicated the attacker's foothold across the affected clusters and rebuilt the compromised nodes.
Revoked and rotated the affected credentials and tokens, and began a broader precautionary rotation of secrets.
Deployed additional guardrails and stricter admission controls on our clusters.
Improved our detection and alerting so a high-severity signal pages a responder in minutes, any day of the week.
We are working with outside cybersecurity forensic specialists to investigate the issue and review our security policies and procedures. Finally, we have also reported this incident to law enforcement agencies.
For our community
We are grateful to the teams across Hugging Face who responded around the clock, and we are sorry for any disruption this caused. Security is never finished; we will keep raising the bar.
Analyzing an AI-driven intrusion
The attack was initially surfaced through AI-assisted detection. Our anomaly-detection pipeline uses LLM-based triage over security telemetry to separate real signals from the daily noise, and it was the correlation of those signals that flagged the compromise.
To understand what a swarm of tens of thousands of automated actions did, we ran LLM-driven analysis agents over the full attacker action log, comprised of more than 17,000 recorded events. This allowed us to reconstruct the timeline, extract indicators of compromise, map the credentials touched, and separate genuine impact from decoy activity. Thanks to this approach, we were able to do in hours what would usually take days, and match the adversary's speed.
The choice of models we could use for this analysis was constrained in a way we did not anticipate; we describe this below.
The asymmetry problem
When we started the log analysis, we first used frontier models behind commercial APIs. This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker. We ran the forensic analysis instead on zai-org/GLM-5.2 , an open-weight model, on our own infrastructure. This had a second benefit: no attacker data, and none of the credentials it referenced, left our environment.
This experience points to a gap worth planning for. We do not know which model powered the attacker's agents, whether a jailbroken hosted model or an unrestricted open-weight one; either way, the attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried. The practical lesson for defenders: have a capable model you can run on your own infrastructure vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment. This is not an argument against safety measures on hosted models, and we are sharing this feedback with the providers concerned.
What this means
Autonomous, AI-driven offensive tooling is no longer theoretical. It lowers the cost of running a broad, patient, multi-stage campaign, and it operates at machine speed. Defending an online platform now means treating the data and model surface as a first-class attack surface, and using AI on defense to keep pace. We will keep investing there, and keep sharing what we learn.
Models mentioned in this article 1
zai-org/GLM-5.2