543,699 Live Passwords Found in Public GitHub Code
Researchers scanned 224 million public GitHub repositories and found 543,699 unique credentials that still worked when tested — keys and passwords sitting in public code for a median of 784 days without anyone revoking them.
Key facts
The scan: Truffle Security analyzed 224 million public repositories and over 58 billion files, using a code snapshot assembled to train AI models
The finding: 543,699 unique credentials still authenticated when tested in late July 2026
Median exposure: 784 days. About 10% had been public for more than 6.3 years; the oldest dates to 2009
The spread: The credentials appeared across more than 1.1 million files and repositories
The gap: 51.8% fall into categories GitHub's default Push Protection does not block
The fix: Rotate exposed credentials, clean repository history, set automatic expiration
What kind of credentials are exposed?
The kind that costs money or grants access. Researchers found live Google Cloud service account credentials, database connection strings, API keys and private keys, among others.
Revocation rates vary enormously by service. Of 101,886 committed npm tokens, researchers found only one that still worked. Of 126,963 exposed Google Cloud service account credentials, 69,041 were still valid at the time of analysis.
That contrast is the real finding. Some services aggressively detect and revoke leaked credentials. Others do nothing, and the keys stay live for years.
Doesn't GitHub block this?
Partly. GitHub's Push Protection scans incoming code for secret patterns such as API keys and access tokens and blocks the upload when it finds one. It became generally available for public repositories in May 2023 and was enabled by default for all users in February 2024.
Within the categories it covers, exposure rates dropped 53% after it was turned on by default — a genuine improvement.
Two gaps remain. Push Protection does not revoke previously exposed credentials, only blocks new ones. And more than half of the live credentials found fall into types it does not block by default, including database connection strings and Google API keys. Developers can also override the block.
Notably, 199,843 of the credentials — roughly 36.8% — were exposed after Push Protection was turned on by default.
What should developers and businesses do?
Rotate first, clean second. If a credential has been public, rotating it is the only action that actually helps — deleting the file does not, because the credential remains in the repository's history and in every fork and clone.
Then clean the repository and its history, and set automatic expiration on all active secrets so that a future leak has a limited shelf life.
For business owners without developers in-house: ask whoever builds or maintains your software whether they scan for committed secrets, and whether any credentials have ever been rotated after a leak. The question itself tends to be informative.
Why this is worse than it sounds
These credentials require no hacking to obtain. They are in public code, indexed and searchable, and in this case they were in a dataset assembled to train AI models — which means they have been copied, redistributed and ingested far beyond GitHub.
The researchers note their findings show the scale of working secret exposure but not what share is actually being abused by attackers. That is the unmeasured part.
Sources: BleepingComputer; Truffle Security report; Cybernews.