AWS Credentials Leaked 2026: 9,300+ Keys Still Active

How big is the AWS credential leak problem in 2026?

Truffle Security has spent four years tracking publicly exposed AWS keys across code repositories, Git history, datasets, Docker images, registries and CI logs, according to BleepingComputer. Between August 2022 and August 2026 it uncovered 431,875 AWS secrets, which resolved to 64,024 unique keys and 50,654 distinct AWS accounts once duplicates were stripped out.

Of a re-verifiable subset of 10,616 keys, 88% still authenticated as of 10 August 2026. That is the detail UK buyers should sit with: this is not a legacy problem where old secrets have quietly expired. Most of what gets leaked simply keeps working, sometimes for years, until someone either finds and abuses it or an organisation finally rotates it.

Why root keys and admin access change the risk calculus

Among the exposed credentials, 817 keys were traced back to specific companies, and 526 of those were AWS root keys — the account's most privileged identity, unrestricted by IAM policy. A further 242 keys belonged to IAM users with AdministratorAccess. Together, researchers say 768 live keys across these two sets hand an attacker full control of a company's AWS account.

Full control means an attacker can read, exfiltrate or delete cloud-hosted data, hijack servers and applications, spin up rogue admin accounts for persistent access, or deploy cryptomining infrastructure at the victim's expense. For firms without mature Identity and Access Management (IAM) discipline, a single leaked root key can undo years of otherwise solid security work in minutes.

Where these credentials are actually leaking from

Hugging Face, the AI model and dataset sharing platform, was the single largest source in the dataset, accounting for 8,482 unique key exposures — 17.9% of which were root keys. That points to a growing blind spot: engineering and data science teams pushing code, notebooks or training artefacts to public or semi-public platforms without realising credentials are embedded inside.

This tracks with a wider pattern BleepingComputer has documented, including AWS keys turning up in public datasets, Common Crawl scrapes and open GitLab and GitHub repositories. Separately, The Register reported an AWS key exposed in public JavaScript build artefacts as the leading suspect behind a charity CRM provider's July breach — a reminder that front-end build pipelines, not just backend repos, are a live leak vector.

The rotation gap: keys that are years old and never renewed

For the 2,903 exposed keys with a recorded creation date, the median age was 1,831 days — roughly five years — and the oldest had been active for 17.4 years. Only 398 of those, 13.7%, had a newer access key associated with the same user, meaning the vast majority had likely never been rotated since creation.

Financial monitoring was equally thin: only 262 of 2,754 readable accounts had a budget alert configured, so even where a key was being abused for cryptomining or resource abuse, many organisations would have no early warning until the invoice arrived.

• •Median key age: 1,831 days (about five years)
• •Oldest exposed key still valid: 17.4 years
• •Keys with evidence of rotation: 13.7%
• •Accounts with budget alerts enabled: 9.5% of those checked

What UK infrastructure buyers should do this week

Truffle Security's own guidance, reported by BleepingComputer, is straightforward: delete all root access keys, review IAM credentials by age, rotate or revoke anything exposed, and configure budget alerts across every account. Any credential that has ever touched a public repository, dataset or build artefact should be treated as compromised, regardless of how long ago it was committed.

For UK teams, that translates into a practical audit cycle: inventory every active AWS key and its age, map which ones carry root or AdministratorAccess, and fold key hygiene into routine vulnerability management services rather than treating it as a one-off exercise. Pairing this with zero trust principles — least-privilege by default, no standing admin access — reduces the blast radius even when a key does leak. Firms should also have incident response planning ready specifically for cloud credential compromise, since containment (revoking keys, auditing CloudTrail logs, checking for rogue IAM users) needs to happen within hours, not days.

Part of a bigger machine identity problem

This disclosure lands alongside a broader shift in how non-human credentials — API keys, service accounts, CI/CD secrets — are becoming the primary attack surface in cloud environments, a trend Servnet has covered in depth around machine identity security. As AI tooling, automated pipelines and third-party integrations multiply, so do the places a credential can be accidentally published.

UK organisations evaluating their essential security tools stack should specifically check for secret-scanning coverage across code repos, container registries, CI logs and any AI/ML platforms staff use — not just the traditional GitHub and GitLab checks most teams already run.