GitHub Credentials Exposed: 543K Active Tokens Still Vulnerable

Key Takeaways

• Over half a million active, unique credentials were found exposed in public GitHub repositories, remaining valid despite being publicly available.
• Many of these credentials have been public for years, with the median exposure lasting 784 days, highlighting significant secret management failures.
• While GitHub’s secret scanning and push protection features show some effectiveness in reducing new leaks, a substantial portion of exposed credentials are not covered by these protections or require manual revocation.
• Automated credential revocation by service providers is identified as a critical factor in neutralizing exposure.

A recent deep dive into public GitHub codebases has uncovered a staggering 543,699 unique and still-active credentials, which remained valid when re-tested by researchers on July 27 and 28, 2026. This discovery underscores a pervasive failure in secret management, where sensitive access tokens can persist as usable for years after their initial public exposure, even with GitHub’s implemented secret-scanning and push-protection mechanisms.

The Research Methodology

The investigation, detailed in research published by Truffle Security, involved an analysis of The Stack v3. This extensive public-code snapshot, compiled for training large language models, encompasses 224,553,295 repositories and 58,467,468,698 files spread across 4,096 metadata shards. The data collection for this corpus concluded on August 7, 2025.

Researchers meticulously verified these exposed secrets against their respective issuing services. After deduplicating credentials by their value, they traced the 543,699 active credentials back to 1,103,438 individual exposures, which included various files and repository forks.

Decades of Exposure

A significant finding was the longevity of these exposed secrets. The median credential had resided in a public default branch for 784 days. Alarmingly, ten percent of the credentials were at least 6.3 years old, with the oldest identified as a database credential from an Erlang server configuration. This particular secret, last modified in June 2009, was still capable of authentication 16.1 years later.

Due to The Stack v3’s nature of preserving only default-branch snapshots and file modification times, researchers used the earliest associated timestamp for each credential as its leak date. This methodology means the true extent of exposure is likely greater, as deleted branches, rewritten history, and secrets removed before the crawl would not have been visible.

GitHub’s Protection Measures and Their Limits

GitHub has introduced several features to combat secret exposure. In February 2023, secret-scanning alerts became freely available for public repositories, enabling maintainers to detect supported secrets across their repository history. A year later, in February 2024, push protection was enabled by default for free users. This feature scans pushes for recognizable credentials, blocking detected secrets before they are published and offering developers options to remove or bypass the warning.

Despite these initiatives, 199,843 active credentials (36.8% of the total) were dated after the default push protection rollout. An additional 245,959 credentials predated the availability of free alerts, while 97,897 appeared during the intervening year. This data suggests that while these controls are beneficial, they do not fully mitigate the problem.

The research indicates that push protection is effective, showing a 53 percent reduction in exposure density for credential types it covers, compared to only a 7 percent reduction for unprotected types. However, coverage remains a key limitation. Approximately 51.8 percent of the live credentials utilized formats that are not blocked by default push protection, including critical items like database connection strings, private keys, and Google API keys.

Prevalent Exposed Credential Types

Among the most frequently exposed categories were 69,041 Google Cloud service-account credentials, 51,067 MongoDB connection strings, and 33,343 Google API keys. Researchers also identified 31,374 live Gemini keys. The shared ‘AIzaSy’ prefix with other Google services complicates reliable blocking for Gemini keys.

The findings also emphasize that detection alone is insufficient. For instance, only one of 101,886 committed npm tokens remained active, alongside 260 of 73,048 GitHub tokens, and 15 of 30,437 Hugging Face tokens. In stark contrast, 11,465 of 12,985 PostgreSQL connection strings, 1,806 of 2,421 MySQL strings, and 69,041 of 126,963 Google Cloud service-account credentials were still functional. This disparity highlights automated provider-level revocation as a decisive control in neutralizing exposure.

What You Should Do

• Treat All Committed Credentials as Compromised: Immediately revoke or rotate any credential found in a public repository, regardless of whether it has been detected by automated tools.
• Investigate Associated Systems: Following credential rotation, thoroughly investigate any systems or services that used the exposed credentials for signs of misuse or unauthorized access.
• Prioritize Rotation Before Cleanup: Ensure that credential rotation happens before any attempt to delete the secret from the repository. Deleting a secret does not invalidate copies already harvested by attackers.
• Scan Complete Git History: Implement tools and processes to scan the entire Git history for sensitive data, not just the latest commits.
• Enhance Secret Detection: Enable and configure both generic and custom patterns in secret scanning tools to broaden coverage beyond default protections.
• Discourage Bypass of Protections: Establish strict policies against casually bypassing push protection warnings.
• Adopt Short-Lived Credentials: Wherever possible, use short-lived credentials or temporary access tokens to minimize the window of exposure if a secret is compromised.
• Integrate Secret Alerts with Automated Revocation: Work towards integrating secret scanning alerts with automated systems for credential revocation or expiration to swiftly neutralize exposed access.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.