Truffle Security has uncovered more than half a million credentials sitting in public GitHub repositories that were still valid when researchers tested them, with some remaining active for more than 16 years.
The security company scanned The Stack v3, a large public-code dataset with 224,553,295 GitHub repositories and over 58.4 billion files. The crawl covers the default branch of each repository as it appeared when the dataset closed on August 7, 2025.
Researchers tested the detected credentials against their issuing services on July 27 and 28, 2026. Of those, 543,699 unique credentials still authenticated successfully. According to Truffle Security, the median exposed credential had been in public code for 784 days, while 10% were over 6.3 years old.
The oldest working credential traced by the researchers dated back to June 2009. It was a set of database credentials stored in an Erlang web server configuration file and remained valid 16.1 years later. Other surviving examples from 2009 included an FTP login and an AWS access key.
The findings also show that GitHub’s push protection is helping, but only for the credential types it recognizes and blocks.
GitHub enabled push protection by default for public repositories on February 29, 2024. Truffle Security found the rate of supported credential types reaching public code fell about 53% in the 12 months around the rollout.
Still, 199,843 of the credentials found in the study were committed after push protection became the default.
One reason is coverage. According to the researchers, 51.8% of all still-active credentials belonged to types GitHub does not block by default, including database connection strings, private keys, and Google API keys.
For example, the scan found 51,067 active MongoDB connection strings and 33,343 live Google API keys. It also identified 31,374 active Gemini API keys, with a median leak date in February 2025.
However, the study points to credential revocation as the bigger issue.
Of 101,886 npm tokens found in the dataset, only one was still active. GitHub tokens showed a similar pattern, with 260 still working out of 73,048 detected, while only 15 of 30,437 Hugging Face tokens remained valid.
Database credentials were very different. Of 12,985 PostgreSQL connection strings, 11,465 were still active, an 88% survival rate. For MySQL, 1,806 of 2,421 credentials remained usable, or about 75%.
Truffle Security attributes much of that difference to automated revocation. Providers like GitHub and npm can automatically invalidate leaked tokens once detected. A PostgreSQL connection string, by contrast, usually has no central issuer to revoke it automatically.
GitHub also operates a secret scanning partner program that can notify providers when their credentials appear in public repositories. However, providers are not required to revoke those credentials after receiving a report.
The researchers argue that stopping secrets before they reach a repository and revoking them afterward are separate problems. Push protection significantly reduces supported leaks but cannot disable credentials already exposed.
The dataset means the real number of leaked credentials is likely higher than the 543,699 confirmed in the study. The Stack v3 includes only the default branch at the time of the crawl and does not contain deleted commits, rewritten history, reverted secrets, or credentials stored only in other branches.
Truffle Security’s recommendation is straightforward: once a credential has been committed to a public repository, it should be considered compromised and rotated immediately. Developers should also scan repository history and, where possible, prefer short-lived credentials that expire automatically.
Source: Truffle Security
