Thousands of Leaked AWS Keys Remained Active for Years

That result is significant because a credential appearing in a public repository does not necessarily mean it is still dangerous. It becomes a serious active risk when the key has not been revoked, still authenticates, and retains meaningful permissions. In this investigation, all three conditions frequently overlapped.

Hundreds of corporate keys provided full administrative control

Of the active keys linked to corporate accounts, 817 were attributed to companies. The set included:

• 526 AWS root-account keys
• 242 IAM-user keys associated with AWS’s AdministratorAccess policy
• 768 keys in total that provided full administrative control of a company AWS account

Root credentials represent the highest level of control available to an AWS customer, while an IAM identity with AdministratorAccess can operate across AWS services with broad permissions. A valid key at either level can create a path to account takeover, unauthorized resource creation, data access, or cloud-billing abuse.

The findings therefore point to a permissions and lifecycle-management problem, not simply a source-code hygiene problem. Removing a key from a visible file does not protect an account if someone has already copied the credential; the key must be revoked or rotated.

Hugging Face was the largest individual source

Hugging Face accounted for 8,482 AWS credential exposures, making it the largest individual source identified in the reporting. Truffle Security reported that 17.9% of those AWS credentials were root credentials.

The result fits into a broader scan of public Hugging Face data. Truffle Security said it examined 7.6 petabytes of public datasets and found live credentials across thousands of datasets, showing how secrets can persist outside conventional software repositories and flow into publicly distributed data.

For security teams, the implication is straightforward: scanning only current source repositories is not enough. Git history, build artifacts, container images, published datasets, registries, and CI output can all preserve credentials after developers believe they have removed them.

The credentials were often years old and rarely rotated

The reported median credential age was approximately 1,831 days, or about five years. The oldest key was 17.4 years old. Only 13.7% of the entries had a newer associated key, suggesting that most had not been replaced through a normal rotation process.

Long-lived access keys increase the time available for unauthorized use and make ownership harder to establish. They can also survive staff changes, application migrations, repository cleanup, and changes in operational responsibility.

The practical lesson is that age should be treated as a risk signal. An exposed key that is several years old should not be assumed to be obsolete; it should be verified, revoked, and investigated unless its owner can demonstrate that it is no longer valid.

Budget monitoring was uncommon

Truffle Security could read account information for 2,754 accounts, but only 262 had AWS budget alerts enabled.

Budget alerts do not replace credential revocation or threat detection, but they can provide an early warning when exposed credentials are used to create costly resources—for example, in cryptomining or other forms of cloud abuse. Without a notification path that reaches someone able to respond, unusual spending can continue after an account has been compromised.

What AWS notifications do—and do not—solve

The reporting describes AWS protections that can detect disclosed access keys, notify affected customers, and apply restrictions or quarantine measures. However, the continued validity of so many tested keys indicates that notification or detection did not consistently lead to prompt customer-side revocation and rotation.

Detection is only the first step in credential response. A complete response must identify the owner, determine what the credential can access, check for misuse, and invalidate the key. Truffle Security characterizes its own validation as read-only: it checked authentication and permission or account metadata rather than modifying customer resources. That methodology is reported by Truffle Security and is not independently substantiated by every source provided here.

What organizations should do after an AWS key leak

1. Revoke or rotate the key immediately

Delete or disable any publicly exposed credential, then issue a replacement only if continued access is necessary. Removing the secret from a repository, deleting a file, or rewriting Git history does not invalidate copies that may already exist.

2. Eliminate root access keys

AWS root-user access keys should not be used for routine programmatic access. Delete root keys and move workloads to controlled identities with narrowly defined permissions.

3. Check permissions and ownership

Determine which account, user, service, and resources the credential belonged to. Prioritize keys with root privileges, AdministratorAccess, broad data access, or authority to create infrastructure.

4. Investigate before and after revocation

Review authentication activity, CloudTrail records, IAM changes, newly created resources, and billing for suspicious behavior. Revocation stops further use of the exposed key; it does not establish whether the key was already used.

5. Replace long-lived keys with short-lived identities

Where possible, use short-lived IAM roles and workload identities instead of permanent access keys. Least-privilege permissions reduce the damage a leaked credential can cause.

6. Configure budget alerts and a response path

Set AWS Budgets alerts and cost-anomaly monitoring, and route notifications to contacts who can act quickly. Financial monitoring is a backstop—not a substitute for secret scanning, credential rotation, and access review.

The broader security lesson

The investigation’s most important finding was not the raw number of secrets. It was the combination of public exposure, continued validity, high privilege, extreme age, and weak monitoring. Public data stores can preserve credentials long after an organization has forgotten where they were used, while a copied key can remain useful until it is explicitly revoked.

For cloud teams, the safer operating assumption is simple: treat every exposed AWS credential as compromised, verify what it can reach, rotate or revoke it immediately, and replace long-lived access with short-lived, least-privilege identities.