Your old API keys are worth money to a stranger. A key like that is a long password that one program uses to log in to another service, with no human typing anything. This month attackers kept getting into companies not by cracking anyone's password, but by finding those keys sitting in plain sight inside code that developers had published.
In May 2026 alone, hackers tampered with hundreds of software packages, all chasing the same prize. They wanted the keys that developers use to reach their company's servers, cloud accounts and code.
GitHub itself got hit. On May 18 a booby-trapped add-on for a code editor took over an employee's laptop, and an attacker claimed access to roughly 3,800 of GitHub's internal repositories, the stores that hold a project's code. GitHub spent the next two days cancelling its most important keys and issuing new ones, before anyone could use the old set.
So here's the question worth asking. If a stranger cloned your code right now, what would they find?
Why a leaked key is so dangerous
Developers call these keys secrets, and a single project can collect a pile of them. The key to a cloud account, the password to a database, the private half of an encryption key. They get typed straight into a source file and saved into the project's history in git, where everybody forgets about them.
Deleting the line later does nothing, because that history keeps every old version of every file. The key is still sitting in one of them, and anyone who downloads the project gets the whole history along with it.
That's exactly what bit the US government this month. Dylan Ayrey, the developer behind the secret-scanning tool TruffleHog, flagged that a leaked CISA repo still held a working RSA private key, the file that opens a locked server, and nobody had bothered to cancel it. A key sitting in public, still working. Yeah. Not great.
Scan your own code
TruffleHog is free and open source, and it does one job well. It digs through your code, finds anything that looks like a key, then actually tries to log in with it to see if the key still works. That last part matters. A dead key is noise. A live one is a fire.
Run trufflehog git file://. --results=verified,unknown from inside any repo on your machine. That flag tells it to show you the keys it confirmed are live, plus the ones it couldn't check, and to hide the dead ones.
What to do when it finds something
Don't just delete the key from the file. That fixes nothing, remember? The history still has it. The only real fix is to cancel the leaked key wherever it came from and make a new one. Log in to AWS, Stripe, whatever issued it, kill the old key, generate a fresh one.
Developers call that rotating a key, and it's the same advice that the pros gave during the GitHub mess. Binance founder CZ told developers to rotate every API key sitting in their repos, public or private, the moment the breach went public. Cancel and replace first, clean up the file second.
Want to stop it happening again? Run TruffleHog before every commit so a key never makes it into the history in the first place.
The bigger picture
Scanning is cheap. The cleanup after a stolen key has drained a cloud account or backdoored your users isn't. TruffleHog can spot over 800 kinds of key, from cloud logins to database passwords to the private keys that keep a website's traffic encrypted, so it'll likely catch whatever you forgot about. Honestly, the worst case is that it finds nothing and you wasted thirty seconds.
The attackers already run these scans against every public repo they can reach. They have for years. The only question is whether you check your code before they do. Spin it up tonight. It's free.
