Researchers Tested 10,616 Leaked AWS Keys. 88% Still Work, and One of Them Is Probably Yours From 2019.

Truffle Security re-verified 10,616 AWS key pairs that had leaked publicly between August 2022 and August 2026. They ran the check on August 10, 2026. 88% still authenticated. Of the 9,308 keys that were still live, 817 belonged to companies, and 768 of those had full administrative control of the account.

That number is the one that got attention. The number I cannot stop thinking about is 1,831.

Rotation is the rare event

For the keys where creation dates could be enumerated (about three in ten), the median age of a still-live leaked key was 1,831 days. Call it five years. The oldest was created 17.4 years ago and still works. Only about two dozen of the keys in the whole set were from the last 30 days.

Then there is the rotation figure. Of the 2,903 keys where researchers could enumerate the IAM user's other access keys, only 398 had any newer key sitting alongside the leaked one. That is 13.7%. The other 86% were never rotated, never superseded, never cleaned up.

Every breach postmortem you have ever read contains the sentence "all affected credentials have been rotated." This data says that for the overwhelming majority of exposed keys, nobody did anything at all. Not slowly. Not partially. Nothing.

My favorite detail, and I mean this as a compliment to whoever wrote the report: 929 of the 7,590 active IAM users (12%) were already carrying AWS's own AWSCompromisedKeyQuarantine policy. AWS noticed. AWS attached the quarantine policy. The keys still authenticate. Nobody on the owner's side acted on it.

The 768 breaks down worse than the headline

"768 keys with admin access" flattens a distribution that gets uglier the closer you look. 526 of them are root access keys. Another 242 are IAM users holding AdministratorAccess.

And at the far end: 130 live root keys on organization management accounts. That is the account that controls every member account in the org. One of those is not one compromised account, it is every account underneath it, at once.

The largest single source of exposed keys, per the report, is Hugging Face. Not GitHub, not Docker Hub. Hugging Face. If you have ever pushed a notebook, a dataset card, or a model repo with a config file in it, that is worth sitting with for a second.

Why I think this is a solo operator story

The instinct is to read this as an enterprise governance failure, and it partly is. But look at the profile of the typical exposed key: created five years ago, attached to an account nobody logs into, never rotated, spending nothing.

That is not a Fortune 500 IAM problem. That is a side project.

I have a personal AWS account from around 2018 that I used for exactly one thing, a scraper I no longer run. I know for a fact I generated a root access key back then because IAM felt like too much ceremony for a weekend project. I have not thought about that key in years. Reading this report, the honest question is not "did I leak it" but "would I know if I had."

The Truffle Security recommendation is blunt and I agree with it: check every account you own, including the personal one from 2019.

The money is small until it is not

Across the accounts where spend could be checked, the leaked keys were attached to $420,631 of AWS spending in July alone. That averages out to something unremarkable. The distribution does not.

Nine keys spent over $10,000 last month. Forty-one spent between $1,000 and $10,000. The rest are the abandoned experiments, costing the owner nothing, which is exactly why nobody notices them.

The budget alert stat is the one worth acting on. Of 2,754 accounts with budgets exposed, only 262 had budget alerts configured, and the median configured ceiling was $8.

An $8 budget alert is a free-tier guardrail. It is the number you set when you are worried about accidentally leaving an EC2 instance running, not when you are worried about someone mining crypto on your credentials. If your alert fires at $8 and your attacker is spending $12,000, the alert told you something on day one and then you learned to ignore it. That is worse than no alert, because it trained you to dismiss the channel.

What I'd actually do

This is a Saturday-morning job, not a project. Four steps, in order of how much they will annoy you.

Delete root access keys entirely. Not rotate. Delete. There is no legitimate reason for a root access key to exist on an account you own in 2026. AWS has been saying this for years and this report is the receipt. If you have one, you created it before you knew better, which is exactly the population this study measured.

Enumerate accounts you forgot you had. Check the email addresses you have used over the years against AWS account recovery. The 2019 personal account is the whole point of this exercise, and it is the one you will not think of because it is not in your password manager under "work."

Fix the alert thresholds you already have. Two tiers, not one. Something small so you notice drift, and something at genuine pain level (I use 10x my normal monthly spend) so a real incident cannot hide under alert fatigue. The $8 median in this data is a monument to single-tier alerting.

Search your own public artifacts, not just your git history. Everyone greps their repos. Almost nobody checks Hugging Face repos, published Docker images, or CI logs from a job that ran three years ago, and those are named in this report as sources. If you have ever run docker push on an image built with a .env in the build context, that is a layer sitting in a public registry right now.

Assume any key you find is compromised rather than trying to determine whether it was. You cannot prove a negative here, and CloudTrail on an account you abandoned in 2019 will not go back far enough to help.

Where this argument is weaker than it sounds

Two caveats I owe you.

The 88% figure measures whether a key authenticates, not whether it is dangerous. sts:GetCallerIdentity succeeding tells you the credential is live; it says nothing about what permissions sit behind it. A large share of that 9,308 is probably keys scoped to a single S3 bucket full of nothing. The 768 admin keys are the actual story and they are 7% of the live set, not 88%.

Also, the sample is not random. These are keys that leaked publicly and were collected by a security vendor that sells secret scanning. Keys that leak and get caught quickly by the owner exit the population; keys that rot for five years stay in it. So "the median leaked key is five years old" is partly a statement about how the sample was built, not only about human behavior. The rotation finding (86% never superseded) is the one I would defend hardest, because it is measured against AWS's own key list per user rather than against the leak corpus.

None of that changes the recommendation. Deleting a root key you do not use costs you four minutes.

Author

Lukas

@lukcombinator

Sources

• Major security oversight: 88% of leaked AWS keys still work
• Hundreds of leaked AWS keys give full control over corporate accounts
• 768 Leaked AWS Keys Still Active With Full Admin Access to Corporate Accounts
• Researchers found 768 leaked AWS keys that still work, and the containment policy leaves plenty possible