top of page

Truffle Security Says 81% of Leaked Keys It Reported Were Still Valid Six Months Later, and Under 2.2% at Issuers That Revoke on Report. What That Means If You Issue Keys, and If You Leak Them.

Writer: Patrick Duggan
Patrick Duggan
3 hours ago
4 min read

If you issue API keys or tokens to customers, decide this month whether a leaked key gets revoked automatically when someone reports it. If you only use other people's keys, assume that telling an owner their key leaked will not, on its own, close the hole. Truffle Security announced a free Secrets Revocation Program on November 4, 2026, built on one measurement: notifying owners mostly does not work, and revoking does. These figures are Truffle's, from its announcement as carried by VentureBeat. We have not verified them.





What Truffle reports


Truffle Security launched the program on November 4. It scans public sources, which the release lists as GitHub, GitLab, Docker Hub, npm, PyPI, Hugging Face, Android apps and Firefox add-ons. It tests each key with its TruffleHog tool and tells participating issuers only about keys it confirms are live. The program launches with 1.4 million verified, live credentials. An issuer can receive them through a webhook and revoke them itself, or give Truffle a revocation endpoint so Truffle revokes them automatically. Participation is free and open to any organization that issues credentials.


Three measurements carry the argument:


  • In a 2025 study, Truffle disclosed 21,981 live keys found on GitLab and Bitbucket to owners and issuers. Six months later, 81 percent were still valid.

  • At issuers that revoke on report, the release names Hugging Face, GitHub, Anthropic, OpenAI and Slack, and says no more than 2.2 percent of exposed keys were still valid. The release does not say those companies are program participants.

  • In an analysis it calls Stack v3, 543,699 credentials still authenticated in July 2026, and half had been exposed for more than two years.

It adds two more. In August 2026 it re-checked 64,024 leaked AWS keys and 88 percent were still active. And after Google Cloud changed a default in June 2024, the share of keys still working fell from 72 percent for keys committed the year before to 11 percent for keys committed the year after. That is the same lesson from a different direction: a default that removes the credential beats a report that asks a person to remove it.



Why this matters


The usual advice after a leak is to tell the owner and trust them to rotate. These figures say that advice fails most of the time. A person gets an email, assumes it is spam or defers it, and the key stays live. The gap between "reported" and "revoked" is where the damage happens, and only the issuer can close it.


It also explains why a leak in a settings file is worse than it looks. Apiiro's research on Claude Code's "don't ask again" file, as reported by The Hacker News on November 7, found 1,122 public copies holding secrets, and one company it notified confirmed its key was live. Notification reached them. We wrote that up in "Apiiro Found 1,122 Public Copies of Claude Code's Settings File Holding Secrets." We then published a free scanner, claude-settings-leak-check, that finds those secrets on your own machine before they leave it.



What to do


If you issue keys:


  • Check whether a leaked key can be revoked without a person in the loop. If revoking needs a ticket and a human, build the endpoint.

  • Look at the program. It is free and open to any issuer, and it is early access. The release names Vercel in a supporting quote and lists no confirmed participants, so ask Truffle who has joined before you assume it covers your ecosystem.

  • Give keys a recognizable prefix and a checksum, so scanners can tell yours from random strings and test them safely.

  • Make keys short-lived by default. Google's 2024 change is the best evidence here.

If you hold keys:


  • Scan your own repositories, including history, and your agent settings files. Our scanner covers .claude/settings.json and .claude/settings.local.json. Run it with npx claude-settings-leak-check --root ~/code.

  • Rotate first, then delete. Deleting a pushed secret does not un-leak it.

  • Prefer keys that expire. Truffle's numbers show how long the other kind lives.


Indicators


None. This is research on leaked-key behavior, not a campaign, so there is nothing to add to the feed.



Limits


We read the announcement as carried by VentureBeat. We did not read Truffle's studies, the program page or TruffleHog's method, and we did not test any key. The headline of the VentureBeat article gives the launch figure as 14 million, while its body gives 1.4 million, so we use 1.4 million. Truffle sells secrets-scanning tools, so the program also serves its own business, which does not make the figures wrong. The 2.2 percent figure is about issuers that revoke on report, not about the program's results, which are too new to measure.


Five percent of this is wrong somewhere. It always is. Truffle's own report on how the 2.2 percent was calculated would show whether the comparison is like for like.




Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.


Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
bottom of page