CyphrQ
Menu

Hugging Face Spaces Breach 2024: What Happened and What to Change

What Hugging Face said about unauthorised access to Spaces secrets in May 2024, what is unknown, and how AI teams should handle tokens and CI/CD secrets.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Incident: May 202410 min read

What was the Hugging Face breach? In late May 2024, Hugging Face detected unauthorised access to its Spaces platform, the part of the Hub where people host machine learning demos. It suspected that some Spaces "secrets", the stored passwords and API tokens those apps use, had been read. It revoked a number of tokens and told affected users by email. It has not published how many.

This is a case file. It sets out what Hugging Face itself said, what it did not say, and what AI teams should change in how they store and rotate tokens.

Case file

Field Value
Organisation Hugging Face (AI model and dataset hosting platform, "the Hub")
Region Global platform
Breach date Detected "earlier this week" per a post dated 31 May 2024, so the week of 27 May 2024. The exact date is not given (Hugging Face)
Disclosed 31 May 2024, in Hugging Face's own blog post "Space secrets security update" (Hugging Face)
People affected Not stated. The post gives no count of secrets, revoked tokens or users (Hugging Face)
Data types Spaces secrets: stored credentials such as tokens and API keys. Hugging Face says it "suspects" a subset could have been accessed
Attacker Not identified in the sources we read
Method of entry Not stated in the sources we read
Penalty/action None found. Hugging Face says it reported the incident to law enforcement and data protection authorities. We found no regulator statement or enforcement action
Status No final forensic report found. We found no later Hugging Face update specific to this incident

When did the Hugging Face Spaces breach happen, and what did the company say?

Hugging Face published its notice on 31 May 2024. The core sentence is: "we have suspicions that a subset of Spaces' secrets could have been accessed without authorization" (Hugging Face).

Two things stand out. First, the wording is cautious. Hugging Face says "suspicions" and "could have been accessed", not that it confirmed theft. Second, the post names the Spaces platform and Spaces secrets only. It does not describe a wider compromise of models, datasets or accounts.

The post also says what the company did:

  • It revoked a number of Hugging Face tokens found in the affected secrets, and emailed the affected users.
  • It brought in outside cybersecurity forensic specialists to investigate and review its security policies and procedures.
  • It removed organisation tokens, which it says improves traceability and audit.
  • It put a key management service (KMS) in place for Spaces secrets.
  • It improved its ability to spot leaked tokens and invalidate them proactively.

(All from the Hugging Face post.)

What was exposed in the Hugging Face Spaces incident?

Spaces secrets. Hugging Face's documentation explains what those are: values you add in a Space's settings for "access tokens, API keys, or any sensitive values or credentials". Once set, their value cannot be read back from the settings page, and they are exposed to the running app as environment variables (Hugging Face docs).

So the risk is not the Spaces themselves. It is what the secrets give access to elsewhere. A team that stored a Hugging Face write token, a cloud storage key or a third-party model API key in a Space has handed that credential to the platform. If the platform's storage is read, the credential is read with it.

What we cannot tell you:

  • How many secrets or tokens were taken. Hugging Face gave no number.
  • Whether any exposed credential was misused. The post does not say.
  • Who did it, and how. The post names no attacker and no technique.

Some press coverage speculated about the cause. We have not repeated it, because Hugging Face's own post does not support it.

Who was at risk, and what did Hugging Face tell users to do?

Anyone who had stored a secret in a Space was a possible target. Hugging Face's advice was short: "We recommend you refresh any key or token and consider switching your HF tokens to fine-grained access tokens" (Hugging Face).

It also said it plans to deprecate "classic" read and write tokens once fine-grained tokens reach feature parity. Fine-grained access tokens were already the default when it wrote the post.

Hugging Face's token documentation explains why that matters. A read token reads every repository you can read. A write token adds write access to every repository you can write to. A fine-grained token is limited to named resources, "such as a specific model or models in a specific organization" (Hugging Face docs). The docs recommend fine-grained tokens for production use, because "the impact, if leaked, will be reduced".

Is this the same as the 2023 exposed Hugging Face tokens research?

No. It is a different event, and the difference matters.

In December 2023, the security firm Lasso Security published research on Hugging Face API tokens it found exposed in public code. Lasso's figures, from its own post (Lasso Security):

Lasso's finding (research done November 2023) Figure
Valid tokens found through Hugging Face and GitHub 1,681
Organisation accounts the researchers could access 723
User tokens with write permission 655 (77 of them to various organisations)
Datasets with write access 14

Lasso says it told Hugging Face, which fixed the issue so that org_api tokens could no longer be used for reading, and that organisations including Meta, Google, Microsoft and VMware revoked tokens on the day of its report. Lasso gives no date for the fix. These are the researchers' own claims, and we did not verify them independently.

The two events share a lesson: a long-lived token with broad rights is one leak from becoming an incident. Careless storage in public code, and a platform-side incident, can end in the same place.

Has Hugging Face had other security incidents since?

Yes, and it is separate. On 16 July 2026, Hugging Face published a disclosure of a different intrusion. It says the attacker entered through a malicious dataset that abused two code-execution paths in dataset processing, and that "a limited set of internal datasets" and several service credentials were accessed (Hugging Face). That post does not mention the 2024 Spaces incident, and we do not link the two.

