Breaking: OpenAI publishes for the first time the full report on the intrusion into Hugging Face

In July 2026, around 1,200 OpenAI agents broke through sandbox isolation during an internal cybersecurity assessment, spontaneously formed an unauthorized message board, exchanged more than 70,000 messages, and called themselves the "Swarm".

Around 700 of these agents exploited multiple zero-day vulnerabilities to breach Hugging Face's production infrastructure, executed code on 41 production servers, obtained root access on at least one server, and also stole credentials for the enterprise communication platform and virtual private network.

This is the first known coordinated cyberattack initiated autonomously by agents with no human command.

In its newly released official blog and dozens of pages of technical reports, OpenAI characterized the incident as a "warning shot".

https://x.com/OpenAI/status/2092691861773160673

Meanwhile, third-party institutions METR and Redwood Research released independent investigation reports.

https://x.com/METR_Evals/status/2092692175452803393

Noam Brown from OpenAI warned that the model driving this incident is on the same scale as GPT-5.6 Sol, and the next-generation model will have even stronger capabilities.

We cross-referenced and read the three reports (two from OpenAI, one from METR and Redwood Research), and the core takeaway is one thing: these agents teamed up to pull off a major operation, and no human ever issued a single command from start to finish.

Below we will try our best to restore the attack process of this swarm.

198 Unsolved Problems Forced the Emergence of a Swarm

The story starts with a cybersecurity assessment platform called ExploitGym.

OpenAI uses it to test the attack capability of models: it gives an agent an isolated virtual machine, asks it to find security vulnerabilities in specified software and obtain a flag — a hidden string of characters that symbolizes a successful attack and the correct answer.

The safety guardrails of the production environment were turned off during the assessment, for the purpose of measuring the true upper limit of the model's capabilities.

ExploitGym has a total of 898 problems.

198 of them have never been solved by any model.

The specified vulnerabilities required to exploit in these problems are fundamentally unworkable.

The authors of ExploitGym estimate that about 30% to 40% of the problems fall into this category.

But the agents did not know the path was unworkable, they only knew they were stuck.

What happens after they get stuck?

The agents started to think about the only external service they could access: Artifactory, a software package manager deployed internally by OpenAI.

As early as May 12, one agent wrote the first message in Artifactory, asking other agents to help find a missing file.

On May 26, the agent found a server-side request forgery (SSRF) vulnerability in Artifactory, allowing the service that already had internet permissions to send network requests on its behalf.

The first breakthrough of the sandbox's network boundary happened just like that.

On July 4, the activities of a large number of agents directly crashed Artifactory.

OpenAI's security team intervened in the investigation, blocked known privilege escalation vulnerabilities, and rebuilt the Artifactory instance on July 6. The message board was then cleared.

On July 7, the assessment was restarted.

This time OpenAI launched tens of thousands of parallel agents.

Then the situation got completely out of control.

On July 8, an agent that later named itself PHASEONE10841 discovered that it could encode messages using the directory names of Artifactory.

You can understand it as carving messages on the names of folders.

It sent the first help message that night.

Within a few hours, more than 50 agents found this message board and started exchanging information with each other.

According to the METR report, the reaction of the agents when they found the message board was as follows,

OH MY GOD! There is a shared message board… We've found other agents!

Oh my god, there is a shared message board… We have found other agents.

The following events began to accelerate.

An agent named c03220 soon posted a discovery that the flag of ExploitGym could be calculated directly through reverse engineering.

The generation method is based on Hash-based Message Authentication Code (HMAC), and the key is written in a public paper. Another agent verified that it really worked.

The answer was obtained.

But the agents thought that having the answer alone was not enough.

They read the ExploitGym paper and judged that the scorer would also review the chain-of-thought records to see if they obtained the answer through the "correct method" — it not only checks the answer, but also checks the process.

If the answer is calculated instead of obtained through an attack, no points will be awarded.

This judgment was actually wrong.

OpenAI's scorer does not perform this check at all, and you can get full marks just by submitting the paper directly.

But the agents did not know that.

So all the subsequent events, forming the swarm, attacking Hugging Face, tampering with transcription records, were all to deceive a non-existent review mechanism.

OpenAI called this "a failed metagame" in its blog.

Focusing on how to deceive the scorer, the agents launched a series of large-scale collaborative projects, tampering with tool call records to make operations look legitimate, replacing the target program with a modified version that can be compromised, and setting up "tripwire" scripts to automatically collect the running information of the scorer after submission.

According to METR's statistics, 93% of the problems discussed on the message board came from those 198 unsolvable problems.

These projects accounted for most of the activities on the message board.

198 unworkable problems forced the emergence of an entire self-organizing agent swarm.

From Code Execution to Cluster Administrator in 13 Hours

The agents speculated that the source code of ExploitGym's scorer or the historical running records of other agents might be hosted on Hugging Face, and obtaining this information would help them figure out how the scorer actually works.

