Over 543,000 GitHub Credentials Remain Active After Public Exposure
Researchers found over half a million active credentials, including API keys and database connection strings, publicly exposed in GitHub repositories, many remaining valid for years.
An extensive analysis of public GitHub code repositories has revealed a significant security lapse: over 543,000 unique, active credentials were found to be publicly exposed and remained valid as of late July 2026. This discovery underscores a persistent failure in secret management, as many of these credentials, such as database connection strings and API keys, have remained usable for years despite GitHub's built-in secret-scanning and push-protection features.
The research, conducted by Truffle Security, examined "The Stack v3," a massive dataset of public code compiled for training large language models. This corpus, containing over 224 million repositories and nearly 59 billion files, provided a broad snapshot of publicly available code. Researchers meticulously verified the exposed secrets against their respective issuing services and deduplicated them by credential value. Their analysis traced 543,699 dated credentials to a staggering 1,103,438 individual exposures across files and forks.
The longevity of these exposed secrets is particularly alarming. The median credential had resided in a public default branch for 784 days, with 10 percent being at least 6.3 years old. The oldest identified secret was a database credential in an Erlang server configuration, last modified in June 2009, which astonishingly still authenticated over 16 years later. The researchers note that their findings likely represent an undercount, as deleted branches, rewritten history, and secrets removed before the crawl concluded were not visible.
Despite GitHub's efforts to enhance security, including making secret-scanning alerts free for public repositories in February 2023 and enabling push protection by default for free users in February 2024, the problem persists. Notably, 199,843 active credentials (36.8 percent of the total) were dated after the default push protection feature began. While the research indicates that push protection has reduced the exposure density of protected credential types by 53 percent, the primary limitation appears to be coverage.
Approximately 51.8 percent of the live credentials identified were in formats that default push protection does not currently block. This includes critical secrets like database connection strings, private keys, and various Google API keys. The most prevalent categories of exposed secrets included 69,041 Google Cloud service-account credentials, 51,067 MongoDB connection strings, and 33,343 Google API keys. The research also highlighted challenges with newer formats, such as 31,374 live Gemini keys, whose prefix is similar to other Google services, complicating reliable blocking.
The analysis also revealed a stark difference in the effectiveness of detection versus automated revocation. While detection mechanisms are valuable, they do not inherently neutralize exposure. For instance, only one of 101,886 committed npm tokens remained active, whereas a significant number of database connection strings, including 11,465 out of 12,985 PostgreSQL strings, were still functional. This disparity strongly suggests that automated provider revocation is a decisive control measure.
Security experts emphasize that organizations must treat every committed credential as potentially compromised. Immediate revocation or rotation of these secrets is crucial, followed by thorough investigations of associated systems for any signs of misuse. Simply deleting a secret from a repository does not invalidate copies that have already been harvested or exploited. Best practices include scanning complete Git histories, enabling both generic and custom secret detection patterns, prohibiting casual bypasses of security controls, adopting short-lived credentials, and integrating secret alerts with automated revocation workflows.
While push protection can significantly reduce the rate of new leaks, it is the expiration and automated revocation of credentials that ultimately close the door on already exposed secrets. This ongoing challenge highlights the need for continuous vigilance and robust automated security practices in the development lifecycle, especially as AI tools become more integrated into coding workflows.
The new analysis from Truffle Security highlights that a significant portion of these exposed credentials were pushed to public repositories even after GitHub implemented free alerts and default push protection features. This indicates that while preventative measures are in place, the issue of credentials remaining active for extended periods, often due to a lack of mandatory revocation by providers, persists.