Leaked Secrets in 2026: Why an API Key Pushed to GitHub Gets Abused Within Minutes, What Deleting the Commit Fails to Remove, and How to Scan, Rotate and Keep Credentials Out of Code
- Equipo de Internet Pros
- October 25, 2026
- Redes y Seguridad
Este artículo está disponible solo en inglés.
A developer is in a hurry, pastes a cloud access key into a config file to test something, and pushes the change to GitHub. Before they finish their coffee, an automated scanner has copied the key and someone is starting servers on the company account. Leaked secrets, meaning passwords, API keys, tokens and private keys stored in code, are one of the most common ways attackers get in. They need no exploit and no phishing email, only a search.
How Big the Problem Is
Security firm GitGuardian scans every public commit on GitHub. Its 2025 report counted about 23.8 million new hard-coded secrets pushed to public repositories in a single year, a rise of roughly a quarter on the year before. The more worrying figure is how long they stay dangerous: most of the valid secrets it found years earlier were still working when it checked again. Someone noticed the leak, or nobody did, but the key was never changed.
Public repositories are only part of the picture. Private repositories hold even more secrets per project, because people assume nobody outside can see them. Then a contractor gets access, a repository is made public by mistake, or a developer’s laptop is infected with an infostealer that copies their Git credentials, and every secret in that code is exposed at once.
A leaked password is not fixed when you delete it. It is fixed when it stops working.
Why Abuse Starts Within Minutes
Attackers run bots that watch the public GitHub event stream and package registries around the clock. They look for patterns that are easy to recognise: AWS keys start with AKIA, Stripe live keys with sk_live_, GitHub tokens with ghp_ or github_pat_. Researchers who plant fake cloud keys on purpose regularly see the first login attempt within a few minutes. Stolen cloud keys are mostly used to run cryptocurrency miners or send spam on your bill, but a key with wide permissions can also be used to copy or delete data.
Some providers now step in. AWS, for example, attaches a quarantine policy to an access key it sees exposed on GitHub, and GitHub alerts many partner services so they can revoke tokens. These are safety nets with gaps. Most small vendors, internal systems and database passwords are not covered, and a quarantine does not undo what happened before it.
Why Deleting the Commit Does Not Remove It
Git is designed never to lose anything, which is exactly the problem. Removing the key in a new commit leaves it in every earlier commit. Even rewriting history leaves copies behind:
- Clones and forks: anyone who pulled or forked the repository already has the old commits, and GitHub can keep commits from deleted forks reachable by their ID.
- Caches and mirrors: archive services, search engines and the scanners themselves may already hold a copy.
- Pull requests and CI logs: old pull request pages and build logs can still show the value even after the branch is cleaned.
- Container images: a secret copied into an early Docker layer stays in the image even if a later step deletes the file.
The right order is therefore always the same: revoke and replace the secret first, then clean up the history if you want to. Tools such as git filter-repo remove the value from history, but they are tidying up, not the fix.
Where Secrets Actually Leak From
| Source | How it happens | What prevents it |
|---|---|---|
| .env and config files | The file is committed because it was never added to .gitignore |
Ignore rules in every project template, plus a pre-commit scan |
| Source code | A key pasted in “just for testing” and forgotten | Read secrets from the environment or a secrets manager only |
| CI/CD pipelines | A script prints variables to the build log, or a long-lived cloud key sits in pipeline settings | Masked variables and short-lived OIDC credentials instead of stored keys |
| Container images | Secrets copied in at build time and pushed to a public registry | Build-time secret mounts and image scanning before push |
| Chat, tickets and docs | Passwords shared in Slack, Teams, Jira or a shared API-testing workspace | A password manager with shared vaults, and scanning of those tools |
How to Find What Has Already Leaked
Start with a scan of everything you own, including full history, not just the current files. GitHub offers free secret scanning and push protection on public repositories, and push protection is on by default for them; private repositories need a paid security add-on. Open-source scanners such as Gitleaks and TruffleHog can scan any Git repository, folder or container image, and TruffleHog can test whether a found key still works, which tells you what to rotate first.
Expect a long list on the first run. Sort it by two questions: is the secret still valid, and what can it reach? A live production database password or cloud admin key goes to the top. An expired test token can wait.
If a secret has leaked: the first hour
- Revoke or rotate it now. Create a new key, update the systems that use it, and disable the old one. Do not wait to clean the repository first.
- Check the logs. Look at the provider’s access logs, such as AWS CloudTrail, for activity from the old key since the time of the commit.
- Look for what an attacker leaves behind. New users, new access keys, unfamiliar servers in other regions and changed billing or email settings.
- Find the other copies. The same password is often reused in other projects and servers. Search for it everywhere.
- Then clean up. Rewrite history if needed, ask collaborators to re-clone, and record what happened in case notification rules apply.
How to Keep Secrets Out of Code for Good
- Block at the source: add a pre-commit hook that runs Gitleaks on every developer machine, and turn on push protection on the server so a missed hook still gets caught.
- Use a secrets manager: AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault or 1Password let applications fetch secrets at run time so nothing sensitive is stored in the code.
- Prefer short-lived credentials: GitHub Actions, GitLab and most clouds support OIDC federation, which gives a pipeline a token that expires in minutes instead of a key that lasts for years.
- Limit every key: give each secret only the permissions and IP ranges it needs, so a leak does less damage.
- Rotate on a schedule: secrets that change regularly are worth less to whoever holds an old copy, and the process is already tested when an emergency comes.
En resumen
Leaked secrets are a simple problem with a simple fix that most organisations still skip. Scan your repositories and their full history, rotate anything that is still live, and put two checks in the way of the next leak: one on the developer’s machine and one on the server. Above all, treat any secret that has touched a commit as public, because it probably is.
Not sure what is sitting in your code, build pipelines or old repositories? Contact Internet Pros for a secrets scan of your repositories and a plan to move your credentials into a proper secrets manager.
