Truffle Security: 1.4 million exposed secrets still work

Truffle Security says 1.4 million publicly exposed secrets are still valid. BleepingComputer reported the figure on November 5, 2026, alongside a free Secrets Revocation Program aimed at the companies that issued the keys. The public headline rounds the pile to nearly 1.5 million. The operational number is the one that still authenticates.

The company has been pulling credentials out of public repositories, packages, container images, datasets, and shipped applications since 2022. Earlier this year it reported 543,000 valid credentials in public GitHub repositories. A separate pass found more than 431,000 AWS secrets across repositories, git history, datasets, Docker images, registries, and CI logs. The usual path is ordinary development: a key committed in public, baked into an image or a package, or left in a config file that rode along with an app or a dataset.

Notification has failed as a control. Truffle’s account is blunt about the follow-through: 81% of the keys it reported last year still worked six months later. A live key in public is a standing credential. The damage reaches the issuer’s customers and anyone downstream of the app that embedded it.

Coding agents have added a pile that did not show up in the prior year. Since January 2025, Truffle says it has found 2,655 working keys in the config files those tools leave behind. The same researchers point at a July OpenAI incident in which agents used exposed Hugging Face tokens and data left that platform. A token checked into an assistant’s config is already outside the repo you meant to publish.

Revoke at the issuer, on a clock

The new program tries to skip the developer who never reads the disclosure mail. Truffle checks that a leaked value still works, then asks the issuer to kill it. The issuer can expose a revocation endpoint, or take verified keys over a webhook and revoke them within 14 days. Sixteen issuers have joined, including Hugging Face, Notion, Vercel, Resend, RubyGems, and Twilio.

Google is the case they use for why the issuer has to act. On June 16, 2024, Google began disabling exposed Google Cloud service-account keys by default. While Google only notified owners, Truffle found 72% of those exposed secrets still active. Automatic disablement cut the share to 11%. Customers can opt out, so the residual is real. The drop is what a default revocation policy buys.

What key issuers and key holders do now

If you mint API keys, give researchers and partners a revocation path that fires when the owner stays silent. Notify the customer, disable the key, and log the disablement so a broken deploy has an explanation. An opt-out belongs in a ticket with a named owner. It should be rare.

If you hold keys, treat public git history, published images, packages, datasets, CI logs, and local AI-tool config as places a live secret may already sit. Rotate at the provider, then revoke the old value. Deleting the file leaves the credential alive for anyone who copied it. Search the assistant config on developer machines for provider keys, and rotate those too. The 2,655 figure is keys that still worked, found in files a coding tool wrote.

Alert when a key that normally serves one app shows up from a new automation identity, a new geography, or a volume the app has never produced. The 81% figure is the argument for a deadline measured in hours. An email to the developer is a courtesy. The revocation is the control.

This briefing relies on public reporting by BleepingComputer and on Truffle Security’s account of the program. It does not describe how leaked secrets are found or abused.