An investigation into publicly accessible GitHub code has revealed that 543,699 unique credentials remained accessible when analyzed by researchers on July 27 and 28, 2026. These findings highlight significant lapses in secret management, where credentials can remain active for extended periods, even with GitHub’s secret-scanning and push-protection measures in place.
Persistent Credential Exposure
Truffle Security’s recent report details how they examined The Stack v3, a snapshot of public code used for training large language models. This dataset comprises over 224 million repositories and almost 58.5 billion files, collected up to August 7, 2025. The researchers validated these secrets with their issuing services, deduplicated them, and found 543,699 unique credentials tied to 1,103,438 instances of exposure, including various files and forks.
The average credential had been publicly accessible for 784 days, with 10% being exposed for over 6.3 years. The oldest credential was a database key in an Erlang server configuration from June 2009, still functional 16.1 years later. The analysis used the earliest modification date as the leak date, acknowledging that actual exposure could be greater since only default-branch snapshots were preserved.
Impact of GitHub’s Protection Measures
In February 2023, GitHub made secret-scanning alerts available for public repositories, enhancing maintainers’ ability to detect exposed credentials. By February 2024, GitHub implemented default push protection for free users, scanning for potential credential leaks during code pushes. Despite these measures, 199,843 credentials, or 36.8% of the total, were dated post-push protection implementation, while 245,959 predated free alerts, and 97,897 were from the interim year.
These figures do not necessarily undermine the controls’ effectiveness. The research observed a 53% reduction in exposure density for credential types covered by push protection, compared to a 7% reduction for those not covered.
Challenges in Credential Management
A significant challenge remains in the breadth of coverage. About 51.8% of active credentials used formats not blocked by default push protection, such as database connection strings and private keys. Among these, Google Cloud service-account credentials, MongoDB connection strings, and Google API keys were predominant. Researchers also found 31,374 live Gemini keys, which complicates blocking due to their shared prefix with other Google services.
The findings demonstrate that detection alone is insufficient to eliminate exposure. For instance, only one out of 101,886 committed npm tokens remained active, in contrast to thousands of PostgreSQL and MySQL strings still being valid. This highlights the need for automated revocation by service providers as an effective control measure.
Organizations are advised to assume any committed credential is compromised, promptly revoke or rotate it, and investigate related systems for misuse. They should prioritize repository cleanup post-rotation and ensure comprehensive scans of Git history. Implementing generic and custom patterns, prohibiting casual bypasses, adopting short-lived credentials, and integrating secret alerts with automated revocation can significantly enhance security. While push protection can curb new leaks, expiration and revocation are crucial for mitigating already exposed risks.
