9,308 Publicly Exposed AWS Keys Still Worked in Truffle Security’s 2026 Research

Truffle Security’s August 2026 findings point to a cloud-credential problem that is both large and unusually persistent. Across public repositories, Git history, datasets, Docker images, container registries, and continuous-integration logs, researchers recorded 431,875 AWS-secret findings between August 2022 and August 2026. After deduplication and verification, the set contained 64,024 unique AWS keys. 145

The most consequential result was not simply how many credentials had been exposed, but how many still worked: 9,308 of 10,616 complete credential pairs tested on August 10, 2026—about 88%—successfully authenticated. 145

The exposed AWS credentials included high-privilege access

The verified key set included 10,625 root credentials, 48,744 IAM-user keys, and 4,655 keys that could not be classified. Root credentials represented 16.6% of the unique keys. 1

Truffle Security identified 817 active keys linked to businesses. Among them were:

• 526 root keys, the highest-privilege credential type in an AWS account.
• 242 IAM-user keys with AdministratorAccess, a policy that can provide full account control.
• 768 credentials in total that could give an attacker full control of a corporate AWS account.
• 130 active root keys for AWS Organizations management accounts, where compromise could potentially affect member accounts across an organization. 13

In a narrower group of IAM users whose policies could be enumerated, 976 of 1,157 readable users—84%—had AdministratorAccess. Another 144 had IAMFullAccess. Truffle cautioned that this was a directional figure because users permitting policy enumeration may not represent all leaked IAM users. 1

How many AWS accounts were affected?

The supplied reporting contains two account totals that appear to use different scopes. One summary describes the 64,024-key set as spanning 9,945 distinct AWS accounts, while the source report’s summary gives 50,654 distinct AWS accounts. The materials provided do not define why those totals differ, so they should not be treated as interchangeable. 1

The account-level risk is clearer in the privilege findings: hundreds of active credentials were tied to businesses, and 768 could provide full control of a corporate AWS account. 13

Hugging Face was the largest individual source

Hugging Face accounted for 8,482 unique live AWS keys across 3,394 public datasets, making it the largest individual source in the review. Root credentials made up 17.9% of those keys, the highest root-key share among the tracked sources. 125

The exposure was amplified by the way public code can be reused. Code snapshots containing secrets may be copied into training datasets and then distributed through multiple downstream datasets. Removing a credential from its original repository therefore does not guarantee that every copy has disappeared. 1

This AWS-focused result sits within a broader Truffle Security scan of Hugging Face. The company says it scanned 7.6 petabytes and 187 million files, finding 221,303 live, unique credentials across 6,003 datasets. Those figures cover all credential types, not just AWS keys. 6

Many exposed keys were years old and had not been rotated

Among 2,903 active keys whose creation dates could be read, the median age was 1,831 days—roughly five years. Half were more than five years old, the oldest was 17.4 years old, and only 25 keys, or 0.9%, had been created within the previous 30 days. 1

Only 398 of those 2,903 keys—13.7%—had a newer replacement key. That suggests that most had not been rotated, superseded, or cleaned up after exposure. 1

The practical lesson is straightforward: a secret that has appeared in public material should be treated as permanently compromised, even if the original file or repository entry has been edited. Git history, container images, package artifacts, and public datasets can preserve earlier copies. 1

Missing budget alerts increased the cryptomining risk

Budget controls were also uncommon. Of 2,754 accounts whose settings could be read, only 262—9.5%—had any budget alert configured. The median alert threshold was $8. 12

That left 90.5% of the readable accounts without a detectable budget alarm. An attacker with usable credentials could exploit cloud compute for cryptomining or other workloads before the organization noticed the unusual spending. 12

The accounts whose spending data was readable spent a combined $420,631 in July 2026. Fifty spent more than $1,000 that month, and nine spent more than $10,000. Those figures describe the observed accounts; they do not establish that the spending was caused by credential abuse. 1

AWS quarantine did not necessarily mean immediate invalidation

Truffle reported observing AWS attach the AWSCompromisedKeyQuarantine policy to exposed IAM keys. The policy restricts what a detected key can do, but does not necessarily disable authentication immediately. 1

Among the active IAM keys examined, 929 of 7,590—12%—carried that policy. Another 112 had an older version that AWS stopped applying in 2023. Truffle’s findings indicate that some keys remained usable despite long-standing exposure notifications. 1

A quarantine policy should therefore be treated as an exposure signal, not as proof that the underlying secret is safely retired. Organizations should investigate the key, identify its owner and permissions, and revoke or rotate it. 1

How the researchers tested the credentials

Truffle said it re-verified only credential pairs for which it had complete material. For account and privilege analysis, it used read-only IAM calls one key at a time, did not publish the key material, and notified every owner it could identify. 15

That methodology matters when interpreting the 88% figure: it applies to the subset of complete credential pairs that was re-tested, not to every public finding or every partial secret discovered during the scan. 14

What organizations should do now

The findings support a short incident-response checklist:

1. Delete root access keys. Truffle argues that root keys have no legitimate operational use. 1
2. Inventory every IAM access key, including keys in repositories, Git history, CI logs, images, registries, and published datasets. 1
3. Revoke or rotate exposed credentials immediately. Deleting a visible copy is not enough if the secret remains in historical or downstream artifacts. 1
4. Set a maximum key age and enforce rotation. Old, unused credentials should be removed rather than left available indefinitely. 1
5. Configure budget alerts. Even a low threshold, such as $10, can provide an early warning of unauthorized spending. 1
6. Monitor for AWSCompromisedKeyQuarantine and investigate it as evidence that a credential may have been exposed. 1
7. Use continuous secret scanning across source code, history, build systems, container artifacts, registries, and published datasets. 1

The central warning from the research is that public exposure is not a one-time leak. Without revocation, rotation, and monitoring, an AWS credential can remain a working path into cloud infrastructure for years.