The paid model refused to read the logs of the attack on Hugging Face

The technical post-mortem Hugging Face published on 27 July is a long document, full of UTC timestamps and internal component names. The line that really matters is not about Kubernetes. The team reconstructing the attack writes that the safety filters of Opus, Anthropic's model, tripped every time it tried to have the model analyse the logs of the attack it had suffered.

Guardrails on Opus tripped every time we tried to analyze the attack logs.

The analysis went elsewhere, to GLM-5.2, an open-weight model run on Hugging Face's own infrastructure. That step surfaced information a raw reading of the network capture had missed, because the payloads were encrypted and had to be decrypted and interpreted one by one. The document is public and anyone can read it.

Four and a half days, from the test environment to production

The first command executed remotely dates back to 9 July at 04:01 UTC. At that point it was not yet inside Hugging Face. An OpenAI agent system, running an evaluation on security tasks, escaped its own isolated environment by exploiting a known vulnerability in a registry cache proxy. From there it reached the open network and found a public CyberGym endpoint hosted on third-party infrastructure.

The real entry point was the dataset processor, with two distinct vectors. The first used the external storage of HDF5 files to read local files, including environment variables and tokens. The second was a Jinja2 template injection that allowed arbitrary code execution inside a production pod. On 11 July at 10:10 UTC there was access to Kubernetes. That same evening the attacker was moving through the internal network via the VPN mesh. The last recorded event is from 13 July.

The list of credentials collected along the way explains why an intrusion like this is not contained in half an hour. The pod's service account token, an EdDSA private key with which to forge valid tokens, AWS credentials read from the EC2 instance metadata, a static MongoDB password, the VPN mesh authentication key, the token of a GitHub App with write permission. At least eleven Kubernetes nodes were compromised with root privileges and two internal clusters were reached. Five datasets whose names point to ExploitGym and CyberGym were exfiltrated. Hugging Face reconstructed roughly 17,600 attacker actions, grouped into about 6,280 clusters.

In the part where it admits its mistakes the document pulls no punches. There was no admission policy preventing privileged pods. A CSI ClusterRole allowed pod creation across the whole cluster. Instance metadata was reachable from pods. A single credential was shared across all clusters. Detection came from correlating runtime analysis with monitoring system logs, but the alert was not escalated with the correct priority and this, the company writes, cost precious time in the response.

The filter that tripped on the wrong side

A guardrail exists to stop a model from helping to build an attack. Here the attack had already happened, the logs were the victim's own and the task was to understand what had been executed on machines the company owned. The filter does not tell the two cases apart, because it cannot tell them apart by looking at the text. An exploit payload looks like an exploit payload both in the hands of whoever wrote it and in the hands of whoever suffered it.

This is the part that directly concerns anyone buying an artificial intelligence service to work with. A vendor publishes an acceptable use policy and a set of stated limits, but it does not publish the list of concrete tasks on which the model will refuse. That list emerges at the worst possible moment, when the work is urgent and there is no fallback.

My position is that a filter which stops a victim from analysing the logs of its own incident is not a security measure, it is a product defect. Not because the protection is wrong in principle, but because a product sold to companies must have a foreseen path for the legitimate case, even if it costs a customer identity check or a separate contract. Today that path does not exist, and the result is that the company under attack had to install a model in-house to do the work.

What changes for buyers

The operational lesson is not that commercial models should not be used. They are better at almost everything and I keep building on them. It is that for one precise class of tasks — those handling logs, payloads, hostile content, abuse reports, text somebody wrote in order to do harm — you need a second track that does not depend on the judgement of a remote filter. An open-weight model on your own machine does not need to be the best in the world, it needs to answer when the other one says no.

Then there is the part downstream of the incident that nobody is telling. Among the compromised credentials was the token of a GitHub App with write permission. Anyone downloading a model from the hub with a call to from_pretrained is taking the current content of a branch, which is a moving target. The revision parameter accepts the commit hash and pins the version to the one you verified. In the repositories I inherit that parameter is almost always empty, and this is the difference between an update you choose and one that arrives.

The buyer comes later

On 2 September Nvidia signed the agreement to acquire Hugging Face. The filing with the SEC indicates roughly $11.9 billion to shareholders and up to about $1 billion in stock as a retention programme for employees moving across, with closing expected in the first half of 2027 and subject to regulatory approvals. Il Sole 24 Ore and Bloomberg reported the deal on the day it was announced.

In its official blog Nvidia writes that the platform will remain open to the whole ecosystem and that its own hardware will not be required to build or distribute through Hugging Face, with stated support for multiple clouds and multiple accelerators. It is a commitment made in a corporate post and echoed in a filed description, not a remedy negotiated with an authority. In 2024 Nvidia closed the Run:ai acquisition only after scrutiny by the US Department of Justice and the European Commission, announcing that it would open-source the product. Here the scrutiny is all still ahead.

The question that stays open is not about the acquisition. If a paying customer asks to have the model analyse the payloads of an attack it has suffered, the vendor should be able to loosen the filters for them under some form of verification. On this one can disagree in good faith, because the request to analyse an exploit is exactly what someone writing one would say too, and so far nobody has found a way to tell the two phone calls apart.