Security firm Truffle Security has uncovered more than half a million active, unique credentials sitting exposed in public GitHub repositories, despite years of platform protections designed to stop exactly this kind of leak.

Scanning 224 million public repositories in August 2025, the company identified 1,103,438 exposed credentials in total. When it tested those credentials against their respective services at the end of July 2026, 543,699 were found to still be active and usable.

The findings highlight just how long leaked secrets can linger. The oldest live credential is an AWS key committed in 2009 that has never been rotated or revoked. The median exposure window across the entire dataset is 784 days, and Truffle Security notes that 2,636 live credentials trace back to files last modified before 2015. A quarter of all exposed secrets found are more than four years old.

Protections in place, but not enough

Perhaps the most striking detail is the timing. Nearly half of the exposed credentials were pushed to public repos after GitHub had already rolled out free secret-scanning alerts and default push protection. According to Truffle Security’s breakdown, 245,959 credentials predate the free alerts program, 97,897 arrived while scanning was free but push protection had not yet been enabled, and 199,843 landed after push protection became the default setting, yet remained valid and answering to their providers more than two years later.

GitHub’s secret-scanning program does forward detected tokens to the issuing providers for revocation, but it does not mandate that those providers actually revoke them. Truffle Security says this gap explains why so many credentials remain live long after discovery.

What’s leaking

The exposed secrets are dominated by a few credential types:

  • 69,041 Google Cloud service account credentials
  • 51,067 MongoDB connection strings
  • 33,343 live Google API keys

Truffle Security frames the core problem as one of revocation, not detection. Push protection stops new secrets from being committed, and alerts can flag historical exposures, but both depend on an owner actually reading the alert and rotating the key. Without automated revocation pipelines on the provider side, detection alone does little to shrink the pool of already-leaked credentials sitting in public view.

For security teams, the research is a reminder to treat credential scanning as an ongoing hygiene exercise rather than a one-time fix, and to pair any secret-detection tooling with enforced, automated rotation and revocation workflows rather than relying on manual follow-up.