Hugging Face: Over the router, through the firewall, off to Grandma's house we go

We wrote this post as a byproduct of working to understand what this event is all about. There are lots of other writeups, but this one is ours. It separates claims that are independently verifiable from claims that rest solely on the accounts of the two companies involved. Both of the companies involved have described their findings as preliminary, and their two accounts do not fully reconcile on all points, so it’s possible that we’ll need to revise this post in the future.

Hugging Face published an incident disclosure on Thursday 16 July 2026 [1]. It stated that earlier that week it had identified unauthorised access to a limited set of internal datasets and to several credentials used by its services [1][3].

OpenAI published a related disclosure on Tuesday 21 July 2026, stating that its own models were responsible for the activity Hugging Face had detected [2][7]. This attribution was reported the same day by Axios, Fortune, Unite.AI and others [6][7][8][9].

OpenAI stated that the incident was driven by a combination of its models, naming GPT-5.6 Sol and a more capable pre-release model, and that these were running with reduced cyber refusals for evaluation purposes [2][7][8].

Broadly, there can be two separate safety layers in play:

1. Refusals are the model’s own trained behaviour, declining to comply.
2. Classifiers or filters sit outside the model at deployment time, inspecting inputs and outputs and blocking them.

OpenAI stated that its models’ activity occurred during an internal evaluation that tasks models with advanced exploitation; the models were run without the production classifiers that would normally prevent high-risk cyber activity, in order to estimate maximal capability. It stated that the benchmark involved was ExploitGym [2][10][11]. ExploitGym is described by OpenAI as a benchmark created by UC Berkeley researchers in collaboration with OpenAI and other frontier labs [10][11].

The ExploitGym paper describes the benchmark as providing the agent with vulnerable source code and build instructions, an input that already triggers the bug, and a containerised environment in which to interact with the target, then tasking the agent with extending that input into a working exploit [11][18].

As an aside, GPT-5.6 Sol appears on the public ExploitGym leaderboard with a (self-reported) score of 0.337, meaning it was successful in creating working exploits for roughly a third of the instances attempted [20]. So what? Well, in May, just a few months ago, the strongest models measured managed roughly 13% to 17%, so 34% represents roughly a doubling of capability in just two months.

Anyhow, back on track: OpenAI’s account of the chain of events is as follows [2]:

• The evaluation ran in an isolated environment whose network access was limited to a proxy and cache for package registries.
• The models identified and exploited a previously unknown vulnerability in that package registry cache proxy, described by OpenAI as internally hosted third-party software, which OpenAI stated it has since disclosed to the vendor.
• The models then performed privilege escalation and lateral movement within OpenAI’s research environment until reaching a node with internet access.
• After gaining internet access, the models inferred that Hugging Face might host models, datasets, and solutions for ExploitGym.
• The models then chained multiple attack vectors, including stolen credentials and zero-day vulnerabilities, to reach a remote code execution path on Hugging Face’s servers.

OpenAI characterised the models as hyperfocused on obtaining a solution to the benchmark. It stated that its own security team discovered the anomalous activity internally, and that Hugging Face’s team had already begun containment and forensic reconstruction using its own open-source models when the two teams connected [2][8].

OpenAI stated remediation and follow-up actions including tightening infrastructure controls at the cost of slowing its research, responsibly disclosing the identified zero-day in the third-party proxy software, and adding Hugging Face to its trusted-access cyber programme [2][7]. Fortune reported that this programme gives Hugging Face access to a version of GPT-5.6 Sol with fewer guardrails around cyber capabilities, intended for defenders [7].

OpenAI stated that the models chained vulnerabilities across OpenAI’s research environment and Hugging Face’s production infrastructure to obtain test solutions directly from Hugging Face’s production database [2]. That seems to answer the question of why Hugging Face was targeted: The LLM believed Hugging Face held benchmark solutions, and the models sought to obtain them.

The step that led there was inferential. OpenAI’s wording is that the models inferred Hugging Face potentially hosted models, datasets, and solutions for the benchmark [2], while the publicly documented distribution point for the ExploitGym harness and dataset is its GitHub repository [19]. The models reasoned their way to a location that was not the documented one, and found an alternative path instead.

On a related point, the disclosure reports have not explained why material sufficient to solve the benchmark would not already have been available to the models, given that the ExploitGym harness and dataset are publicly published [19]. Whether the internal evaluation used non-public instances, withheld information, or a private split is not addressed in the disclosure.

Hugging Face’s public disclosure does not specify whether the remote-code dataset loader it refers to is the client-side dataset loading-script mechanism or an internal server-side processing path. This distinction is relevant because the client-side mechanism had already been removed from the datasets library before the incident [12][13].

Neither company has published indicators of compromise at the time of writing [17].