Security researchers have identified 543,699 unique credentials that remain valid despite being exposed in public GitHub repositories. This highlights a persistent failure to revoke secrets once they enter source code.
These credentials were verified as active in July 2026, even though many had been publicly accessible for years.
Researchers at Truffle Security examined The Stack v3, a dataset containing 224.55 million public GitHub repositories and over 58.46 billion files. This dataset represents a snapshot of default branches collected for AI model training, with the crawl ending on August 7, 2025.
The research team scanned all 4,096 metadata shards and tested candidate secrets against their issuing services between July 27 and 28, 2026.
Their analysis identified 543,699 active credentials across 1,103,438 individual exposures, with the median credential reportedly remaining in a public default branch for 784 days.
Active Credentials Leaked in Public GitHub
The oldest active credential in the dataset was associated with a file last modified in June 2009. It remained valid more than 16 years later. Researchers also discovered active FTP logins, AWS keys, database credentials, and dynamic DNS credentials dating back to 2009.
A total of 2,636 verified live credentials originated from files modified before 2015. One-quarter of all live credentials were more than four years old, while the 90th percentile had been exposed for an average of 6.3 years.
The research emphasizes that publicly visible secrets should be considered compromised immediately. Simply deleting a secret from the latest version of a repository does not invalidate it, especially if the credential remains usable or exists in forks, commit history, cached copies, or cloned repositories.
GitHub made secret-scanning alerts free for public repositories in February 2023 and enabled push protection by default for these repositories in February 2024. Push protection blocks commits containing recognized secret patterns unless a developer deliberately bypasses the warning.
Researchers found that 199,843 active credentials were committed after push protection became the default. However, this control appears effective only for the credential types it recognizes: protected credential families decreased by approximately 53% in the 12 months following the rollout, compared with a 7% decline among unprotected credential types.
The researchers concluded that while GitHub’s protection measures prevent many new leaks, they cannot address credentials exposed before these controls were implemented.
More than half (51.8%) of the live credentials identified were of formats not blocked by GitHub’s default push protection. These included database connection strings, private keys, and Google API keys.
Google Cloud service-account credentials made up the largest category, with 69,041 active credentials found. MongoDB connection strings, which are not covered by default, accounted for 51,067 live credentials. Researchers also identified 33,343 live Google API keys, including 31,374 Gemini API keys with a median exposure date of February 2025.
This distinction is significant because Google API keys can share the same prefix (AIzaSy) across services. Some keys may be intended for public web applications. In contrast, others can authorize billable access to Gemini or other cloud services. As a result, GitHub does not block the pattern by default.
The study found that credential survival depended primarily on issuer-side revocation, not secret detection alone. npm tokens showed the strongest revocation outcomes: researchers identified 101,886 committed npm tokens, but only one remained valid. GitHub tokens had a 0.36% survival rate, while Hugging Face tokens had a 0.05% survival rate.
In contrast, database connection strings showed high persistence. Researchers found that 88% of exposed PostgreSQL URIs and 75% of MySQL URIs were still valid. Google Cloud service account keys had a 54% live rate, while SendGrid keys had a 40% live rate.
The findings reinforce the notion that organizations should rotate exposed credentials immediately, scan repository history, not just current branches, and favor short-lived, automatically expiring credentials.
GitHub push protection helps reduce future exposures, but automated provider revocation remains essential for limiting the impact of secrets already leaked into public code.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
