Half of the working secrets that Truffle Security pulled out of public GitHub code had been sitting there for 784 days or longer. The security firm verified 543,699 unique passwords, tokens and keys that still authenticated when it tested them on July 27 and 28, 2026, spread across about 1.1 million files and repositories. The oldest dated to June 2009, more than 16 years before the verification run.
Each one was live, which is the part that separates this count from the usual tallies of strings that merely look like secrets. Truffle’s headline for the study carries the finding in three words: nobody revoked them.
The Stack v3 scan and how the 784 days were measured
The raw material was The Stack v3, a corpus of 224 million public GitHub repositories and about 58 billion files assembled to train language models, whose crawl closed on August 7, 2025. Truffle Security’s published report ran pattern matching against that corpus and then checked every hit against the issuing provider’s servers, counting only results that came back live. The scope is therefore a snapshot of one dataset tested eleven months after its crawl, not a census of every public repository.
The 784-day figure is an age, not a dwell time measured by the owners. Truffle took the last-modification timestamp of the file containing a credential, using the earliest across all copies, as the leak date, and measured from there to the July 2026 test. The report’s own sentence reads that the median live credential “had been sitting in a public default branch for 784 days.” About a tenth of working credentials were older than 6.3 years, according to BleepingComputer’s summary.
Density is climbing as well. The rate of working credentials rose from 3.72 per million files in 2015 to 11.62 per million in 2025, Windows Report noted, so newer code leaks proportionally more. At the 2025 rate, roughly one working credential appears for every 86,000 files, by simple division of the reported rate.
Push protection covered some shapes and missed others
GitHub switched on push protection by default for public repositories on February 29, 2024. The feature scans pushes and blocks those containing recognized secrets before they land, and GitHub’s documentation says it only catches patterns matching its configured detection rules. When a push is blocked, the developer receives an explanation and can retry after removing the secret, and the user-level default applies to public repositories rather than private ones. Truffle’s numbers show the limit in practice: 199,843 of the live credentials, or 36.8 percent, were exposed after the default took effect.
Truffle reports that leaks in protected categories fell by roughly half after the change. Yet 51.8 percent of every live credential in the corpus has a shape the default configuration lets through, among them database connection strings, private keys and Google API keys. Blocking the pattern at push time does nothing for a secret that was committed years earlier and never revoked.
npm token revocation against Google Cloud service account keys
Survival rates split along one line: whether the issuer revokes leaked secrets on its own. Of 101,886 npm tokens Truffle found committed, exactly one still worked in July. GitHub’s own tokens fared nearly as badly, with 260 of 73,048 alive. Google Cloud service account keys went the other way: 69,041 of 126,963 still worked, a survival rate of about 54 percent, and 11,465 of 12,985 PostgreSQL connection strings, 88 percent, were live.
Google’s documentation on service account keys explains why that matters: a leaked key lets a bad actor authenticate and gain a foothold, and such keys can be more valuable than a leaked password because they bypass 2-step verification. The same page says Google Cloud will automatically disable leaked keys it detects, but only when the relevant organization policy constraint is configured. npm took the other route, letting holders set an expiration date on granular tokens, a design that shrinks the useful life of any token that escapes.
Truffle states the contrast directly: providers with automated revocation, npm and GitHub, show almost no survivors, while those without a kill switch show very high survival. The 784-day median therefore reflects issuer policy as much as developer habit, because a secret that its provider has revoked stops counting as live no matter how long it sat in the repository.
Truffle’s recommendation follows from its own data: rotate anything exposed and put automatic expiry on live credentials, since expiry limits how long a stale secret in an old commit stays useful.
Among the provider families the report itemizes, the Google Cloud block is the largest still-working group: 69,041 service account credentials that authenticated in July 2026, years after some of them were published.
This article was produced with the assistance of AI and reviewed by Morning Overview editors prior to publication.
More from Morning Overview
- Hackers are hijacking outdated home routers, and the FBI named the models to check
- Older Teslas are wearing out in ways early owners never saw coming
- Early electric-car owners are hitting battery and screen failures no one warned them about
- A magnitude 5.3 quake struck off the Oregon coast this week