More than 543,000 unique credentials found in public GitHub repositories were still valid and usable in July 2026, highlighting the continuing risk of sensitive access information remaining exposed online despite security measures designed to prevent accidental leaks. The research found that a unique credential remained publicly accessible for a median of 784 days.
FCRF Launches CP-FRM to Build India’s Next Generation of Fraud Risk Professionals
How Many Credentials Were Exposed?
Security research firm Truffle Security analysed data associated with 224 million repositories and more than 58 billion files. Researchers identified 543,699 unique credentials that appeared repeatedly across more than 1.1 million files and repositories, including copies stored in repository forks.
The study found that about 10 per cent of the working credentials were more than 6.3 years old. The oldest still-valid credential identified by the researchers dated back to 2009. The findings indicate that once sensitive credentials become public, they can remain accessible and active for years if they are not properly revoked or replaced.
The assessment was based on a dataset assembled for training large language models. The underlying dataset was created from a large-scale crawl that ended on August 7, 2025. Researchers subsequently examined credentials present in those repositories and identified those that were still working during their July 2026 analysis.
Is GitHub Facing a Bigger Exposure Problem?
The research also indicated that the scale of active credential exposure on GitHub was considerably higher than on another major code and AI dataset platform. An earlier assessment of Hugging Face repositories identified 221,303 working credentials, compared with 543,699 unique working credentials found in the GitHub dataset.
The density of exposed secrets also increased over time. Researchers found that the number of working credentials per million files rose from 3.72 in 2015 to a peak of 11.62 in 2025. The trend points to a continuing challenge for developers and organisations in preventing sensitive access information from being embedded in publicly accessible code.
Why Didn’t Push Protection Stop Them?
GitHub’s Push Protection feature is designed to reduce this risk by scanning code before it is uploaded and looking for patterns associated with secrets such as API keys and access tokens. When a covered secret is detected, the feature can block the push. The protection was introduced for Advanced Security users in April 2022 and became available for public repositories in May 2023 before being enabled by default more broadly.
However, Push Protection does not automatically revoke credentials that have already been exposed. Truffle Security found that 199,843 of the 543,699 working credentials identified in July had been exposed after February 2024, when Push Protection was enabled by default. These accounted for approximately 36.8 per cent of the total.
Researchers also found that 51.8 per cent of the working credentials belonged to categories that are not blocked by GitHub’s default Push Protection coverage. These included database connection strings and Google API keys. At the same time, the security measure appeared to have a measurable effect within the categories it does cover, with the exposure rate for protected credential types falling by 53 per cent after the feature was enabled by default.
Which Credentials Remained Active?
The likelihood of credentials remaining active varied significantly by service. Among 101,886 exposed npm tokens examined by researchers, only one was still working at the time of analysis. In contrast, 69,041 of 126,963 exposed Google Cloud service account credentials remained valid.
What Should Developers Do After a Credential Leak?
The findings underline the importance of immediately rotating credentials once they are exposed. Security teams should also scan repository histories, remove sensitive information from old commits where appropriate and establish automatic expiration mechanisms for active secrets.
The study did not determine how many of the exposed credentials had actually been obtained or misused by attackers. Nevertheless, the presence of hundreds of thousands of valid credentials in publicly accessible repositories creates a significant security risk, particularly when exposed credentials provide access to cloud services, databases, APIs or other critical infrastructure.
The420 Takeaway
Deleting a leaked credential from the latest version of code is not enough if the secret remains valid or survives in repository history. Developers and organisations should treat every publicly exposed credential as compromised, revoke or rotate it immediately, and review connected systems for suspicious access.
About the author — Ayesha Aayat writes on cybercrime, digital safety, and emerging online threats. Her work focuses on public awareness, legal clarity, and technology-driven risks.
Follow for daily updates on cybercrime, corporate fraud, DFIR, hacking, investigations, and digital forensics
