Hugging Face Spaces Leaked 11,557 Keys—Git History Is the Hidden Trap

A 2026 ICSE study scanned 313,647 public Spaces repositories created from March 2022 through December 2024 and identified 11,557 unique exposed keys in 9,149 repositories. Its file-distribution table attributes 3,883 leak instances, or 32.86%, to Git commit history.

Store credentials as private Secrets, keep only non-sensitive configuration in Variables, and never commit the real values. If a key enters any commit, revoke it at the issuer before cleaning the repository: removing it from the current file does not remove earlier revisions or copies already made from them.

Set the exposure boundary before deployment

Hugging Face’s Spaces documentation says Space code is stored in a Git repository and distinguishes three visibility levels: public source is viewable and clonable by anyone; protected source is limited to owners and collaborators while the app remains publicly accessible; private source and the app are both restricted. The same page directs developers to use publicly viewable Variables for non-sensitive configuration and private Secrets for tokens, API keys and credentials.

Visibility and secret storage address different risks. A protected or private repository reduces who can inspect the source, but collaborators, local clones, generated artifacts and a later visibility change still make committed credentials unsafe. Design every credential as though the repository may eventually be copied or opened.

• List each external service the Space calls and the minimum operations it needs.
• Create a dedicated credential for the Space instead of reusing a personal or multi-application key.
• Choose read-only, fine-grained or resource-limited permissions where the issuer supports them.
• Put model identifiers, feature flags and other non-sensitive settings in Variables.
• Put API keys, database credentials, signing material and privileged tokens in Secrets.
• Exclude local environment files, credential exports, saved notebook output and debug logs before the first commit.

Inject the secret without exposing it

Create the credential at its provider, add it in the Space repository’s Settings as a Secret, and read it from the runtime environment. Commit only the variable name and explicit handling for a missing value; never include the real value in a default, test fixture, Dockerfile, README or example request.

Static Spaces require a stricter design because both Variables and Secrets are made available to client-side JavaScript. A privileged value delivered to a browser is observable by that browser’s user, regardless of its configuration label. Move the privileged call to a trusted server-side component, or redesign the integration around a user-supplied or short-lived token.

Inspect staged changes before every push, including generated files and notebook output. Search for provider-specific token prefixes, private-key headers, connection strings and unexplained high-entropy strings. Pre-commit and CI scanners add useful gates, but a warning is an incident signal—not a substitute for revocation.

Audit Git history, not only the current tree

A cleanup commit records that a string was removed; it does not erase the commit that introduced it. The credential may remain reachable through an earlier revision, branch or tag, while forks, clones, caches and build artifacts can preserve additional copies.

Search all reachable revisions and references for the exposed value, recognizable prefixes and related credential files. Include development branches, merge or pull-request references and artifacts produced while the key was present. Finding nothing in the latest checkout answers only whether the current tree is clean.

History rewriting can remove the value from revisions under your control, but it cannot restore the credential’s secrecy. Revoke first, then rewrite affected history where appropriate, coordinate the force-push with collaborators and require fresh clones. Assume copies outside your control may retain the original commits.

Rotate an exposed credential in the right order

1. Contain execution. Pause the Space or disable the affected integration if continued requests could cause access, spending or data changes.
2. Revoke at the issuer. Disable or delete the exposed credential through the service that created it. Do not wait for repository cleanup.
3. Create a constrained replacement. Limit the new credential to the resources, operations and lifetime the Space actually requires, then store it as a Secret.
4. Deploy and verify. Confirm that the Space uses the replacement, the old key is rejected and no fallback configuration contains the exposed value.
5. Determine impact. Review authentication, audit and billing records from the earliest affected commit through revocation. Look for unfamiliar requests, writes, downloads, resources or charges.
6. Clean every retained copy. Remove the value from the working tree, rewrite reachable history where justified, delete contaminated artifacts and rotate secondary credentials exposed by the same files.

If the key allowed database access, writes or credential retrieval, rotation may be only the first containment step. Check for changed data, altered permissions, persistence and downstream secrets accessible to the compromised identity. Record the earliest affected commit and revocation time to define the investigation window.

Limit the damage of future mistakes

Use one credential per Space so revocation does not interrupt unrelated applications. Keep its scope and lifetime as small as the provider permits, assign responsibility for rotation and remove unused Secrets when an integration is retired or duplicated.

Hugging Face’s Hub security catalog includes access tokens, multifactor authentication and secrets scanning. Enable MFA for accounts that can change Space settings, use narrowly scoped tokens and investigate scanner warnings without treating a clean scan as proof that every revision is safe.

Remediation is complete only when the exposed key is rejected by its issuer, the replacement exists solely in the intended private store, the current tree and controlled history are clean, and any misuse has been investigated separately. Repository cleanup reduces future discovery; revocation ends the old key’s ability to authenticate.

Also read:

• OpenAI Sandbox Escape: What the Hugging Face Incident Means for AI Security
• Autonomous AI Agents Breach Hugging Face in First-of-Its-Kind Attack; U.S. Considers FINRA-Style Oversight Body for Frontier Models
• OpenAI–Hugging Face AI Breach: What Happened and How to Respond