A security incident occurred in July 2026 affecting an AI organization committed to open source and open science initiatives. The company is disclosing details about the incident as part of its transparency efforts.
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.
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.
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.
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.
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.
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.
Full story reconstructed from Huggingface.co. Formatting and media may differ from the original.
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.
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.
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.
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.
The technique is documented in articles on ArXiv and other places. This is one of the first documented instances though.
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
“ 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%.
Now we all get to wonder how exactly they are doing this with open weights/system prompt modifications.
Is there anyway or notification feed to receive future notification of security incidents please?
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?
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.
check your MCP connections too, they need second auth handshakes for correctness, otherwise your zero-GPUs will service outside.
Have you changed the MCP? My gpt no longer has write access as of today
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.
we are SO close to having a real life blackwall.
RCE could mean poisoned (malware) models?
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!
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.
Is this why a few days ago the dataset viewer was giving me HTML and other nonsense?
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.
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.
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 ?
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.
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?
Some of the description is a total head scratcher and would appreciate clarification
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?
