GitHub Still Hosts 543,000 Live Secrets After Push Protection Left Old Keys Untouched

More than half a million passwords, API keys and database logins are sitting in public GitHub code right now, and they still work. Truffle Security found 543,699 unique live credentials after scanning a dataset of public repositories that AI companies use to train large language models.

The finding cuts against a comfortable assumption. GitHub has blocked many secrets at push time by default since early 2024, but that protection does nothing about keys that were already exposed, and a large share of the live ones were leaked after it switched on.

Years of forgotten keys

The researchers worked through The Stack v3, a code corpus covering roughly 224.6 million repositories and 58.47 billion files, with a crawl that closed on August 7, 2025. When they tested the secrets they found in July, more than half a million still authenticated. They were scattered across over 1.1 million files and repositories, forks included.

These are not fresh mistakes. The median live credential had been publicly accessible for 784 days. About 10 percent were older than 6.3 years, and the oldest dated back to 2009.

The problem is also getting denser, not thinner. Working credentials rose from 3.72 per million files in 2015 to a peak of 11.62 per million in 2025. The total is more than double the 221,303 working credentials Truffle found in an earlier scan of Hugging Face.

What Push Protection catches and what it misses

GitHub's Push Protection, on by default for public repositories since February 2024, inspects code as developers push it and stops commits that contain recognized secret patterns. It works where it applies: within the categories it blocks, exposure rates fell about 53 percent after the default went live, SecurityWeek reports.

But it is a gate, not a cleanup crew. It does not revoke anything that was pushed before, and it does not cover everything. About 199,843 of the live credentials, roughly 36.8 percent, were exposed after the default took effect. And 51.8 percent of live credentials belong to categories the default configuration does not block at all, including database connection strings and Google API keys.

Gemini keys lead the pile

The single biggest category was live Google Cloud service accounts with access to Gemini, at 69,041. That matters because a stolen AI key is a billing weapon: whoever holds it can run up model usage on someone else's account. MongoDB connection strings followed at 51,067, then Postgres at 11,465, SendGrid at 9,189 and AWS access keys at 6,819.

A database connection string is often worse than an API key, since it can hand over the data itself rather than a metered service. The same pattern of overlooked secrets keeps turning up elsewhere, from Vite dev servers leaking cloud keys to OAuth tokens pulled through the MCP Python SDK.

There is one bright spot. Npm tokens were almost entirely dead: of 101,886 found, only one still worked. Npm has been aggressively revoking exposed tokens, which shows what happens when a provider treats a public leak as an automatic kill signal.

What the numbers do not say

The research measures exposure, not abuse. Truffle did not determine how many of these keys attackers have actually used, so the count is a map of open doors rather than a tally of break-ins.

Still, the dataset in question is one AI labs openly train on, which means these secrets are not hidden in some obscure corner of the internet. Blocking new leaks at push time has clearly helped. The half million keys already out there will stay live until the people who own them, or the vendors who issued them, rotate them.