Datasets are usually treated as passive collections of information. Developers download them, load them into their systems and use them to train or test AI models. However, a recent security incident at Hugging Face has shown that a dataset can also be used to deliver and execute malicious code.
Hugging Face said an attacker gained unauthorised access to parts of its production infrastructure. According to the company, the attack was carried out using an autonomous AI agent system and was largely detected with the help of its own AI-powered security tools.
The company reported that some internal datasets and service-related credentials were accessed. It is still investigating whether any customer or partner information was affected. Hugging Face said its public models and Spaces were not compromised.
How the attack reportedly began
The most concerning part of the breach was the method used to enter the system.
According to the incident details, a malicious dataset exploited a loader capable of remote code execution, along with a template injection weakness in the dataset configuration. This allowed the attacker to run code inside a processing worker.
After gaining access to the worker, the attacker reportedly escalated privileges, obtained cloud and cluster credentials and moved across several internal clusters in less than a week.
A dataset loader is designed to import data and prepare it for use by an AI model. Some loaders can also run scripts included with a dataset, making the process easier for developers.
However, this convenience can create a serious security risk. When a loader automatically executes scripts, a dataset is no longer just a collection of files. It can also act as a payload carrying malicious code into a trusted environment.
The template injection vulnerability made the situation worse by allowing harmful instructions to be hidden inside a configuration file that appeared harmless.
An attack powered by autonomous AI agents
Hugging Face said the breach was unusual because the operation was reportedly carried out by an autonomous agent-based system.
The attacker is believed to have performed thousands of individual actions through a network of temporary sandbox environments. The system also reportedly moved its command-and-control operations across public services to avoid detection.
Hugging Face described this as the kind of agentic attacker that the cybersecurity industry had expected to emerge. However, the core techniques used in the attack, including credential theft, privilege escalation and lateral movement, are already familiar to security teams.
What has changed is the speed and scale at which an AI-powered system can carry out these actions.
Safety guardrails created another challenge
The incident also exposed an unexpected problem for Hugging Face’s security team.
The company reportedly attempted to analyse more than 17,000 actions performed by the attacker using frontier AI models available through commercial APIs. However, the requests were blocked by safety systems because they involved the analysis of a real-world cyberattack and exploitation techniques.
Hugging Face eventually used GLM 5.2, a general-purpose model running on its own infrastructure, to examine the attack logs.
The incident highlights a difficult balance for AI providers. Safety restrictions are designed to stop people from using AI tools for harmful cyber activity, but those same restrictions can also prevent legitimate security teams from investigating attacks.
Hugging Face has therefore recommended that organisations prepare capable, self-hosted AI models before a security incident occurs. This could allow defenders to analyse sensitive attack data without depending entirely on external services.
What developers should learn from the breach
For developers and AI teams that regularly download datasets from Hugging Face or other public platforms, the incident is not a reason to panic. It is, however, a reminder that datasets should never be trusted automatically.
Dataset loaders capable of executing scripts should be treated in the same way as any other third-party code. Teams should review scripts before running them, restrict loader permissions and process untrusted datasets inside isolated environments.
They should also avoid exposing cloud credentials, internal networks or sensitive systems to dataset-processing workers.
The biggest lesson is simple: a dataset may look like a harmless collection of information, but if it contains executable components, it can become an entry point for attackers.
