Two years of Hugging Face credential exposure: what the Spaces breach and the Lasso token research actually showed

Two separate incidents, six months apart, tell the same story about the AI supply chain from different angles: in December 2023, Lasso Security researchers found more than 1,500 exposed Hugging Face API tokens sitting in public code, and in June 2024, Hugging Face itself disclosed unauthorized access to its Spaces platform that may have exposed a subset of Spaces secrets. Neither incident is a smoking-gun report of a model being poisoned in the wild. Together, though, they describe exactly the kind of access a poisoning attack would need — and show that access has, at different points, been sitting in the open or plausibly reachable by an unauthorized party.

The Lasso Security findings: exposure at a scale worth taking seriously

In December 2023, Lasso Security published research from scanning public code repositories for exposed Hugging Face API tokens. They found over 1,500 of them, granting access into 723 organizations' accounts — including Meta, EleutherAI, and BigScience Workshop, names behind some of the most widely used open models and datasets in the ecosystem. Of those 1,500-plus tokens, 655 carried write access: the ability to modify files in the associated repositories, not just read them.

It's important to be precise about what this research does and doesn't establish. Lasso's report is a study in exposure — tokens that were sitting in plain sight in public code, discoverable by anyone running the same kind of scan Lasso ran. It is not a report that any of those 655 write-capable tokens were actually used to alter a model, insert a backdoor, or otherwise tamper with a repository. There's no confirmed poisoning incident attached to this finding.

What the finding does establish, clearly, is the shape of the risk. A write-access token to a widely-used model repository is not a minor credential. If an organization like the ones named had a token compromised through this kind of exposure — and there's no reporting that any specifically was — the plausible outcome is a targeted supply-chain attack: a small, deliberate modification to a model or dataset that millions of downstream users and applications pull in as a trusted dependency. That's a materially different threat than a leaked read-only token, and it's why write-scoped credentials deserve tighter handling than the rest of an org's token inventory.

The June 2024 Spaces breach: Hugging Face's own infrastructure

Six months later, in roughly the same window as the Lasso findings might have prompted broader scrutiny, Hugging Face disclosed unauthorized access to its Spaces platform. The company said it suspected a subset of Spaces secrets — the API keys and tokens Spaces apps use to reach Hugging Face and other services — could have been accessed without authorization. This wasn't a report of tokens scraped from public code; it was Hugging Face's own hosting infrastructure being accessed by a party who shouldn't have had access.

Hugging Face's response was to revoke and rotate the affected tokens, and then to make structural changes rather than treat it as a one-off cleanup. The company introduced a Key Management Service (KMS) specifically for Spaces secrets, moved away from org-wide tokens in favor of fine-grained tokens scoped to what a given integration actually needs, and expanded automatic detection and invalidation of leaked tokens across the platform. Each of those changes maps directly onto a way the Lasso-style exposure could recur: KMS reduces the blast radius of infrastructure-level access, fine-grained tokens reduce what any single leaked credential can do, and automatic leak detection shortens the window between exposure and revocation.

Reading these two incidents together

Neither the Lasso research nor the Spaces breach, on its own, proves that a real-world model-poisoning attack has happened via a compromised Hugging Face token. What they establish together is that the precondition for such an attack — a write-capable credential to a trusted repository, reachable by someone who shouldn't have it — has existed at meaningful scale (1,500+ tokens, 723 organizations) and has also occurred at the infrastructure level (the June 2024 breach), independent of individual users leaking their own credentials.

This is the recurring shape of AI supply-chain risk: it rarely shows up as a single dramatic breach with a confirmed victim count. It shows up as exposure research finding hundreds of live, write-capable credentials, and as a platform disclosing that its own secret-storage layer was touched by someone unauthorized. Whether either specific event was ever weaponized into an actual poisoned model is, per the public record, unknown — and that unknown is itself the risk. A poisoned dependency in a widely-reused model doesn't necessarily announce itself the way a leaked database does.

What to check this week

• Audit every Hugging Face token in your organization's CI/CD, notebooks, and public repos for scope. Any token with write access to a model or dataset repo should be treated with the same handling rigor as a production deploy credential, not a convenience API key.
• Replace org-wide or broadly-scoped tokens with fine-grained tokens, matching Hugging Face's own post-2024 hardening direction — a token should be able to do only what the specific integration using it needs.
• Scan your own public repositories, notebooks, and CI logs for accidentally committed HF tokens, the same class of exposure Lasso found at scale across hundreds of organizations in December 2023.
• Confirm secret rotation cadence for any Spaces or third-party integration secrets, and don't assume a credential is safe simply because you haven't seen an alert — automatic leak detection catches known patterns, not every path to exposure.

How Safeguard helps

Safeguard's AI-BOM and AI-SPM discovery is built to surface exactly this kind of exposure before it becomes an incident report: which model and dataset repositories your organization depends on, which credentials have write access to them, and where those credentials might be sitting in code, configuration, or CI logs rather than a proper secrets store. That visibility matters most for the risk this pair of incidents illustrates — a compromised write-access token to a trusted, widely-used repository is a realistic vector for a targeted model-poisoning attack, even in the absence of a confirmed case, and continuous monitoring of dependency provenance is how you catch a quietly-modified upstream artifact rather than discovering it after it's already shipped downstream.