9,300 Leaked AWS Keys Still Work, 526 Are Root

A leaked cloud credential is usually described as an incident. This research describes it as a condition. Truffle Security scanned four years of public data — code repositories, git history, published datasets, Docker images, container registries, and continuous integration logs — and found that the overwhelming majority of the AWS keys it recovered had never been rotated, never been revoked, and in most cases never been noticed by the organization that issued them.

Key Takeaways

• Truffle Security found 431,875 AWS secrets across public sources between August 2022 and August 2026, narrowing to 64,024 unique keys across 50,654 distinct AWS accounts.
• Of the 10,616 keys with complete credentials the researchers could actually verify, 88 percent were still active as of August 10, 2026.
• 768 live keys granted full control of a company's AWS account — 526 were root access keys and 242 carried the AdministratorAccess policy.
• The median exposed key had been public for 1,831 days, roughly five years, and the oldest had been exposed for 17.4 years.
• Hugging Face was the single largest source, accounting for 8,482 unique exposures, of which 17.9 percent were root keys.

What Did Truffle Security Actually Find?

The research funnels from a very large raw number down to a small, verified, alarming one. The scan surfaced 431,875 AWS secrets in public sources over four years. Deduplication reduced that to 64,024 unique keys spread across 50,654 separate AWS accounts. Of those, 10,616 came with complete enough credential pairs that the researchers could test whether they still functioned. Roughly 9,300 keys were confirmed exposed, and 88 percent of the verifiable set was still active in August 2026.

Within that live population, 817 keys were traced to identifiable companies. The most serious subset numbers 768: keys that give complete authority over an AWS account. 526 of those are root access keys, the credential type AWS explicitly advises customers never to create. The other 242 carry the AdministratorAccess managed policy, which permits a holder to create, modify, delete, and view virtually every service and resource in the account.

Practically, holding one of those 768 keys means owning the environment. Read every S3 bucket. Read every database snapshot. Create new users, delete audit trails, spin up compute, and change the billing contact. There is no lateral movement stage, no privilege escalation chain, no exploit. The credential is the whole attack.

Why Have These Keys Not Been Rotated?

Because nobody knows they exist. The age data makes this plain: a median exposure of 1,831 days means the typical leaked key has been publicly readable for five years without anyone acting on it, and the oldest key in the set had been exposed for 17.4 years. Only 13.7 percent of exposed keys had a newer replacement key issued in the same account, which suggests the vast majority were not rotated even inadvertently as part of routine credential hygiene.

Git history is the structural reason so many of these persist. A developer commits a key, notices, deletes it in the next commit, and considers the matter closed. The file no longer shows the secret. The repository still does — every prior commit remains in the history, and anyone who clones the repository gets the entire history by default. Deleting the line does not delete the key, and this is the mistake that generates a very large share of long lived exposures.

The other reason is that the surface has grown faster than the scanning has. Repositories are the obvious place to look, and platforms scan them. Published machine learning datasets, layered Docker images, container registries, and CI job logs are not scanned with anything like the same consistency, and all four are now routine parts of a normal software pipeline. A key baked into an intermediate Docker layer is invisible in the final image's filesystem but fully recoverable from the layer archive.

There is a monitoring gap on top of the detection gap. Of 2,754 accounts whose billing configuration the researchers could read, only 262 had budget alerts configured. Cost anomalies are one of the most reliable signals that a stolen key is being used for cryptomining or bulk data transfer, and roughly nine in ten of these accounts had no such tripwire in place.

Why Is Hugging Face the Biggest Source?

Hugging Face accounted for 8,482 unique exposures, making it the largest single origin in the dataset, and 17.9 percent of those were root keys — a materially worse ratio than the population as a whole. The explanation is not that the platform is careless but that machine learning work has a different relationship to secrets than application development does.

Model repositories carry notebooks, training scripts, configuration files, and serialized artifacts. Notebooks in particular are written to be run, shared, and reproduced, and the fastest way to make one reproducible is to paste the credential directly into a cell. The data science toolchain also grew up outside the code review and secret scanning culture that hardened around web application repositories over the last decade. The concentration of root keys specifically suggests researchers reaching for the most permissive credential available to make an S3 bucket read work, rather than scoping an IAM role.

The pattern echoes what has been surfacing in other parts of the software supply chain, from AWS GovCloud keys leaked through GitHub to a poisoned Rust crate that ran an infostealer at compile time. The common thread is that developer infrastructure is now a primary target surface, and its credential hygiene has not caught up to that status.

What Has AWS Said?

Amazon's position is that it acts on exposures it becomes aware of. In its statement on the research, AWS said that any time it is aware of exposed keys it notifies the affected customers, and quickly takes necessary actions such as applying quarantine policies.

That is accurate and also the crux of the problem. AWS operates automated scanning against public GitHub and applies a quarantine policy when it detects an exposed key, which is why credentials leaked through the most heavily monitored channel tend to get caught quickly. The keys in this research are, largely by definition, the ones that channel missed — sitting in git history rather than a current file, in a dataset rather than a repository, in a Docker layer rather than source code.

The shared responsibility model puts credential lifecycle on the customer. Detection by the provider is a safety net, not the control, and this research is a measurement of how much falls through it.

What Should Teams Do This Week?

The remediation list from the research is short and unglamorous, which is usually a sign it is the right one.

• Delete every root access key. There is no supported workflow that requires one. 526 of the fully privileged live keys in this dataset were root keys, and none of them needed to exist.
• Sort IAM credentials by age and start at the bottom. A five year old access key is the median case here, not an outlier. Any key that predates your current deployment process deserves an explicit justification or deletion.
• Treat any credential ever committed publicly as compromised. Rotate it. Do not reason about whether anyone found it — the verification rate in this research suggests they can, and they have four years to try.
• Scan git history, not just the working tree. The deleted line is still in the commit graph, and that is where the long lived exposures live.
• Configure budget alerts. Only 262 of 2,754 readable accounts had them. It is a few minutes of setup and it is often the first signal that a stolen key is in active use.

For individuals rather than infrastructure teams, the transferable lesson is about credential lifespan. Exposed data does not expire on a schedule; it waits. The same dynamic drives the resale of old inbox credentials, as we covered in the analysis of 48 million Gmail logins circulating in an infostealer database. Rotating a credential you suspect has leaked costs minutes. Not rotating it, on this evidence, costs years of unmonitored access.

Sources: BleepingComputer: Hundreds of leaked AWS keys give full control over corporate accounts; Truffle Security research on exposed AWS credentials, August 2026; AWS IAM best practices on root user access keys.