Your Model's Name Isn't a Security Guarantee

How the takeover works

There are two versions of this attack, and the second one is worse.

Deletion reuse. An org publishes a model, gets some traction, then deletes their Hugging Face account — company shuts down, team moves on, whatever. The namespace doesn't get retired. It goes back into a public pool. Anyone can claim "DentalAI" and upload a model under the exact path your code already references. Your from_pretrained("DentalAI/toothfAIry") call now pulls someone else's weights. You'll notice something's wrong eventually — the model was gone for a while first, a 404 before the hijack — but you'll notice after you deploy it.

Transfer reuse is the quieter one. When a model's ownership legitimately transfers — an acquisition, a rebrand — Hugging Face redirects the old namespace to the new one automatically, so nobody's code breaks. Sensible design. But if the original org then deletes itself, as orgs that just got acquired tend to do, that old namespace is available again. Register it, upload a poisoned model under the old name, and you've broken the redirect in your favor. Every pipeline still pointed at the old path — which is most of them, because nobody goes back and updates a string that "still works" — gets your model instead. No downtime. No error. No signal that anything changed.

Unit 42 demonstrated this against Google Vertex AI and Azure AI Foundry, both of which pull directly from Hugging Face into their model catalogs. They also found the same reusable-namespace pattern hardcoded across thousands of open-source repos — in from_pretrained() calls, in default arguments, in example notebooks nobody re-reads after the model ships.

Why this matters more for SLM teams

If you're fine-tuning or quantizing a small language model, you're probably pulling a base model from a public hub, running it through your pipeline, and shipping the result. That base model is a dependency. Most teams don't treat it like one.

We think about model behavior changing across a pipeline constantly — a model that passes safety checks at the base stage can fail them post-quantization, and that drift is the whole reason quantization-aware testing exists. Namespace reuse is the same failure mode one layer down: it's not that the model's behavior changed, it's that the model itself did, silently, underneath a name you had every reason to trust.

A name was never identity. It was just a label you agreed to trust.

What to actually do about it

• Pin to a commit, not a name. from_pretrained("Author/ModelName", revision="abcdef123...") locks you to a specific artifact. A bare name string will always fetch whatever currently sits at that path — trusted or not.
• Clone after you vet, not before. For anything production-facing, pull the model into storage you control once, after review, and stop depending on the upstream path at all.
• Scan your codebase for hardcoded model references the same way you'd scan for a vulnerable package version. They hide in default arguments and docstrings, not just import statements.
• Treat orphaned upstream orgs as a signal. If the author behind a model you depend on no longer exists on the platform, that dependency is now unclaimed territory. Someone will eventually claim it. Better if it's you noticing first.

None of this is exotic. It's the same supply-chain discipline that eventually became standard practice for npm and PyPI, arriving late to model registries because the ecosystem is younger. The attack surface isn't new in kind — it's new in target.

Your users shouldn't be your first red team. Neither should your model registry.