Hugging Face organization API token
ID |
huggingface_org_token |
Severity |
high |
Remediation Complexity |
trivial |
Remediation Risk |
high |
Remediation Effort |
low |
Vendor |
Hugging Face |
Family |
API Token |
Description
Hugging Face organizations could issue an organization-wide API token. The format is legacy: new integrations should use fine-grained user access tokens scoped to the resources they need.
api_org_ followed by 34 alphanumeric characters.
Security
A leaked Hugging Face key grants an attacker the same access as the application that owns it:
-
Unauthorized usage is billed to your account, and automated high-volume calls can run up a large charge before anyone notices.
-
Whatever is sent through the leaked key — prompts, documents, query results — is exposed to whoever holds it.
-
An organization token is shared by definition, so a leak widens the blast radius to every repository the organization owns.
-
The key does not expire on its own, so the exposure lasts until it is revoked.
Examples
The following is a leak of a Hugging Face key:
HUGGINGFACE_ORG_TOKEN=api_org_vDsdoDJu...gnKW0FV
Mitigation / Fix
-
Follow your policy for handling leaked secrets, which normally requires revoking the key. Go to the organization settings on Hugging Face, delete the leaked token, and replace it with a fine-grained user access token restricted to the repositories that need it.
Revoke the leaked key, do not merely disable it. -
Remove the leaked key from the source code or committed configuration file, and replace its usages with the new value. Environment variables, local files or secret vaults could be used for passing the key, instead of hardcoding the value, as documented in How to Prevent Hard-Coded Secrets.
-
Review the usage and audit logs for the key, to confirm that it was not used by unintended actors while it was exposed.
-
Apply the usual precautions for API keys: never commit them, pass them through environment variables or a secret manager, use a separate key per environment, monitor usage for unusual spikes, and rotate them periodically.
|
You should consider any sensitive data in commits with secrets as compromised. Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories. |