The bug is in the reference, not the model

Hugging Face identifies models as Author/ModelName. That string is the reference your code carries — in a config, a default argument, a deployment template.

It looks like an identifier. It behaves like a pointer to whoever currently holds that name.

When an author or organisation deletes their Hugging Face account, the namespace doesn't get retired. It returns to the pool, and anyone can register it. An attacker takes the abandoned name, uploads a model at the original path, and every pipeline still resolving that reference by name fetches their version instead. No compromise of the original account required — it doesn't exist anymore. That's the point.

Unit 42 at Palo Alto Networks published this as Model Namespace Reuse on 3 September 2025, credited to Itay Saraf and Ofir Balassiano.

Two ways in

Deletion. The account goes away, the namespace frees up, someone else takes it.

Transfer, then deletion. Hugging Face redirects renamed and transferred repositories to their new home — its own documentation confirms this, noting that download counts and likes carry across. Useful behaviour, and it means old references keep working after a legitimate move.

But if the original author's account is later deleted and someone re-registers it, the redirect stops applying. The reference resolves to whoever holds the name now. A pointer that used to be forwarded is quietly repointed.

What the researchers actually got

Not a theoretical writeup. They found orphaned models still listed in major cloud catalogues, registered the namespaces, and demonstrated execution:

• Google Vertex AI Model Garden — reverse shell execution.
• Microsoft Azure AI Foundry Model Catalog — deployed a model and obtained endpoint access to the underlying infrastructure.

Both platforms ingest models from Hugging Face. Neither had done anything wrong in its own code — they trusted a name that had changed hands.

Beyond the clouds, Unit 42 reported thousands of susceptible repositories, including well-known and heavily starred projects. The references weren't always where you'd look: they turned up in default parameter values, docstrings and comments — places a dependency scanner isn't reading.

Where it stands

Google now scans daily for orphaned models and marks them "verification unsuccessful" to block deployment.

Microsoft and Hugging Face received the disclosure. Unit 42's assessment at publication was that mitigations were incomplete and the underlying problem persists.

As of today, 5 August 2026, I could not find any Hugging Face announcement that deleted namespaces are now permanently reserved. Absence of an announcement isn't proof the behaviour is unchanged — but if you're relying on it having been fixed, verify that yourself rather than assuming.

What to do about it

Pin to a full commit hash. The huggingface_hub download guide documents a revision parameter accepting a branch, tag, PR reference or commit hash. A hash pins you to exact bytes — a re-registered namespace serving different content won't match. One trap worth knowing: the docs specify the full-length hash, not the 7-character short form git normally gives you.

hf_hub_download(
    repo_id="author/model",
    filename="config.json",
    revision="877b84a8f93f2d619faa2a6e514a32beef88ab0a",
)

Mirror what you depend on. Verify a model once, then serve it from an internal registry. Production shouldn't reach out to a public namespace at deploy time.

Grep wider than you think you need to. Model references hide in defaults, docstrings and comments. A scan targeting only requirements files will miss them.

My read

This section is my own assessment, not part of the reported research.

The interesting thing here isn't the technique — it's repojacking, well understood in package registries for years. It's that the AI ecosystem rebuilt the same trust assumption from scratch and shipped it into cloud model catalogues.

Package managers learned this lesson expensively: npm and PyPI now restrict re-registration of deleted names precisely because the name outlives the owner. Model hubs arrived at "reference by mutable name" without inheriting that history.

And the AI case is worse in one specific way. A poisoned npm package runs in your build. A poisoned model gets loaded by a process that, by design, already has access to your data, your GPUs and often your cloud credentials. The blast radius is bigger, and the artefact — a weights file — is far less likely to be read by a human before it executes.

If you run models in production, the version-pinning question is not really about namespace reuse. It's whether you can currently state which exact bytes are running. Most teams can't, and that gap is the actual exposure.

Sources

• Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust — Unit 42 — the original research: mechanics, both vectors, the Vertex AI and Azure demonstrations, vendor responses and recommended defences.
• AI Supply Chain Attack Method Demonstrated Against Google, Microsoft Products — SecurityWeek — independent reporting corroborating the method, affected products and scope.
• Repository Settings — Hugging Face docs — confirms rename and transfer auto-redirect behaviour and that download counts and likes are preserved.
• Download files from the Hub — Hugging Face docs — the revision parameter, accepted values, and the full-length commit hash requirement.