Truffle Security didn’t go looking for leaked credentials one repository at a time. It went looking through a dataset built for an entirely different purpose — an AI training corpus — and found that the same pile of code scraped to teach large language models to write software was also sitting on more than half a million working passwords to other people’s infrastructure.
The dataset was built to train AI, not to audit security
Truffle Security’s report is built on The Stack v3, a snapshot of 224.5 million public GitHub repositories — 58.4 billion files — assembled to train code-generation models and frozen at a crawl closed in August 2025. Researchers ran pattern matching across all of it to flag strings that looked like API keys, access tokens, and connection strings, then did the part that turns a list of guesses into a finding: they tested every single match against the service that issued it, on 27 and 28 July 2026, to see which ones still authenticated.
The scan surfaced 1,103,438 distinct credential exposures. Of those, 543,699 — just under half — logged in successfully when tested. That number describes credentials still capable of accessing a Google Cloud project, a MongoDB database, or a Slack workspace, not just strings that merely looked like secrets. Because The Stack v3 only captured default branches at the time of its crawl — no commit history, no deleted branches, no force-pushed history scrubbed after the fact — Truffle Security describes its own count as a floor: “the real population is larger.”
Half of what’s exposed is already two years old
The report’s age data is where the finding stops being about carelessness and starts being about neglect. The median live credential had sat in public code for 784 days — a little over two years — before Truffle Security’s July 2026 retest caught it still working. The oldest credential in the dataset traced back to a file last modified on 13 June 2009 and was still valid 16 years later. GitGuardian’s own 2026 secrets-sprawl research backs up the same pattern independently: more than 64% of credentials its scanners confirmed valid in 2022 were still valid at a January 2026 retest, four years on. Two unrelated research teams, scanning different corpora with different methods, arrived at the same conclusion: once a credential leaks, the default outcome is that it simply keeps working, indefinitely, until something outside the leak itself forces a change.
GitHub’s own defense cut the problem in half — for the credentials it covers
GitHub rolled out credential protection in three stages: free secret-scanning alerts for all public repositories starting 28 February 2023, push protection as an opt-in feature from May 2023, and push protection turned on by default for public repositories from 29 February 2024. Truffle Security’s data shows that default-on push protection worked, within its scope. Covered credential families — GitHub tokens, AWS access keys, Slack tokens — showed roughly a 53% drop in the rate at which they reached public code after the policy changed, with individual categories including Slack and AWS keys falling by more than half.
But “within its scope” is doing a lot of work in that sentence. Push protection’s pattern matching only recognizes 48.2% of the credential shapes in Truffle Security’s dataset. Connection strings, Google API keys, and private keys — more than half of every credential confirmed live in this report — don’t match a fixed enough format for GitHub to block them by default. That gap shows up directly in the numbers: 199,843 of the live credentials, 36.8% of the total, were pushed to GitHub after the default protection was supposedly already standing guard.
The real divide isn’t exposure — it’s whether anyone can kill the key
The most useful finding in the report isn’t the headline count; it’s the variance underneath it, because it points straight at the fix. Some credential types are functionally self-destructing once leaked. npm published 101,886 exposed tokens in the dataset — and only one still worked. GitHub’s own tokens showed 73,048 leaks against 260 live, a 0.36% survival rate. Contrast that with PostgreSQL connection strings: 12,985 exposures, 11,465 still live — 88%. MySQL strings ran close behind at 75% live.
The report’s own framing is the sharpest way to put it: “the gap is revocation.” Providers like npm and GitHub have built automated systems that detect a leaked token and kill it, often without a human in the loop. Database connection strings and similar generic secrets have no equivalent — nobody is watching for a MongoDB URI with embedded credentials showing up in a public repo and proactively rotating it. The leak event is identical in both cases. The outcome diverges entirely based on whether the credential format has an automated kill switch sitting behind it, which is a property of the issuing platform, not of how careful the developer who leaked it happened to be.
AI coding tools are adding to the pile, not shrinking it
GitGuardian’s parallel 2026 research gives this problem a growth curve. Its scanners found 28.65 million hardcoded secrets added to public GitHub in 2025 alone — a 34% year-over-year increase — with leaks tied to AI service credentials specifically up 81% to 1.27 million. GitGuardian also measured the behavior of AI-assisted commits directly and found they leak secrets at roughly 3.2%, about double the baseline rate for human-written commits. The tools meant to make developers faster are, measurably, also making them faster at shipping their own credentials into public view — credentials that, per Truffle Security’s revocation data, will likely still be sitting there working years from now unless something forces the issue.
The lessons that generalise
A security control’s coverage number matters more than its existence. GitHub’s push protection measurably works — but only against roughly half the credential shapes attackers and researchers actually find live in the wild. A defense that’s “on by default” against less than half the threat surface will always leave a majority-sized gap that looks, from the outside, like the problem is solved.
Prevention and revocation are two different problems, and most organizations only invest in one. Blocking a secret from being committed in the first place is cheaper and more visible than building the infrastructure to detect a secret that already leaked and kill it automatically. The npm-versus-PostgreSQL gap — 0.001% survival against 88% — shows which investment actually determines whether a leak turns into a compromise.
A credential’s age is not evidence of its safety. The instinct to treat an old, forgotten key as low-risk is backwards: Truffle Security’s data shows the opposite correlation — the longer a credential has been exposed without being rotated, the more likely nobody is watching it at all, which is exactly why the median live credential in this dataset had been sitting in public code for over two years.
Tech-Bee is an independent technology publication. This piece is drawn from Truffle Security’s technical report on credential exposure in The Stack v3 dataset, supporting coverage from SecurityWeek, and GitGuardian’s State of Secrets Sprawl 2026 research as reported by Help Net Security.