Leaked API Keys on GitHub: How It Happens and What to Do

A developer commits a .env file to a public repository. They notice an hour later and delete it. By then, automated bots have already copied the AWS keys and started launching servers. This scenario plays out constantly.

How secrets end up in repositories

• .env and config files committed before .gitignore was set up.
• Hardcoded keys "just for testing" that ship to production.
• Notebooks and scripts with credentials embedded.
• Private repos made public, exposing the whole history.
• Personal forks and side projects of company code.
• CI configuration with inline secrets.
• Test fixtures containing real tokens.

Deleting the file is not enough

Git keeps history. A secret removed in a later commit is still visible in the earlier commit, in forks, in clones and in caches. Treat any committed secret as compromised.

How quickly attackers find them

Bots continuously watch public commit feeds and package registries for patterns like cloud access keys, payment API keys and tokens with known prefixes. Exposed credentials can be tested within minutes. Some code hosts now scan pushes and notify providers, which may revoke keys automatically, but you cannot rely on that for every secret type.

Response plan

1. Revoke or rotate the secret immediately at the provider. This is the only step that actually stops misuse.
2. Review provider logs for usage since the exposure: API calls, logins, new resources, data access.
3. Check for persistence, such as new IAM users, keys, OAuth apps or SSH keys created by the attacker.
4. Remove the secret from history using a history-rewriting tool, and force-push, accepting that forks and clones may still have it.
5. Notify affected parties if data was accessed.
6. Fix the root cause: add .gitignore rules, pre-commit scanning and a secrets manager.

Prevention

• Pre-commit secret scanning blocks secrets before they are committed.
• CI secret scanning catches what slips through.
• Push protection in your code host rejects pushes containing known secret patterns.
• Secrets managers remove the need for secrets in files at all.
• Short-lived credentials, such as OIDC federation from CI to cloud, eliminate long-lived keys.
• Scoped keys, so a leak has limited impact.

Do not forget the frontend

Secrets also leak through JavaScript bundles served to every visitor. Anything in client-side code is public, including keys injected at build time through environment variables meant to be private.

Finding your exposed secrets

SecurityInfinity's static analysis and secrets agents scan your code and frontend bundles for keys and tokens, and brand intelligence checks public sources for leaked keys associated with your organisation. Start free.

Frequently asked questions

If my repository is private, are secrets safe?

Safer, but not safe. Private repos can be made public, cloned to personal devices, accessed by compromised accounts or integrations, and shared with contractors.

Does GitHub automatically revoke leaked keys?

GitHub's secret scanning notifies participating providers, some of which revoke keys. Coverage varies, so always rotate yourself.

How do I remove a secret from Git history?

Use a history rewriting tool, then force-push and ask collaborators to re-clone. Rotate the secret regardless, because copies may exist elsewhere.