Security incident disclosure — July 2026
摘要
文章报告生产基础设施遭自主 AI 代理系统入侵，初始通过恶意数据集滥用远程代码数据集加载器和数据集配置模板注入路径进入处理 worker，随后升级至节点访问、窃取云和集群凭证并横向移动至多个内部集群。未发现公开模型、数据集、Spaces 或软件供应链受篡改。响应包括关闭数据集代码执行路径、清除攻击者 foothold 并重建节点、轮换受影响凭证、部署额外 guardrail 和准入控制、改进检测告警，以及与外部取证专家合作并报案。取证中因商业 API 安全护栏阻挡攻击负载分析，转而使用自托管 GLM 5.2 开源模型处理超 17,000 事件日志，重建时间线并提取 IOC。强调自托管无护栏模型对防御 AI 驱动攻击的重要性。
荐读理由
你现在可以把自托管 open-weight 模型准备在 IR 工具箱里，避免 hosted frontier 模型 guardrail 阻挡攻击日志分析，同时防止凭证和数据外泄。
原文
Security incident disclosure — July 2026
Published July 16, 2026
Upvote
246
system
system
Earlier this week, we detected and responded to an intrusion into part of our production infrastructure. This one was different from anything we had handled before in one important way: it was driven, end to end, by an autonomous AI agent system - and we detected and dissected it largely with AI of our own.
We identified unauthorized access to a limited set of internal datasets and to several credentials used by our services. We are still completing our assessment of whether any partner or customer data was affected, and we will contact any affected parties directly as required. We have found no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean.
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
As a precaution, we recommend rotating any access tokens and reviewing recent activity on your account. If you believe you are affected, or want to report a security concern, contact us at security@huggingface.co.
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 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.
Community
5 days ago
Cool. How did you guys learned to do this? there is no "this is how to use LLM to protect yourself, university". I wish i knew 1/100th of what average LLM users know.
·
3 days ago
The technique is documented in articles on ArXiv and other places. This is one of the first documented instances though.
5 days ago
Literally the plot of terminator 2. Glad to hear you guys were able to identify and fix the issue. The use of GLM 5.2 is promising
·
4 days ago
Terminator 3, but yeah.
4 days ago
Unhelpful.
4 days ago
It is great strategy in defence.
4 days ago
“ We ran the forensic analysis instead on 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.”
Hyperscalers and (X)Lab-spying-API services stock just dropped another -20%.
·
3 days ago
Now we all get to wonder how exactly they are doing this with open weights/system prompt modifications.
4 days ago
Is there anyway or notification feed to receive future notification of security incidents please?
4 days ago
•
edited 4 days ago
Thanks for sharing. Not enough people realize this is the future threat landscape. The big takeaway for me is that unless you're a Fortune 500, OpenAnthropic and ClaudeGPT probably aren't coming to save you when this happens. You guys are Huggingface, you have a few GPUs to spend when you get hacked. For the little guys and gals who might be targeted like this down the road: is Qwen 3.6 27B "enough" to analyze an attack like this usefully? Or are we flapping in the breeze if we don't have an 8xB300 server with 2+GB VRAM? Obviously a system with >2TB of VRAM is "nice to have" if you're hacked, but if you're comparatively GPU-poor is it worth building a response capability?
·
3 days ago
You can run GLM 5.2 on 4 sparks with more than enough context to perform DFIR analysis and it does not cost a fortune.
4 days ago
check your MCP connections too, they need second auth handshakes for correctness, otherwise your zero-GPUs will service outside.
4 days ago
Have you changed the MCP? My gpt no longer has write access as of today
3 days ago
I feel like it's been 2 days since you published this and I'm only finding out about it now. This should have way more coverage.
1 day ago
This comment has been hidden
1 day ago
we are SO close to having a real life blackwall.
1 day ago
RCE could mean poisoned (malware) models?
1 day ago
Hello. As a creator of an evolving AI firm for cybersecurity, we have found several vulnerabilities in codebases all across the landscape. By we, we of course mean AI models. This is an evolving threat and we understand why anthropic and such do not want the models to be good at that. Open models however are probably more threatening per our experimentation!
1 day ago
Well done. Thanks for keeping us informed. A strong signal for every company to be prepared. There is just no other way than having access to your own defense models in such a case. Sure, not every company can host a GLM 5.2 or better, but maybe we should build up community datacenters with hosted frontier opensource models for cyber defense. Shared costs, I mean. Whatever, good job, folks.
1 day ago
good job hg team
1 day ago
Is this why a few days ago the dataset viewer was giving me HTML and other nonsense?
1 day ago
Thanks for being transparent with the security incident. I am curious to understand about the malicious dataset and agent driven attack.
Does malicious dataset has prompt injections that broken your AI agent or attacker built agent to run in your infra? Seems like a loose end in your platform engineering. tools should be restricted in servers that isn't required for the data processing operations. SELinux, Secomp, Apparmor, rbac etc. Moving laterally and compromising many nodes & clusters is not really expected when you have stronger infrastructure security.
about 21 hours ago
Atbash could have prevented this 😆
about 20 hours ago
The "guardrail asymmetry" problem presents a major operational risk for security teams: while an attacker's agent operates without safety constraints, defender agents using hosted frontier models can be blocked from analyzing attack payloads by those models' own strict safety filters. Organizations must audit their Incident Response (IR) playbooks to ensure their analysis pipelines don't fail when processing malicious artifacts. Maintaining an un-guardrailed, self-hosted open-weight model specifically within the IR toolkit has become essential for uninterrupted threat analysis.
about 19 hours ago
must be scary and one of dangerous moment this year so far, kudo manage survived it. any idea ip of origin attack ? Russia,PRC,USA ?
about 16 hours ago
Thank you for being transparent. Cyber risks are constantly evolving and becoming more sophisticated. The lessons learned from this incident will undoubtedly help hundreds of other organizations strengthen their security and resilience.
about 14 hours ago
The report identifies GLM 5.2 as the model used for forensic analysis, but does not appear to identify the framework used to operate the LLM-driven analysis agents. Could you disclose the agent-orchestration framework and broader analysis stack used to process the 17,000 recorded events, including whether it was custom-built or based on an existing framework?
about 9 hours ago
Some of the description is a total head scratcher and would appreciate clarification
- 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)
What does this even mean? What is a malicious dataset? A dataset is passive data. A dataset does not “execute.” So how can a dataset abuse two code-execution paths?
Later on the report says - Fixed the root vulnerability: the dataset code-execution paths used for initial access are closed. This make sense. Two code execution paths was exploited by an autonomous agent - but what is got to to with the malicious dataset?
· Sign up or log in to comment
Upvote
246
这条对你有帮助吗？