Live credentials found in public GitHub code: 543,699 (Source: Truffle Security research (credentials tested 27-28 July 2026))
Stopping a leak is not the same as ending it
A lock on the door keeps new secrets out of public code. It does nothing for the secrets already inside. Only the company that issued a key can make it stop working.
That is the lesson in new research from Truffle Security. Its team tested credentials found in public GitHub code and counted what still worked. The answer depended less on GitHub's controls than on whether the issuer kills leaked keys automatically.
What the researchers found
Truffle scanned The Stack v3, a snapshot of 224,553,295 public repositories assembled to train AI models. The crawl closed on 7 August 2025. Over two days at the end of July 2026, Truffle asked each issuing provider whether the candidate secrets it had matched still opened the door.
In total, 543,699 unique credentials still authenticated. Half of them had been readable in a public default branch for at least 784 days. The oldest was last touched on 13 June 2009, and its database credentials still worked 16.1 years later.
A further 199,843 date from after GitHub made push protection the default on 29 February 2024. They leaked while the block was running. More than two years later, they still answered their providers.
How push protection works, and what it skips
Push protection is a check that runs at upload time. When a developer pushes code that matches a known secret format, GitHub stops the push. The developer can still override the block.
The patterns it can block cover over 200 kinds of token from more than 180 providers. Only formats precise enough to block safely make the list. Database connection strings and private keys fall into a separate generic class. An organisation has to switch that class on itself.
Google keys show the difficulty. A Gemini key is a billable credential tied to a model endpoint. Google also issues Maps keys that begin with the same AIzaSy letters, and those are built to sit in public web pages. One pattern cannot tell the two apart, so GitHub lists Google API keys as not push protected. Truffle counted 31,374 live Gemini keys in total. The typical leak date among them was February 2025.
The result is that 51.8 percent of live credentials in the corpus are in formats a default public repository lets through.
The control works where it applies
Truffle compared credential types GitHub blocks with types it does not. For each group, it divided credentials found each month by files touched that month. It then looked at the twelve months on either side of the March 2024 rollout. The protected group fell 53 percent. The unprotected group fell 7 percent.
The measure is a rate, credentials per million files, not a count of leaks. The researchers list three limits. The change was a ramp from March to July 2024, not a step. Some unprotected types were partly covered where organisations opted in. And AWS and Google were moving toward short-lived credentials in the same years. That may explain part of the drop.
What separates live keys from dead ones
Truffle then asked a different question. Of the credentials committed, how many still work? The answer tracked the issuer, not GitHub. Where the issuer runs an automated kill switch, almost nothing survives.
One caution on the word "dead." Truffle counts a key as not live if it failed verification. That covers revoked keys and keys simply deleted at the far end. Revocation is the researchers' explanation for the pattern. They did not measure it directly.
Of 101,886 committed npm tokens, one still worked. Of 126,963 Google Cloud service account credentials, 69,041 did. Truffle's own summary: GitHub and npm revoke their own tokens, while nobody revokes a Postgres URL.
GitHub's partner programme forwards a leaked token to its issuer. It does not require the issuer to revoke it. The story is that a detection system is only as strong as the step after detection.
What the data cannot say
The counts describe one branch per repository at one moment. Force-pushed or reverted secrets are invisible, so Truffle says the real population is larger. The survival rates also exclude some families, such as MongoDB and Google Maps-type keys, for method reasons.
BleepingComputer adds that the findings do not show how many keys attackers actually stole or used.
Questions for your security team
Ask which credentials your teams have ever committed, and whether anyone scanned history rather than trusting the push-time block. Code committed before that February 2024 default never passed through it.
Ask which of your providers revoke leaked keys on their own. For those that do not, rotation is a human task with an owner. Ask who that is.
Ask where short-lived credentials can replace long-lived ones. Truffle notes that most of what it found would have aged out if it had been given a lifetime.
Truffle's rule of thumb is to assume a secret is compromised the moment it is committed, whether or not any tool flagged it. Rotate first and clean up history second. A gate helps, but only a dead key is safe.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Truffle Security.
