Researchers Find 9,300+ Active Leaked AWS Keys

The Scale of the Exposure

Truffle Security, a cybersecurity vendor, announced its scanners found 64,024 unique AWS key pairs. These keys appeared across 431,875 public findings, spanning Git history, Hugging Face datasets, Docker images, package registries, and CI logs.

The firm re-verified 10,616 pairs with complete credentials, and 88% of these keys remain active according to the report. That figure includes 768 corporate AWS keys providing full admin rights, meaning nearly nine in ten confirmed leaks are still usable by anyone who finds them.

Keys That Never Get Rotated

The median age for active leaked keys with creation dates is around five years. Some keys are over 17 years old, sitting exposed and functional the entire time. Truffle Security’s data points to a broader pattern of neglect rather than a one-off mistake.

Only 13.7% of enumerated user access keys had a newer key alongside the leaked one. The remaining 86% were never rotated, superseded, or cleaned up, which means most organizations aren’t just leaking keys once. They’re leaking keys and then never noticing.

Why Hugging Face Keeps Showing Up

Hugging Face datasets emerged as the largest single source of these leaked credentials. Researchers discovered 8,482 unique live keys across 3,394 public datasets there, and 18% of these keys possessed root privileges.

The pattern makes sense once you consider how datasets get built. Developers often bundle notebooks, config files, and environment variables together when publishing training data or model artifacts, and credentials hardcoded during development get swept up in that process. Unlike a GitHub repo where a security scanner might flag an obvious API key pattern, dataset files are less consistently screened for secrets before being made public.

What a Leaked Key Actually Enables

AWS account takeovers allow malicious actors to steal or delete critical cloud data outright. Attackers can also quietly install cryptocurrency mining software to monetize access, a common and profitable tactic once inside.

Not every leaked key carries the same risk. A key with admin rights or root privileges hands an attacker the ability to spin up new resources, exfiltrate data across services, and cover their tracks by modifying logs. A narrowly scoped key limited to a single S3 bucket is a problem, but a contained one. The 768 corporate keys with full admin access represent the worst-case scenario in this dataset, since there is effectively no boundary on what an attacker can do with them.

The Silence After a Breach

Despite the risk, only 9.5% of the compromised accounts had a budget alert configured. Such alerts could flag unusual activity, like unauthorized crypto-mining, early enough to limit damage. For context on similar threats, see CISA’s response to exposed AWS GovCloud keys.

That 90.5% gap means most organizations with a leaked key have no early warning system at all. A compromised account can run up thousands of dollars in unauthorized compute costs before anyone notices, often only when the bill arrives.

Fixing the Leak Doesn’t Fix the History

Truffle Security urges organizations to improve key handling by deleting root access keys, sorting IAM keys by age, and setting budget alarms. Even a $10 alert is a meaningful improvement given how few accounts have any threshold set.

Treat exposed secrets as permanently compromised, not as something a quick fix resolves. Approximately 43% of discovered keys appeared multiple times across various public repositories and datasets, meaning the same credential often gets copied, forked, and re-published long after the original leak. Deleting a secret from a current commit doesn’t remove it from Git history, where it remains fully retrievable by anyone who checks out an earlier version of the repository. Watch for AWS’s AWSCompromisedKeyQuarantine policy, which is AWS’s own signal that a key has been flagged as publicly exposed.

Hashlytics Take

The 88% active rate is the number worth sitting with. That’s not a report about credentials being leaked, it’s a report about how rarely anyone checks whether their leaks were ever cleaned up. Truffle’s numbers reflect their own scanning universe, not every AWS credential in existence, so the real total is almost certainly higher. If your organization has ever committed a config file to a public repo or published a dataset with embedded notebooks, the responsible move isn’t waiting for a scanner to find you. It’s assuming a leak already happened and rotating accordingly.