GitHub repos expose over 543,000 still-valid credentials

Public GitHub repositories still hold hundreds of thousands of working secrets, even though the platform has added tools meant to stop accidental leaks. A new analysis by Truffle Security found 543,699 unique credentials that were still valid in July.

The researchers scanned 224 million repositories and more than 58 billion files. They found that a typical leaked credential stayed publicly accessible for a median of 784 days before anyone noticed or acted.

The age of some of these secrets is notable. About 10% of the working credentials were older than 6.3 years, and the oldest valid one dates back to 2009. The 543,699 unique secrets appeared again and again across more than 1.1 million files and repositories, including copies in forks.

Where the data came from

Truffle Security did not crawl GitHub directly for this study. It worked with a dataset built to train large language models, based on a crawl that ended on August 7, 2025.

The GitHub figure is more than double what the same team found in August after scanning Hugging Face, where it identified 221,303 working credentials.

The research also points to a steady rise in how often secrets turn up in code. The number of working credentials grew from 3.72 per million files in 2015 to a peak of 11.62 per million files in 2025.

Push Protection helps, but only so far

GitHub's main safeguard against this problem is Push Protection. It first became available in April 2022 for Advanced Security customers, was extended to public repositories in May 2023 and was later turned on by default.

The feature checks incoming code for secret patterns such as API keys and access tokens, and blocks the push if it finds a match. It does not, however, revoke credentials that were already exposed before it stepped in.

According to Truffle Security, 199,843 of the live credentials, or about 36.8% of the total, were exposed after GitHub enabled Push Protection for all users in February 2024.

Slightly more than half (51.8%) of the working secrets belonged to categories that the default Push Protection setup does not block. These include database connection strings and Google API keys.

Within the categories it does cover, the feature seems to work. The rate of exposed credentials in protected categories dropped by 53% after GitHub switched it on by default.

Some services clean up faster than others

The chances that a leaked secret still works depend heavily on the service behind it. Of 101,886 npm tokens committed to public repositories, the researchers found only one that was still active.

Google Cloud service account credentials told a very different story. Out of 126,963 exposed keys, 69,041 were still valid when Truffle Security ran its checks.

For anyone affected, the advice is to rotate exposed credentials immediately, clean up the repositories, scan the full commit history and set automatic expiration on all active secrets.

The study shows how many working secrets are sitting in public code. It does not show how many of them have actually been found and abused by attackers.

Why It Matters

For developers and security teams, the most useful takeaway is that blocking new leaks is not the same as fixing old ones. Push Protection seems to reduce exposures in the categories it covers, but hundreds of thousands of older and uncovered secrets remain live. This suggests that scanning history and revoking keys is still largely left to repository owners.

The gap between npm tokens and Google Cloud credentials is also telling. It indicates that provider-side detection and automatic revocation can make a large difference, and that services without such mechanisms leave the burden on users.

The findings fit a wider pattern of sensitive data ending up in public code, from AI agents leaking screenshots to GitHub to exposed GitLab email addresses being used to push code. It is worth watching whether GitHub expands Push Protection to cover database connection strings and Google API keys, and whether more cloud providers adopt automatic revocation for leaked credentials.