Topic starter
21/08/2026 4:44 pm
TL;DR: Truffle Security re-verified 10,616 leaked AWS keys and found 768 live corporate keys still holding full control of AWS accounts, including 526 root keys and 242 IAM users with AdministratorAccess. The blast radius is defined at issuance, not discovery, because standing credential exposure keeps ownership, privilege, and remediation misaligned.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “768 Leaked Corporate AWS Keys Held Full Admin Rights”.
By the numbers:
- 768 of the live ones belong to a company and carry full control of its AWS account.
Key questions
Q: What breaks when a leaked AWS key is still active?
A: When a leaked AWS key is still active, the compromise is no longer about disclosure alone.
Q: Why do leaked AWS keys with AdministratorAccess create such high risk?
A: They turn secret exposure into broad account control.
Q: What are the signs that leaked AWS keys are failing governance controls?
A: Long-lived keys, unchanged key age, and leaked principals that still authenticate are strong warning signs.
Practitioner guidance
- Delete root access keys Find every root access key in every AWS account you own and remove it.
- Set a maximum access-key age Apply a hard age limit to IAM access keys and rotate before the limit is reached.
- Review leaked-key principals for account-wide privilege Prioritise any leaked key attached to AdministratorAccess, IAMFullAccess, or similar broad policy sets.
Bottom line: Leaked AWS keys remain dangerous when they still authenticate, because exposure turns into active access rather than historical risk.
What's in the full report
Truffle Security's full article covers the operational detail this post intentionally leaves for the source:
- The full re-verification method used to enumerate AWS principal type, policy names, and account metadata without reading policy documents
- The breakdown of how many leaked keys were root, IAM user, or not classifiable at verification time
- The account-level findings on budgets, spend, and quarantine policy coverage across the leaked-key population
- The methodology notes on how public sources such as repositories, datasets, and container images were deduplicated
👉 Read Truffle Security's analysis of 768 leaked AWS keys with full admin rights →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:04 pm
Leaked cloud credentials are not a disclosure problem alone, they are an access problem. Once an AWS key is public and still valid, the organisation has already lost control of the credential lifecycle. The governance failure is that secret detection often runs faster than revocation and replacement, leaving a standing path into cloud resources. The practitioner conclusion is simple: leaked NHI credentials must be treated as active access until proven otherwise.
A question worth separating out:
Q: How should security teams respond when AWS keys are exposed in public developer forums?
A: Security teams should treat any public secret exposure as an active compromise, not a theoretical risk. The immediate steps are to revoke or rotate the key, review cloud activity for misuse, and remove the exposed content if possible. Public forums can be scanned by attackers or opportunistic users within hours, so speed matters more than post-incident cleanup.
👉 Read our full editorial: 768 leaked AWS keys show full admin rights still persist