It has been discovered that over 540,000 authentication credentials that were accidentally made public on GitHub remain valid and unattended.
A large-scale investigation of GitHub's public repositories by security firm Truffle Security revealed that 543,699 pieces of authentication information, including API keys, access tokens, and database connection information, remained publicly available and usable. The median duration for which the authentication information had been publicly available was 784 days, with some pieces remaining valid for over 16 years, dating back to 2009.
GitHub Repos Exposed 543,699 Credentials. Nobody Revoked Them. ◆ Truffle Security Co.
GitHub allows you to publish your source code online, but configuration files during development may contain API keys and passwords for connecting to external services. Uploading source code with authentication information written directly into it to GitHub creates the possibility that a third party could use that information to access cloud services or databases.
Truffle Security used 'The Stack v3,' a large-scale language model training dataset, to examine approximately 58.4 billion files contained in 224,553,295 public GitHub repositories. Collection for The Stack v3 ended on August 7, 2025, and Truffle Security attempted to authenticate the found credentials against the publishing services from July 27-28, 2026, to verify their actual usability. As a result, 543,699 were found to be valid. If the same credentials are included in multiple files or forks, the number of credential exposures reaches 1,103,438.
Furthermore, the median time since valid credentials were made public was 784 days, with 10% being publicly available for more than 6.3 years. The oldest credentials were for a database included in a file updated in June 2009, and were still usable at the time of the investigation. Truffle Security has not disclosed the name of the repository in question because the credentials are still valid.
Because there have long been many cases of users accidentally disclosing their authentication information on GitHub, GitHub has implemented various countermeasures. A prime example is 'Push Protection,' a feature that detects and stops the transmission of authentication information if an attempt is made to upload code containing API keys or access tokens in formats supported by GitHub. Push Protection for public repositories became available in 2023 and was enabled by default for all users from February 2024.
In the diagram below, files that were last updated after February 29, 2024, when Push Protection was enabled by default, are shown in orange. A large number of valid credentials have been found even in files that were last updated after Push Protection was enabled by default.
On the other hand, a closer look at the credentials protected by Push Protection reveals a 53% decrease in detections per million files over a 12-month period before and after default activation. This suggests that even after GitHub's detection and prevention capabilities were strengthened, unprotected credentials and other sensitive information continued to enter public repositories.
Of the 543,699 cases identified, 199,843 were published after February 2024, when Push Protection became enabled by default. Furthermore, 51.8% of the valid credentials were of types not blocked by standard Push Protection settings, such as database connection strings, Google API keys, and private keys.
Furthermore, Truffle Security points out that mechanisms to prevent disclosure alone cannot invalidate credentials that have already been leaked. GitHub's secret scan can detect leaked credentials of the corresponding types, but if valid credentials are found, the issuer needs to revoke the credentials or switch to new ones.
There were significant differences between services. Of the 101,886 npm tokens published on GitHub, only one was valid at the time of the survey, and of the 73,048 GitHub tokens, only 260 were valid. On the other hand, of the 126,963 service account credentials for Google Cloud, 69,041 were valid. Truffle Security analyzes that a major difference lies in whether the issuer has a mechanism to detect leaked credentials and automatically revoke them.
Truffle Security warns that if you accidentally commit credentials to a public repository, you should treat it as a breach, regardless of whether it's detected or not. If you accidentally commit credentials, you should first revoke them and switch to new ones, and then clean up your Git history. They also recommend that you manually scan your history for commits made before Push Protection was enabled by default. They also state that it's important to use credentials with expiration dates whenever possible.
Related Posts:
in Security, Posted by log1d_ts