543,699 Working GitHub Credentials: The Keys Push Protection Was Never Built to Catch

543,699 working keys are sitting in public GitHub repos. Half of them are the kind GitHub’s alarm never checks.

Truffle Security crawled 224 million public GitHub repositories and 58 billion files. The count that came back: 543,699 credentials still live and working as of July 2026. Not leaked-and-burned. Not revoked. Live. The median one had been sitting in public view for 784 days. The oldest survivor dates to 2009, seventeen years of an open secret on the world’s biggest code host.

BleepingComputer carried the research on September 30, and the numbers deserve a slow read, because most security teams have built their posture around a comforting assumption: that GitHub’s Push Protection has this covered. It doesn’t. Roughly 200,000 of those live credentials landed in repositories after GitHub switched Push Protection on for everyone in February 2024. That’s 36.8% of the total, exposed with the guard already on duty.

The gap is in what the guard looks for

Push Protection scans incoming commits for known secret patterns and blocks the upload. What it catches, it catches well: after GitHub made the feature a default, exposed-credential rates in its protected categories dropped 53%. The problem is coverage. The researchers found that 51.8% of the live credentials belonged to types the default rules simply don’t block. Database connection strings. Google API keys. The stuff that gets you straight into a datastore, pasted into a repo because a developer was three hours into a deadline and the connection string was right there in their terminal.

Revocation behavior varies by service, and the spread is wild. Of 101,886 committed npm tokens, exactly one still worked when Truffle tested. Somebody, somewhere, is running a serious npm hygiene program. On the other end, 69,041 of 126,963 exposed Google Cloud service account credentials were still valid at the time of analysis. Sixty-nine thousand working paths into Google Cloud projects, most of them presumably not being hunted yet, because nobody has data on what percentage actually gets stolen. Scary is a word I use sparingly. Sixty-nine thousand live service-account keys is where I use it.

Why an African fintech should care more than a Silicon Valley one

Three details in this dataset map uncomfortably well onto how software actually gets built here.

First, the fork problem. Many of the 543,699 credentials appeared repeatedly across 1.1 million files once forks and copies were counted. You can delete the secret from the repo you control. You cannot delete it from the forty forks that a contractor cloned in 2021 and never touched again. Rotation is the only real fix, and rotation is exactly the thing nobody budgeted for.

Second, the age distribution. About 10% of the working credentials were older than 6.3 years. In South African fintech, where a payment integration written in 2019 still moves money today, a seven-year-old key with production access isn’t a horror story, it’s a Tuesday. The person who committed it left the company three years ago. The key did not.

Third, the credential mix. Database connection strings to payment platforms and cloud service accounts are exactly what a bank or payments switch in Johannesburg runs on. They’re also exactly what Push Protection’s default rules let through. The credential type with the highest survival rate in this study, Google Cloud service accounts, is the same identity type your cloud console uses to grant your applications the keys to everything.

What to do this week, in order

• Rotate, don’t delete. If any credential of yours surfaced in this research or any scan like it, treat it as stolen. Deleting the commit changes nothing; forks and history keep copies alive.
• Scan your history, not just your HEAD. Secrets committed and reverted still sit in the git log, and scanners read logs.
• Extend your detection past default patterns. Database connection strings and Google API keys sail under Push Protection’s radar. Your own scanners should know what your stack actually uses.
• Put expiry on everything. Truffle’s own recommendation, and the cheapest control on this list: automatic rotation windows and time-bound credentials, so an old key dies of age instead of assassination.

The eHawu view

A credential exposed for a median of 784 days is a network-layer problem wearing a developer-tools costume. Somewhere inside that window, an API call made with a stolen key looks completely legitimate to your firewall and your WAF. It comes from a real cloud provider, authenticates with a real key, and asks for real data. eHawu starts where perimeter trust ends: identity-bound sessions, least-privilege access enforced at the network layer, and verification that keeps asking whether the thing holding the key is still the thing you handed it to. Secrets leak. The question is whether your architecture notices when one gets used.