Breach · Access Control

Hundreds of Leaked AWS Keys Give Full Control Over Corporate Accounts

August 24, 2026 · 6 min read

On August 10, 2026, Truffle Security published findings from a large-scale scan of public repositories, datasets, container images, and CI logs. They re-verified 10,616 leaked AWS access key pairs and confirmed that 88% of them, more than 9,300 keys, still authenticate against AWS today. Of those, 817 are tied to businesses, and 768 of those business-linked keys carry full administrative control over their respective AWS accounts. If you run workloads in AWS, or if any of your vendors or partners do, this finding warrants a direct look at your own key hygiene right now.

What actually happened

Truffle Security's scanners combed through git history, Hugging Face datasets, Docker images, package registries, and CI logs, turning up 431,875 raw credential findings. From those, they extracted 64,024 unique AWS key pairs spanning 50,654 AWS accounts. The 10,616 key pairs they re-verified on August 10 represent the subset they could actively confirm. The 88% live rate on those re-verified keys is what makes this more than a research curiosity.

Among the 817 business-linked live keys, 526 are AWS root credentials and 242 are IAM users with AdministratorAccess attached (these are non-overlapping sets), producing 768 keys that give whoever holds them complete control of a company's AWS account. Beyond account-level compromise, 130 of the live root keys belong to AWS Organizations management accounts. A compromise of any one of those exposes every member account in that organization's hierarchy.

One global consultancy had 19 distinct leaked keys across separate AWS accounts. The affected sectors skew toward software, cloud, and IT consulting, which tracks with the sources where the keys were found. Hugging Face alone accounted for 8,482 unique live keys across 3,394 public datasets, with roughly 18% of those being root credentials.

The age and rotation data tell the more uncomfortable part of the story. Among the 2,903 keys for which creation dates were available, the median age was 1,831 days, approximately five years. The oldest key had been active for 17.4 years. Truffle Security found that 86% of the leaked keys had no newer replacement key associated with the same user, meaning they had never been rotated after being exposed. Only 9.5% of the accounts with readable budget settings had any AWS budget alert configured, and the median configured budget limit among those was $8. The accounts behind the readable keys collectively spent $420,631 in July 2026 alone, with 50 accounts spending over $1,000 and 9 accounts spending over $10,000 in that single month.

Why this should matter to you even if you don’t run AWS

The instinct when reading research like this is to ask whether your organization is in the dataset. That is the wrong starting question. The right question is whether the conditions that put those 768 keys into public repositories also exist in your environment, because those conditions are common across most engineering teams.

Keys get embedded in source code during development and committed before anyone catches them. They end up in CI/CD pipeline configurations, in container build arguments, in Jupyter notebooks published to Hugging Face, in package metadata. The Truffle Security findings span sources that represent entirely normal parts of a modern software delivery workflow. The organizations represented in this dataset were probably following standard practices for their time. The problem is that their key hygiene did not keep pace with where their artifacts ended up.

The AWS Organizations management account exposure deserves specific attention. A management account root key is one of the highest-privilege credentials in any cloud environment. Compromising it gives an attacker the ability to affect every account in the organization: creating new accounts, modifying SCPs, accessing billing data, and potentially disabling logging across the board. The blast radius of a management account compromise is categorically different from a single-account compromise, and 130 of those keys are confirmed live in public sources right now.

For organizations that share code with partners, use third-party CI systems, or publish datasets or models to public platforms, the exposure surface extends beyond your own repositories. One of the reasons the affected sectors skew toward software and cloud consulting is that those organizations tend to have dense interconnections between internal tooling and external platforms. If your engineering workflow touches any of the sources Truffle Security scanned, your keys have been in those pipelines.

The control that would have blunted it

The specific control category here is access control, and within that, credential lifecycle management. The practical remediation has two parts: finding what has already leaked and changing the conditions that allow long-lived keys to accumulate in the first place.

For the immediate finding, any organization running AWS workloads should be running pre-commit secret scanning and periodic retrospective scanning of their git history, container registry, and any public artifact repositories. AWS itself offers Amazon Inspector and AWS Secrets Manager for some of this, and third-party tools like TruffleHog, GitGuardian, and similar products are purpose-built for the retrospective scanning problem. The priority is to establish a baseline: what keys exist, when they were created, and whether any have appeared in public sources. AWS CloudTrail logs are the primary mechanism for checking whether a leaked key has been used, and that review should happen before rotation to understand what an attacker may have already accessed.

On the structural side, the shift away from long-lived IAM access keys toward short-lived credentials using IAM Identity Center (formerly AWS SSO) or role-based access with AssumeRole is the right direction for most organizations. Short-lived credentials have a bounded exposure window by design. A key that expires in an hour provides a much smaller attack surface than one that has been sitting in a public repository for five years. That shift carries a real operational cost: existing automation that relies on long-lived key pairs needs to be updated, and teams need to be trained on the new credential flow. That is worth acknowledging. The migration is not frictionless, especially in organizations with sprawling legacy automation.

On AWS Organizations management accounts specifically, root credentials should have no programmatic access keys attached at all. AWS has guidance on this, and it is one area where the configuration is straightforward: delete any root access keys on management accounts and enforce that through an SCP that prevents their creation. This is a control that cyber insurers and compliance frameworks like SOC 2 and ISO 27001 are increasingly asking about explicitly. If your insurer asks about privileged access management and key rotation policies, this is the evidence they want to see.

Rotation alone addresses only part of the risk. The 86% of leaked keys that were never rotated represent one failure mode, but rotation on a fixed schedule, say every 90 days, only helps if the rotation actually happens and the old key is fully revoked. Many organizations rotate keys on paper and leave old keys active in parallel for weeks because something breaks when the old one is disabled. The rotation policy needs to include a hard revocation step with a defined deadline, not just the issuance of a new key.

Strondex's cloud security services include credential exposure assessments and access control reviews designed to identify long-lived keys, overprivileged IAM roles, and gaps in secret scanning coverage before they appear in the next research dataset.