Truffle Security published research on August 21 showing that thousands of AWS access keys leaked into public sources over the past four years are still live credentials today, many with root-level or full-administrator access to corporate cloud accounts. This isn’t a single breach or a new CVE — it’s a systemic secrets-sprawl problem that most infrastructure teams underestimate, and the numbers make the exposure concrete.

What was found

Researchers scanned public sources for AWS credentials exposed between August 2022 and August 2026, turning up 64,024 unique AWS key pairs across 431,875 individual findings in Git history, Hugging Face datasets, Docker images, public package registries, and CI/CD logs. Hugging Face alone accounted for 8,482 of the unique key exposures — training data, notebooks, and config files checked into model repos are turning into one of the largest unmonitored credential leak vectors in the industry.

Of those, the team re-verified 10,616 complete key pairs against the live AWS API on August 10. 9,308 of them — 88% — still authenticated successfully. That’s the headline risk: these aren’t stale test credentials, they’re working keys sitting in public view.

Narrowing to keys tied to identifiable companies, 817 corporate keys were still live. Breaking that set down:

  • 526 were root account keys — AWS’s highest-privilege credential type, which bypasses IAM policy restrictions entirely.
  • 242 belonged to IAM users with the AdministratorAccess policy attached — functionally equivalent to root for most purposes.
  • These sets don’t overlap, meaning 768 of the 817 corporate keys grant an attacker full, unrestricted control of the account.
  • 130 of the live root keys belong to AWS Organizations management accounts — compromising one of these can cascade to every member account under that organization.

Age compounds the risk. Among keys with a determinable creation date, the median age of a still-active leaked key was 1,831 days — roughly five years. The oldest verified credential was 17.4 years old, meaning it predates most current IAM tooling and almost certainly predates whatever access review process the account has today.

Why this matters

An attacker with a live root or admin key doesn’t need to exploit anything — they authenticate like any legitimate operator. From there: exfiltrate S3 buckets, spin up EC2 fleets for cryptomining, pivot through IAM to create persistent backdoor users, or in the case of Organizations management-account keys, reach into every linked subaccount at once. Because these keys have often sat exposed and unrotated for years, there’s no reliable way for a victim organization to know whether they’ve already been used maliciously — most CloudTrail retention windows don’t go back far enough to check.

The root cause isn’t exotic. It’s the usual mix of hardcoded credentials committed to git history that “removal” commits don’t actually erase, secrets baked into Docker image layers, notebooks and datasets uploaded to Hugging Face with embedded config, and CI logs that echo environment variables into build output that gets archived indefinitely.

Mitigation

If you run AWS infrastructure, treat this as a prompt to check your own exposure rather than someone else’s incident:

  • Kill root access keys entirely. AWS root accounts almost never need long-lived access keys — delete them and enforce MFA on the root user instead.
  • Rotate on a schedule, not on suspicion. A key that’s five years old has had five years to leak somewhere you’ll never find out about.
  • Scan your own history and artifacts. Run a secrets scanner (TruffleHog, gitleaks, or equivalent) across git history, Docker images, and any Hugging Face repos your org publishes — not just current source trees.
  • Move off long-lived IAM keys where possible. Use IAM roles with short-lived STS credentials, OIDC federation for CI/CD, and instance/task roles instead of static access keys.
  • Enable and extend CloudTrail retention, and pull recent access-key usage reports to check for logins from unfamiliar IPs or regions on any key you find was ever public.

Full findings: Truffle Security research.