Researchers at Truffle Security found 543,699 unique credentials that still worked sitting in public GitHub code, after scanning 224 million repositories collected for training large language models, BleepingComputer reported Wednesday. The median working secret had been publicly exposed for 784 days.

What Happened

Truffle Security analyzed more than 58 billion files from a dataset assembled for LLM training and based on Common Crawl, whose crawl closed on Aug. 7, 2025. The valid credentials it identified appeared across more than 1.1 million files and repositories, a count that includes forks, where a secret committed once is copied along with the rest of the code.

Many of the secrets were old. About a tenth of the working credentials were more than 6.3 years old, and the oldest dated to 2009. The rate of leakage has also risen over the past decade: the researchers measured 3.72 secrets per million files in 2015 and 11.62 per million in 2025, the highest level in the series.

RelatedNew curl Release Fixes 24 Flaws, Including a High-Severity Bug Reported With Anthropic’s Claude

The sharpest contrast was between ecosystems. Of 101,886 npm tokens found in the data, only one was still valid. Of 126,963 Google Cloud service account keys, 69,041 still worked.

BleepingComputer also reported that a comparable scan of a Hugging Face dataset turned up 221,303 working credentials, less than half the GitHub total.

Why It Matters

The npm result shows what registry-side revocation can achieve. When a platform detects its own tokens in public code and invalidates them, a leak becomes a short-lived problem rather than a standing one. The Google Cloud numbers show the reverse: a service account key committed to a public repository can remain usable for years, giving anyone who finds it whatever access that account holds.

The dataset itself adds a second dimension. Code gathered to train AI models preserves a snapshot of public repositories, including secrets that may later be deleted from the live version of a project. Removing a key from the latest commit does not remove it from history, forks or downstream copies.

Push Protection's Limits

GitHub turned on Push Protection, which blocks commits containing recognized secret formats, by default for public repositories in February 2024. Truffle's figures suggest it helped where it applies: for protected categories, the exposure rate fell by 53%. But 199,843 of the live credentials, or 36.8%, were exposed after the default was switched on, and 51.8% of all live credentials fall into categories the feature does not block, including database connection strings and Google API keys.

That means a large share of the problem sits outside any single vendor's pattern list. Generic connection strings, for example, do not carry a provider-specific prefix that a scanner can match reliably.

What to Do

The researchers' recommendations are familiar but often skipped: rotate any exposed secret immediately rather than only deleting it, purge it from repository history, scan continuously instead of once, and prefer credentials that expire automatically so that a leaked value loses its usefulness on its own.

What to Watch

The findings add pressure on GitHub to widen Push Protection to more credential types, and on cloud providers, Google in particular, to detect and revoke leaked service account keys the way npm does with its tokens. Organizations with long-lived service account keys in older public projects have a straightforward audit to run.