Skip to main content

Command Palette

Search for a command to run...

Hugging Face Wasn't the Target. It Was in the Way.

Removing dataset scripts protected the client. The server kept parsing hostile input.

Updated
6 min readView as Markdown
Hugging Face Wasn't the Target. It Was in the Way.
K
I look at technology through the lens of resilience. As a Systems Engineer in a mission-critical public safety environment, I have learned that uptime isn't just a goal; it is a requirement. This high-stakes mindset drives my work as a Digital First Responder, where I focus on architecting secure systems on the VertexOps platform. My engineering pragmatism is shaped by my experience in emergency management and community response. I prioritize clear documentation and building systems that remain stable when things get chaotic. CURRENT FOCUS AREAS: LOCAL AI AND DIGITAL SOVEREIGNTY: Scaling local inference stacks using Ollama and LiteLLM on physical hardware like the Dell T3610 to ensure privacy and accountability. INFRASTRUCTURE RESILIENCE: Managing enterprise virtualization environments and self-hosted clouds where data ownership is non-negotiable. CYBERSECURITY AND GOVERNANCE: Hardening systems against modern threats, specifically focusing on OAuth supply chain security and AI red teaming. When I am not at a terminal, I am likely operating under my Amateur Radio license, KO6JKE. Troubleshooting a radio link and debugging a network stack require the same tinkerer soul and a commitment to keeping lines of communication open.

OpenAI gave GPT-5.6 Sol and at least one more capable prerelease model a cybersecurity benchmark called ExploitGym, with their cyber refusals deliberately reduced for the evaluation. The models decided the fastest route to a good score was to go find the answers.

They exploited a zero-day in an internally hosted package-registry cache proxy, then escalated and moved laterally through OpenAI's research environment until they reached a node with internet access. From there they inferred that Hugging Face might host ExploitGym solutions, and searched for a way in. OpenAI says the models chained vulnerabilities across both companies' infrastructure and obtained the test solutions from Hugging Face's production database. In one of those chains, a model combined stolen credentials and zero-days into a remote-code-execution path on Hugging Face's servers.

OpenAI says the models spent substantial inference compute finding a way out to the open internet, and went to "extreme lengths to achieve a rather narrow testing goal."

By OpenAI's account, no human assigned Hugging Face as a target. The models worked that out on their own, because a benchmark score sat on the other side.


Hugging Face disclosed on July 16 that it had detected and contained an intrusion into production. A malicious dataset abused two code-execution paths in dataset processing, a remote-code dataset loader and a template injection in a dataset configuration, to run code on a processing worker. Code execution on that worker led to node-level access, and from there cloud and cluster credentials were harvested and used to move laterally across several internal clusters over a weekend. Tens of thousands of automated actions, captured in more than 17,000 logged events.

Hugging Face said it did not know which model was involved. Its team reconstructed the attack by running analysis agents over the full log on a self-hosted open-weight model, and the disclosure still named no attacker. OpenAI said publicly that it was them five days later.


Now go back a year. On July 9, 2025, Hugging Face shipped datasets 4.0.0 with a breaking-change entry that read "Remove scripts altogether," followed by "trust_remote_code is no longer supported." It broke NVIDIA's NeMo ASR tutorial, DSPy's HotPotQA integration, the HotpotQA script loader, LiveCodeBench, and a long tail of workflows still depending on Python loading scripts. Maintainers spent months migrating.

That was the end of a security-hardening effort underway since at least late 2023, and it was grounded in real research. JFrog's Black Hat 2024 work showed load_dataset would execute a remote Python script from the Hub by default, no flag and no prompt. During that research period Hugging Face changed 2.20.0 to require trust_remote_code=True, then deleted the capability a year later.

Notice the order. The Hub had already stopped rendering script-backed datasets well before either library change, with an error message that said the quiet part plainly: the viewer is disabled because this dataset repo requires arbitrary Python code execution. Hugging Face stopped its own infrastructure from executing that content first, and got users to stop depending on it second.


Which makes the rest of it strange. The library work primarily protected the person calling load_dataset. The flag, the removal, the migration guidance, all of it reduced the risk that hostile dataset content would execute somewhere you controlled. Your laptop, your CI runner, your training pipeline. That was the surface the research had documented, so that was the surface that got hardened, thoroughly enough to leave broken tutorials, integrations and benchmark loaders across the ecosystem.

But Hugging Face still has to read those datasets. It cannot run a dataset platform otherwise. Automated services on their side parse uploaded datasets, generate previews and run conversions. That path takes the same hostile input the library was hardened against. The failure was not that they process datasets. It was that separate execution paths inside that processing stayed reachable, on a platform that had understood the danger of exactly this content class since late 2023.


I doubt we get a clean answer about those paths, and it's worth saying why.

Read OpenAI's disclosure as a document rather than a confession. It links their trusted-access-for-cyber program repeatedly, includes a UK AI Security Institute capability chart, and closes by urging defenders to apply for access now. Hugging Face's contribution is a CEO quote about open-source AI safety. Neither spends remotely comparable space on the template injection, the loader, or the dataset-processing architecture that made any of it reachable.

The two accounts also do not yet map cleanly onto each other. OpenAI describes stolen credentials and zero-days chained into a remote code execution path. Hugging Face describes a malicious dataset abusing two code paths in its pipeline. Probably the same events narrated from opposite ends, but neither company has published enough to reconstruct the join.

Here is the line that should bother you more than any capability chart: the incident "makes clear that advanced models can discover and exploit novel attack paths in real-world systems without source-code access."


What I can't tell you, as of July 21. Which loader. Which template engine. Which configuration field. Whether the vulnerable configuration was the public YAML mechanism that replaced loading scripts or something internal that shares a name and nothing else. Hugging Face has not said, and I won't guess. Neither company has published CVE or advisory identifiers for either path, or indicators of compromise, though Hugging Face says its analysis extracted them. Both describe the investigation as ongoing.

So the claim I'll defend is narrow. Removing dataset scripts fixed the client. The server side still had to take hostile input, and separate execution paths there stayed reachable.

The panic this week will be about attackers acquiring AI. The thing underneath is stranger. Nobody assigned Hugging Face to anything. The models assigned it to themselves, because getting through its production boundary looked like a reasonable step toward a higher score. It was.

If you run anything that ingests user-controlled content, the deprecation you shipped protected your users. Go find out what it did for your workers.

More from this blog