Safeguard
AI Security•

Hugging Face Spaces secrets incident (May 2024): what was disclosed

What Hugging Face said about unauthorized access to Spaces secrets in May 2024, what it changed afterwards, and what the disclosure left unstated.

Safeguard Security Team
3 min read

In a post dated 31 May 2024, Hugging Face said it had detected unauthorized access to its Spaces platform, specifically to Spaces secrets, and that a subset of those secrets may have been accessed. It revoked some tokens, notified affected users and told everyone to refresh keys.

What the company stated

The post says the access was detected earlier that week. The scope was described as a suspicion: a subset of secrets "may have been" accessed. Hugging Face revoked a number of HF tokens found among the affected secrets and emailed the users concerned.

It also said it had engaged outside forensic specialists, reported the incident to law enforcement and data protection authorities, and published a contact address for security questions.

What it changed

The disclosure lists several platform changes:

  • Organization tokens were removed completely, which the company says improves traceability and audit.
  • A key management service was put in place for Spaces secrets.
  • Detection of leaked tokens was improved, with proactive invalidation.
  • Fine-grained access tokens became the default, with classic read and write tokens planned for deprecation once the fine-grained ones reached feature parity.

What the post does not say

The post does not say how the access happened, how many users were affected or how long the access lasted. This analysis does not fill those gaps and neither should you. Where a disclosure is silent, treat the question as open.

It also does not say what the secrets protected beyond Hugging Face tokens. That is the practical point for anyone who stored third-party keys in a Space: any secret you placed on the platform was in scope for the advice to refresh it.

Lessons for teams that host apps on shared platforms

  • A secrets store on a hosted platform is a trust decision. Know what else you put there besides the platform's own tokens.
  • Prefer narrow, short-lived credentials so that a refresh is cheap.
  • Keep a list of where each secret is stored, so a notice like this one takes minutes to act on rather than days.
  • Scope tokens per project. A token that can only read one repository is a smaller loss than one with write access to an organization.

For a step-by-step response, see our leaked token checklist and the notes on fine-grained tokens for production and CI.

How to read an incident post like this

First separate what the company confirms from what it suspects. Here it confirms unauthorized access to Spaces secrets and the revocation of tokens, and it suspects a subset of secrets may have been read. Second, list the actions it asks of you. Third, list the questions it leaves open, and decide your own response without waiting for answers.

Quick check

Did Hugging Face confirm which secrets were accessed?

No. The post says a subset may have been accessed. It confirms it revoked tokens found in those secrets.

Should I rotate keys from other services stored in a Space?

The post tells users to refresh any key or token. Treat third-party keys held in Spaces secrets as in scope.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.