Over 543,000 GitHub Credentials Remain Active After Being Publicly Exposed

An analysis of public GitHub code has uncovered 543,699 unique credentials that remained valid when researchers tested them on July 27 and 28, 2026.

The findings expose a secret-management failure: credentials can remain usable for years after developers publish them, despite GitHub’s secret-scanning and push-protection controls.

According to research published by Truffle Security, Truffle Security examined The Stack v3, a public-code snapshot assembled for training large language models. The corpus contains 224,553,295 repositories and 58,467,468,698 files across 4,096 metadata shards, with its crawl ending on August 7, 2025.

Researchers verified secrets against their issuing services, deduplicated them by credential value, and traced 543,699 dated credentials to 1,103,438 exposures, including files and forks.

543,699 Unique Credentials Exposed

The median credential had remained in a public default branch for 784 days. Ten percent were at least 6.3 years old, while the oldest was a database credential in an Erlang server configuration last modified in June 2009 that still authenticated 16.1 years later.

Because The Stack v3 preserves only default-branch snapshots and file modification times, the researchers treated the earliest timestamp associated with each credential as its leak date. Deleted branches, rewritten history, and secrets removed before the crawl were invisible, meaning the exposure is likely larger.

GitHub made secret-scanning alerts free for public repositories in February 2023, allowing maintainers to detect supported secrets across repository history. In February 2024, the platform began enabling push protection by default for free users. The feature scans pushes for recognizable credentials, blocks detected secrets before publication, and allows developers to remove or bypass the warning.

Nevertheless, 199,843 active credentials, 36.8 percent of the total, were dated after default push protection began. Another 245,959 predated free alerts, while 97,897 appeared during the intervening year.

This does not mean the control is ineffective. The research found that exposure density for credential types covered by push protection fell by 53 percent after rollout, compared with 7 percent for unprotected types.

Coverage remains the limitation. About 51.8 percent of the live credentials used formats that default push protection does not block, including database connection strings, private keys, and Google API keys.

The largest categories included 69,041 Google Cloud service-account credentials, 51,067 MongoDB connection strings and 33,343 Google API keys. Researchers identified 31,374 live Gemini keys, whose format shares the AIzaSy prefix used by other Google services, complicating reliable blocking.

The results also show that detection alone does not neutralize exposure. 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.

By 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 still worked. The difference points to automated provider revocation as a decisive control.

Organizations should treat every committed credential as compromised, revoke or rotate it immediately, and investigate associated systems for misuse.

Repository cleanup should follow rotation, not precede it, because deleting a secret does not invalidate copies already harvested. Security teams should also scan complete Git history, enable generic and custom patterns, prohibit casual bypasses, adopt short-lived credentials, and integrate secret alerts with automated revocation. Push protection can reduce new leaks, but only expiration and revocation close access already exposed.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC