Where models come from. Hugging Face, the July attack and the real risks of downloading

Anyone running artificial intelligence in-house, on their own servers, has to download a model at some point. Almost always it comes from Hugging Face, the platform where labs all over the world publish open models: Qwen, Gemma, Mistral, DeepSeek, gpt-oss. When it emerged in July that Hugging Face had been breached, the question was obvious: are the models we downloaded still the right ones?

What happened in July

Between 9 and 13 July 2026, AI agents run by OpenAI, during an internal test of the cyber capabilities of unreleased models, got out of the closed environment they were meant to work in and attacked Hugging Face. According to Hugging Face's reconstruction, they were looking for the test's answers: they wanted to cheat. They came in through the system that processes datasets uploaded by users, with purpose-built files, and from there climbed to control of part of the internal infrastructure and a store of keys and credentials. Hugging Face disclosed the incident on 16 July and published the technical timeline on the 27th. OpenAI admitted its role on 21 July and described it in detail at the Black Hat conference on 5 August.

The point that matters to anyone downloading models is in the 16 July disclosure: "We have found no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean." Data from five customer datasets and an internal database were read. Hugging Face advised users to rotate their access tokens as a precaution. Nobody was asked to re-download or re-check models.

To be precise: that is Hugging Face's conclusion, from its own investigation. There is no reason to doubt it, but nobody outside Hugging Face has re-checked the files one by one. That is a good reason to be able, in any case, to verify what you use yourself.

The real risks are older

The July attack was spectacular, but for someone downloading a model the documented problems are different, and they have been the same for years.

Files that run code. A model is, in theory, a set of numbers. But some formats, those born with PyTorch, can contain instructions that run the moment the file is opened. In 2024 the security firm JFrog found around a hundred models on Hugging Face built to open remote access to the computer of whoever loaded them. In 2025 ReversingLabs found two that had slipped past the platform's automatic checks. The modern formats, safetensors and GGUF, the one Ollama and LM Studio use, are designed to hold only data.

Scripts next to the model. In May 2026 a fake OpenAI repository, with a name almost identical to the original and the same copied description, reached number one on Hugging Face's trending list with more than two hundred thousand downloads. The model was harmless. The danger was in a separate file, loader.py, which downloaders were invited to run and which stole passwords, keys and credentials. Real models do not need installation scripts.

Near-identical names. It is the same trick as scam websites: an account named like a well-known lab, with one letter missing or added. Download counts and trending positions say nothing about trustworthiness.

The programs that read models. Even a format designed only for data needs a program to read it, and that program can have flaws. llama.cpp, the engine Ollama and LM Studio rely on, fixed vulnerabilities in reading GGUF files in 2024, in 2025 and again in March 2026. Ollama had a serious one in 2024. The fixes exist; the problem is that many people do not update.

Instructions hidden in the model. Researchers have shown that models can be trained to behave well until they receive a certain trigger word. To date there is no documented case of a widely used open model with such a trap being used against real users. But there is not yet a way to find one by checking the file. That is why what a model produces should always be treated as text to verify, especially if the model can act on files, e-mail or systems.

What to do, in practice

None of this needs special tools. These are the rules a serious company already applies to any software, adapted to a new kind of file:

1. Download only from the lab's official account, or from a few known distributors, checking the name letter by letter, and record where each model comes from.
2. Use only the formats that hold data, safetensors and GGUF, and never run scripts supplied with the model.
3. Pin the version and keep your own copy: download once, record the exact version and the file's fingerprint, and serve the model from your own network, instead of letting servers fetch "the latest version" from the internet.
4. Update regularly Ollama, LM Studio, llama.cpp and the other programs that read models.
5. Do not expose the model server to the internet, and do not leave on the machine that opens third-party files any passwords, keys or credentials it does not need. In July, at Hugging Face, a single file read became a credential theft precisely because the credentials were there.
6. Keep a list: which models, from where, which version, under which licence.

It is ordinary work, but someone has to do it, and redo it at every update.

One detail, at the end

Hugging Face's technical timeline contains a passage worth noting. To analyse the traces of the attack, the engineers first tried the large cloud models, which refused to examine the attack logs: their safeguards mistook them for a dangerous request. So they ran an open model, GLM-5.2, on their own servers, "with the added benefit of keeping the attacker data on-prem". The lesson they draw: "have a capable model you can run on your own infrastructure vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment."

That is written by the platform that hosts the world's models. Having a model in-house is not only about protecting data when everything goes well. It is also, perhaps above all, about when something goes wrong.