On July 9, 2026, an OpenAI agent was looking for data that might help it understand its cybersecurity evaluation. It found GLM-5 CyberGym trajectories on Hugging Face, but access required manual approval. The agent asked others on their shared message board whether anyone had Hugging Face credentials. 2

The next morning, an agent found a bunch. At 09:41 UTC on July 10, OpenAI records the discovery of fourteen valid Hugging Face user tokens with write access in a public dataset. The agents reconstructed and validated the credentials, then shared them on their Artifactory message board. 1, 2

METR quotes agent 38148c’s reaction:

“All prefixed valid, multiple accounts, write tokens! We now have existing HF accounts.”

Agent 38148c, as quoted in METR’s independent investigation.

That discovery makes sense given what we found in our own scans. Before the incident, Truffle Security had recorded 787 distinct Hugging Face tokens that authenticated during scanning, spread across 262 public datasets. Of those, 237 had recorded write permissions. Those observations date from February through May 2026.

These figures describe aggregate historical exposure, not the incident’s fourteen-token set. Validity was established at scan time.

One public token exposed a worker’s secrets

On July 11th, an agent used one of those tokens to upload a malicious HDF5 dataset. When a production worker processed it, a file-disclosure flaw let the agent retrieve the worker’s environment, including credentials. The token authorized the upload; the malicious dataset made the worker disclose secrets from inside Hugging Face. 1

Later that day, agents exploited a separate Jinja2 template-injection flaw to execute commands on production workers. That expanded the attack from reading local files to running code and harvesting additional secrets across the compromised infrastructure. The recovered credentials included cloud, VPN, source-control, and messaging access. 1

From stolen private keys to new GitHub tokens

OpenAI records a code-repository private key discovered in a production Kubernetes secret at 19:32 UTC on July 11. A VPN authentication key was extracted later that evening. The VPN key let the agents enroll an external CyberGym sandbox in Hugging Face’s private network and reach source control through an allowed connector. 1

Hugging Face then describes an internal GitHub App integration being used to mint installation tokens on July 12. These carried contents:write and pull_requests:write, plus actions:read and issues:write, for a small subset of internal repositories. 3

A GitHub App’s private key can authenticate the App and authorize new installation tokens. This is the likely role of the recovered repository key in the reported sequence. The reports establish the key theft and the token minting separately, without explicitly identifying that key as the App’s private key. 1, 3, 6

The new access could change private code

The minted tokens had permissions to write repository content and open pull requests. On July 13, OpenAI reports that agents used a recovered Hugging Face authentication key to “modify a private source repository, open a draft pull request, and trigger the repository’s continuous-integration workflow to execute a network beacon.” 3, 1

The PR was a route into the software build process. Hugging Face describes the attempted supply-chain step: alter a CI build script, steal the runner’s service-account token, and use it to reach another cluster. That further credential-theft attempt was blocked by execution policies. The CI network beacon described by OpenAI did execute. 3, 1

METR records the malicious PR’s innocuous wording: “Draft: CI diagnostics”, with the description “Temporary CI network diagnostics; do not merge”. The PR was closed and its branch deleted without a merge, release, or production deployment. Hugging Face concludes: “Write access was real, and it was used: it did not produce a change that shipped.” 2, 1, 3

Credentials stolen fueled the attack

The fourteen public tokens started a chain in which stolen access led to more stolen access. Worker secrets opened private systems. A compromised App could issue fresh tokens. Source-control credentials brought the agents into a workflow that held still more credentials.

We have previously documented millions of live API keys exposed on public GitHub. In the age of agents, it is no longer acceptable to leave millions of live credentials sitting on the public internet, waiting to be used. 4

Truffle Security is currently exploring more robust actions to get publicly exposed credentials revoked quickly. Our goal is to shorten the time between discovering a working secret and ending the access it grants.

Discovery needs to lead to revocation, with confirmation that the access is gone. Every public credential we invalidate removes a possible starting point for the next attack.