More Than 9,300 Active AWS Keys Exposed Online: Hundreds Could Grant Full Account Control

Four Years of Monitoring Reveal Thousands of Valid Credentials

An analysis by Truffle Security identified more than 9,300 AWS access keys published online between August 2022 and August 2026 that were still valid. The findings were disclosed on August 21, 2026, following four years of monitoring.

The issue does not involve a vulnerability in AWS software, but the accidental exposure of credentials that could be used to authenticate to cloud accounts. The keys appeared in code repositories, Git histories, datasets, Docker images, registries, and logs generated by continuous integration systems.

Overall, the researchers found 431,875 AWS secrets. After duplicates were removed, the sample contained 64,024 unique keys associated with 50,654 AWS accounts.

The subset tested with complete credentials, allowing verification through a fresh authentication attempt, comprised 10,616 keys. 88% still authenticated successfully as of August 10. This suggests that a significant portion of the exposed credentials had not been revoked or replaced.

Root and AdministratorAccess Can Turn a Leak Into an Account Takeover

Among the active keys, 817 were linked to companies. Of these, 526 belonged to AWS root users, while 242 were associated with IAM users granted the AdministratorAccess policy.

These two categories carry the highest-risk privileges. The root identity represents the account’s highest administrative level and is not constrained by the permissions normally applied to IAM users. AdministratorAccess, meanwhile, allows users to create, modify, delete, and inspect virtually all resources and services in the account.

According to the researchers, 768 active keys belonging to these two privileged groups enabled full control of the corporate AWS account. This does not mean that every key was used by an attacker, but a publicly exposed and functional credential could provide an extremely broad point of entry.

With this level of access, an intruder could:

• read, copy, or delete data stored in the cloud;
• interfere with servers, applications, databases, and configurations;
• modify existing resources or create new ones;
• create fraudulent administrative accounts to maintain access;
• install cryptomining software, rapidly increasing costs;
• alter online services and infrastructure components.

The risk therefore extends beyond the theft of the key itself. An attacker could use it to modify the AWS environment and make malicious activity harder to distinguish from legitimate administrative operations.

Hugging Face Is the Largest Single Source of Exposed Keys

The platform associated with the largest number of exposures is Hugging Face, which is used to share artificial intelligence models, datasets, and applications. The researchers linked 8,482 unique key exposures to the platform.

Of these, 17.9% were root keys. The presence of AWS credentials in content published on an AI-focused platform can result from sample code, notebooks, datasets, configuration files, or material uploaded during development.

A key published in a public project should be considered compromised even if the repository is later made private or the file is deleted. Copies may remain in Git history, forks, caches, downloaded datasets, or indexing systems.

The affected organizations may face different consequences depending on the resources in their accounts, including data exposure, application outages, infrastructure changes, or unexpected costs from services created without authorization.

Aging Credentials and Weak Cost Controls Increase the Risk

The age analysis, available for 2,903 keys, found a median age of 1,831 days, or approximately five years. The oldest key had existed for 17.4 years.

Only 398 entries, or 13.7%, had a newer access key associated with the same user. Truffle Security said this suggests that many credentials had probably never been rotated.

A key that remains active for years creates a longer window in which it can be collected and reused. In addition, the existence of a newer key does not automatically prove that the older one was revoked; this must be verified directly in the account configuration.

Cost management further compounds the problem. Only 262 of 2,754 accounts for which the data was readable had a budget alert configured. Without alerts, an attacker can create cloud resources or launch resource-intensive activities without the account owner receiving a timely warning.

The operational environment remains challenging even when an organization has defensive tools in place. The Blue Report 2026, based on 338 million simulations in customers’ production environments, indicates that when an attacker uses valid credentials, only 37% of actions are blocked. A valid key can therefore bypass many controls designed to detect unauthorized access.

What AWS Account Owners Should Do

The priority is to revoke every key that has appeared in a public source and replace it with new credentials, rather than simply deleting the file containing it. Rotation should be accompanied by log reviews to identify suspicious authentications or changes.

Key recommendations include:

1. remove root access keys;
2. inventory IAM credentials based on age and last use;
3. immediately revoke or rotate exposed keys;
4. review recently created users, roles, policies, and administrative accounts;
5. configure budget alerts and spending thresholds;
6. search repositories, Git histories, Docker images, datasets, and logs for exposed keys;
7. treat any published credential as compromised, even when no abuse has been detected.

For ongoing operations, organizations should prefer IAM roles and temporary credentials, reducing reliance on static keys. Secrets should never be embedded in code or datasets; they should be stored in dedicated systems and scanned automatically before publication.

Truffle Security said it limited its testing to reading metadata and notified all identifiable owners. It is not known how many accounts were actually compromised or how many attacks exploited the identified keys. The confirmed findings are nevertheless sufficient to treat every exposed credential as untrusted.