Old leaks never die: more than 9,300 AWS keys are still valid, and dump shops know it
A leaked cloud credential is usually reported like an incident: something happens, someone responds, the story ends. New research shows the story often does not end at all. According to a report by BleepingComputer, more than 9,300 Amazon Web Services access keys exposed publicly between August 2022 and August 2026 were still active and valid this month.
What the researchers actually found
The security firm Truffle Security spent four years scanning public sources for exposed AWS credentials: code repositories, git history, datasets, Docker images, package registries, and CI logs. That scan surfaced 431,875 findings, which deduplicated down to 64,024 unique key pairs spread across roughly 50,654 accounts. For 10,616 pairs where complete credentials were available, the team re-ran authentication checks on August 10, 2026. As documented in the firm's own write-up, 88 percent still authenticated — over 9,300 live keys sitting in public for up to four years. Within that live population, 817 keys traced back to identifiable companies, and 768 granted full account control: 526 root access keys plus 242 IAM user keys carrying the AdministratorAccess policy. The two sets do not overlap, so those 768 credentials each hand an attacker complete authority over a business AWS account. One global consultancy had nineteen distinct leaked keys across separate accounts.Why old leaks stay dangerous
The age data is the uncomfortable part. Where creation dates could be determined, the median live leaked key was 1,831 days old — five years — and the oldest was 17.4 years. Only about 13.7 percent of dated keys had ever been superseded by a newer credential for the same user. These are not transient test tokens; they are long-lived keys nobody remembered owning. AWS does detect some exposures on its own and applies a quarantine policy called AWSCompromisedKeyQuarantine to keys it flags as leaked. But 929 of the active IAM users in the study already carried that policy — meaning AWS had flagged them — and they still authenticated. Worse, as The Next Web reported, analysts note the quarantine leaves plenty of room for damage: quarantined credentials can still assume other roles in the account, run commands on live instances via systems management tooling, and stop or delete CloudTrail logging, erasing the audit trail while they are at it. There is also a supply side. Stolen and scraped credentials get aggregated into combolists and dump shops, where buyers pay pennies per line and automated checkers validate everything before resale. A key that still works is inventory; a key revoked within hours is worthless. Every year a leaked credential survives, someone re-validates it and adds it back into circulation.The lesson self-hosters keep skipping
Deleting a secret from a repository does nothing by itself. The commit lives forever in git history, forks, mirrors, cached clones, CI logs, Docker layers, and increasingly public AI training datasets — Truffle Security's earlier analysis of public training data found thousands of still-active keys in published datasets alone. The credential stays valid until someone explicitly disables or deletes it in IAM. Exposure and revocation are two completely separate events, and the second one is optional unless you make it happen. This matters doubly if you operate onion services. Self-hosting behind Tor does not hide your cloud bill or your billing account: a compromised AWS or VPS-provider credential lets an attacker read your infrastructure metadata, snapshot volumes, redirect DNS, or simply spin up cryptominers on your card. Anonymity at the network layer is no substitute for hygiene at the credential layer. If you rely on uptime monitoring — our onion status checker included — assume the endpoints you watch are known to others too, and protect the account that pays for the servers, not just the ports they listen on.A practical checklist
Truffle Security's recommendations map cleanly onto any small operation:- Delete root access keys entirely. Roughly one in six leaked keys in the study was a root key, and there is no legitimate reason for one to exist today.
- List your IAM access keys and sort by age (
aws iam list-access-keys). Anything older than ninety days deserves scrutiny; anything you cannot name should be revoked. - Rotate, do not just remove. Create the replacement first, update the workload, then disable and delete the old key.
- Scan your own repositories and their full history with secret-scanning tools such as TruffleHog or gitleaks, not just the current branch.
- Prefer short-lived credentials: OIDC federation for CI pipelines instead of static keys baked into environment variables.
- Set budget alerts so anomalous spend surfaces in hours, not months.