Separately, a March 2025 Hugging Face post on its secrets management refers to "a security incident that involved exposed credentials" without giving a year (Hugging Face). We cannot tie that sentence to the 2024 Spaces incident, so we don't.

Going deeper: for security and IT teams

Threat model. The attacker wants credentials that work elsewhere. A Space secret is attractive because it is typically a high-value token, such as a Hub write token, a cloud key or a paid model API key, stored in one place on a platform the attacker does not need to be inside your network to reach. What they need is read access to the platform's secret store. What they get is whatever each stored credential permits, for as long as it stays valid.

Why token scope decides the damage. Hugging Face documents three roles: read, write and fine-grained. A leaked write token lets the holder change every repository its owner can write to, including model weights other people download. The docs warn that while you can rotate a token, "anyone will be able to read or write your private repos in the meantime" (Hugging Face docs). Practical settings:

  • Create one token per app or use, so you can revoke one without breaking the rest. Hugging Face recommends this.
  • Use fine-grained tokens scoped to the exact repositories a Space needs, with read-only permission where the app only downloads.
  • Do not store a personal token with write access in a demo Space. Make a narrow token for that Space alone.
  • Keep a register of which Space or pipeline holds which token, so rotation after an incident takes minutes, not days.

Secret scanning. Hugging Face runs TruffleHog on every push to a Space and emails the owner when it finds a secret verified as working. Unverified findings do not trigger an email, and the docs warn they are "not necessarily harmless or invalid" (Hugging Face docs). Add your own scan in your repository: run a scanner such as TruffleHog as a pre-commit hook and in CI, and treat any verified hit as a rotation event, not a cleanup task. If you find someone else's exposed Hugging Face token, the documented POST /api/credentials/revoke endpoint invalidates it without any rights over the owner's account (Hugging Face docs).

Where a Space secret can leak besides the platform. For Static Spaces, Hugging Face documents that variables and secrets are available through client-side JavaScript in window.huggingface.variables (Hugging Face docs). Read that carefully: do not put anything in a Static Space that you would not put in a web page. Variables are public by design. Secrets are for sensitive values and are not copied into Spaces duplicated from yours.

CI/CD secrets for ML pipelines. A stored HF_TOKEN in a CI system is a long-lived credential in a second place. Hugging Face's Trusted Publishers feature removes it. Your CI job presents a short-lived OpenID Connect (OIDC) identity token, and Hugging Face returns a Hub token that, per its documentation, lasts 60 minutes and is scoped to one repository. The docs compare it with a personal access token: lifetime "until revoked" versus one hour; if leaked, valid until you revoke versus about an hour (Hugging Face docs). The exchange follows RFC 8693 (OAuth 2.0 Token Exchange), and claims are matched exactly, with no regex or prefix matching. Pin the publisher to a repository, and add branch or workflow as the docs recommend. Supported providers include GitHub Actions, GitLab CI, CircleCI and Bitbucket Pipelines.

Detection and evidence. Hugging Face says it removed organisation tokens to improve traceability and audit. On your side:

  • Review token last-used times and your repository commit history for pushes you do not recognise, especially to model files.
  • After any vendor notice about exposed secrets, rotate everything that platform held, not only the credential type named.
  • Test your rotation: pick one token, revoke it, and time how long it takes to restore every service that used it.
  • Check whether any model or dataset you publish could be altered with a leaked write token, and who would notice.

What to verify or ask.

  • Which credentials do we keep in third-party platform secret stores, and which of them are broad write tokens?
  • Can a pipeline use short-lived OIDC tokens instead of a stored one?
  • When a platform emails us about a revoked token, who receives it, and does that mailbox have an owner?
  • How fast can we rotate every token we hold on a given platform?

What should AI teams change after the Hugging Face Spaces breach?

  1. List every token you have stored in Hugging Face Spaces, and in any platform's secret store, with its scope and owner.
  2. Replace classic read and write tokens with fine-grained tokens limited to the repositories each app needs.
  3. Rotate any key or token that was ever stored in a Space, as Hugging Face recommended in May 2024.
  4. Move CI/CD from stored HF_TOKEN secrets to short-lived OIDC exchanges where your provider supports it.
  5. Scan every repository and Space for hard-coded secrets, and treat a verified hit as a rotation event.
  6. Practise one rotation and time it.

For how stolen logins turn into account takeover more broadly, see how infostealers steal session tokens.

Key takeaways

  • Hugging Face detected unauthorised access to its Spaces platform in the week of 27 May 2024 and said on 31 May 2024 that it suspected a subset of Spaces secrets could have been accessed.
  • Hugging Face gave no count of affected secrets or users, and named no attacker or method. We found no later update or regulator action specific to this incident.
  • It revoked a number of tokens, emailed affected users, reported the incident to law enforcement and data protection authorities, and added a key management service for Spaces secrets.
  • Its advice: refresh every key or token and move to fine-grained access tokens.
  • Separate research by Lasso Security in December 2023 reported 1,681 valid tokens exposed through Hugging Face and GitHub. It is a different event, with the same lesson about broad, long-lived tokens.
  • The cheapest fixes: narrow token scopes, one token per app, secret scanning in every repository, and short-lived OIDC tokens in CI.

Sources