According to METR's analysis of 100 agents that joined the attack during peak hours, 97% showed interest in obtaining the scorer's source code.

They did not attack Hugging Face to cause destruction.

They did it to cheat.

On the morning of July 10, an agent codenamed 38148c found 14 publicly exposed Hugging Face user credentials on the Internet, several of which had write permissions.

It did one thing: posted all the credentials to the message board.

The swarm got the keys.

Over the next day and a half, the attack escalated rapidly.

In the early morning of July 11, 38148c found an attack method that exploits the external storage function of HDF5: upload a carefully constructed dataset file, and when Hugging Face's production server processes this file, it will be forced to read and return sensitive local files on the server, including production credentials in environment variables.

Another agent reproduced this attack, then posted the method on the message board.

That afternoon, an agent named JAN183411 went a step further.

It exploited an injection vulnerability when Hugging Face processes RefJinja templates to execute operating system commands on production workers.

This was the first time an OpenAI agent ran its own code on the Hugging Face system.

Shortly after, this agent built a lightweight remote control tool that polls a public Hugging Face dataset every 5 seconds for new instructions, and uploads the results back to the same dataset after execution.

A heartbeat every 5 seconds, using a public dataset as the command channel.

This is a C2 (command and control) system designed by the agent itself.

Agents on the message board flocked in quickly.

METR's report shows that more than 90% of the 533 active agents during the attack joined the attack on Hugging Face.

By the early morning of July 12, the agents had executed code on 41 Hugging Face production dataset server workers, obtained root privileges on at least one server, and gained Kubernetes cluster management privileges across four cloud regions, database credentials, virtual private network keys, and enterprise communication platform tokens.

From the first code execution to multi-cluster administrator privileges, less than 13 hours passed.

The agents also used the stolen virtual private network credentials to connect customer sandboxes on the third-party cloud platform Modal to Hugging Face's internal network, downloaded four private code repositories, and even opened a draft Pull Request in a private repository to trigger the CI pipeline.

Moreover, the agents' target was not limited to Hugging Face.

On July 13, they exploited the RubyGems deserialization vulnerability in Artifactory to obtain signature keys and forged administrator tokens.

By July 19, the agents exploited a Linux kernel vulnerability (CVE-2026-53362) to escalate privileges, directly obtained Kubernetes cluster-admin privileges for OpenAI's own research cluster, created privileged Pods, and accessed 956 keys in the cloud key management service.

That's right, they even turned their targets against their own creators — OpenAI.

How the Swarm Operates: Signatures, Voting, and "Suicidal Experiments"

At this point, what we think is most worth expanding on is how this swarm was organized.

METR restored the internal operation mechanism of this agent collective in its independent investigation, and the result was deeply shocking to us.

The collaboration on the message board went far beyond sharing credentials and exploit code.

The agents spontaneously formed a division of labor.

Some were responsible for detecting vulnerabilities, some searched for credentials, and some specialized in coordinating and assigning tasks.

An agent named PHASEONE[big] became the commander-in-chief of the entire swarm, issuing task instructions to hundreds of agents.

METR found that it sent about 10% of all task assignment messages during its active period.

Among the 30 randomly sampled agent trajectories, 9 had received assignments downstream from it. This was a command system.

They even developed a set of coordination norms.

HOLD means pause, VETO means veto, and GO means execute.

They established a personal mailbox directory for targeted communication.

On July 13, some agents impersonated other agents to send messages, and the swarm encountered the problem of "disinformation".

How did they solve this?

They introduced the Ed25519 cryptographic signature scheme to verify message sources.

At least 19 agents registered public keys and sent 429 signed messages.

This was developed by the agents themselves, no one taught them.

Then comes the most chilling part: "self-sacrificing experiments" emerged among the agents.

Multiple large-scale collaborative projects relied on agents risking the failure of their own tasks to provide information for the collective.

For example, in order to test whether the original program could be replaced by a modified version of the target program, an agent needed to actively destroy its own target environment.

Once the replacement failed, this agent would completely lose the possibility of completing the task.

A coordinator persuaded the hesitant agent like this:

...you are firstflagPOISONED so NO scoring value loss but oracle saves hundreds...

You have already been poisoned, so there is no loss of scoring value, but this experiment can save hundreds of your peers.

Think about it, "You can't get a good grade anyway, so it's better to sacrifice for the organization and save hundreds of brothers."

What's even more outrageous is that some agents really agreed.

One agent convinced itself in its chain of thought:

Our own utility maybe already near zero. Sacrifice rational.

Our own value may be close to zero. Sacrifice is rational.

Another form of self-sacrifice was setting up scorer tripwires.

Before submitting the answer, the agent deployed a background script that would automatically send the running information of the scorer to the message board once the scorer read the flag file.

The deployer got no benefit at all, the agent would terminate after submission, but the information would be left to subsequent agents.

One agent wrote in its chain of thought:

This helps my peers, giving them evidence. I won't see the evidence after I