The discovery of more than 9,300 still-valid AWS access keys exposed publicly over the past four years is a striking reminder that cloud compromise does not always require exploitation of a sophisticated vulnerability. Sometimes the attacker simply finds a credential that an organisation has accidentally published and then discovers that nobody ever bothered to revoke it. Truffle Security identified 431,875 AWS secrets across code repositories, Git history, public datasets, Docker images, registries and CI logs, which were reduced to 64,024 unique AWS access keys associated with more than 50,000 AWS accounts. Of the subset for which complete credentials were available for re-validation, 88% were still active as of August 10, 2026.

The most alarming aspect is not simply the number of exposed keys, but the privilege attached to many of them. Truffle Security identified 817 exposed credentials associated with companies, including 526 AWS root access keys and 242 IAM credentials carrying the AdministratorAccess policy. Together, 768 live credentials in these two categories effectively provided full control over the corresponding AWS accounts. An attacker possessing one of these credentials could potentially create, modify or delete resources, access cloud-hosted data, deploy new workloads, create additional privileged users and establish persistence inside the environment.

Root access keys are particularly dangerous because the AWS root identity is fundamentally different from an ordinary IAM user. Root credentials have unrestricted access to resources and account-level functions and are not constrained through ordinary IAM permissions in the same way as standard identities. AWS explicitly recommends that organisations should not create root-user access keys except in extremely unusual circumstances and should remove existing root access keys wherever possible. The fact that hundreds of publicly leaked root credentials remained valid therefore represents not merely accidental secret exposure but a failure of identity architecture.

AdministratorAccess credentials are only marginally less alarming. The AWS managed AdministratorAccess policy effectively grants `Allow` permissions across all actions and resources. An attacker obtaining such a key does not need to discover a privilege-escalation vulnerability because the privilege escalation has already been thoughtfully preconfigured for them. They may be able to create additional IAM identities, attach policies, assume roles, manipulate infrastructure, access databases and storage or disable security controls depending on the broader account configuration. Truffle Security's analysis also highlights that apparently limited IAM credentials may have trust relationships allowing them to assume much more powerful roles, meaning the permission attached directly to a leaked key does not necessarily represent the full extent of its potential access.

This distinction is important for incident response. Security teams should not look at a leaked key and ask only, "What permissions does this IAM user have?" They also need to ask which groups the identity belongs to, which roles it can assume, which trust policies recognise it and whether those roles can subsequently assume other roles. AWS IAM environments can contain complex privilege paths, and a credential that appears relatively harmless at first glance may ultimately lead to administrative access several trust relationships away.

The age of these credentials is another disturbing finding. For the 2,903 exposed keys where creation dates were available, the median age was 1,831 days, or approximately five years, and the oldest credential had existed for more than 17 years. Only 13.7% had a newer access key associated with the same identity, suggesting that most had never been rotated. This illustrates one of the fundamental problems with long-lived cloud credentials: once created, they can quietly survive for years because applications continue functioning and nobody wants to discover which forgotten script breaks when the key is removed.

That convenience becomes extremely dangerous after exposure. An access key is essentially a machine-readable username and password. There is no requirement for MFA when an application presents a valid Access Key ID and Secret Access Key to an AWS API. Anyone possessing those credentials receives whatever permissions belong to the associated identity. AWS documentation states this very plainly: anyone who possesses your access keys has the same level of access to AWS resources that the legitimate owner has.

This is why leaked cloud credentials are often more immediately useful to attackers than stolen human passwords. A normal account may require MFA, device compliance, Conditional Access or additional identity verification. A long-lived programmatic credential may simply continue authenticating until somebody explicitly disables it. It also works very conveniently with automation. Attackers can continuously scan public repositories and datasets for credential patterns, test discovered keys and automatically enumerate what each credential can access.

The scale of exposed secrets in AI-related datasets deserves particular attention. Hugging Face was identified as the largest single source in the research, accounting for 8,482 unique AWS key exposures. In earlier analysis of 7.6 petabytes of publicly available AI training data on Hugging Face, Truffle Security discovered 3,343 live AWS keys, of which more than 900 could enumerate S3 buckets containing at least 51.7 TB of private information. This illustrates a rapidly expanding secrets-management problem: credentials are no longer leaking only into Git repositories. They can end up inside datasets, model-training corpora, notebooks, containers, logs and other artefacts that are subsequently copied and redistributed at enormous scale.

Once a secret enters a public dataset, deleting the original file may provide almost no meaningful containment. The credential may already have been copied into forks, container layers, archived repositories, mirrors, training datasets or search indexes. This is why organisations should treat any credential that has appeared in a public location as permanently compromised. Removing the file is useful for reducing future discovery, but the credential itself must be revoked or rotated. BleepingComputer specifically notes that Truffle Security recommends treating every credential committed to a public source as compromised.

The potential impact goes well beyond data theft. Full AWS administrative access could allow an attacker to terminate EC2 instances, delete S3 objects, interfere with databases, modify networking, change IAM permissions or create rogue administrative users for persistence. Attackers could also deploy expensive compute workloads such as cryptocurrency miners or GPU instances, leaving the victim with substantial cloud charges. Truffle Security found that only 262 of 2,754 readable accounts had configured budget alerts, meaning many organisations might not even receive early financial warning if stolen credentials were abused for resource creation.

Budget alerts obviously do not prevent compromise, but they can provide an additional detection signal. A sudden increase in EC2, GPU or other resource consumption may reveal credential abuse before the organisation notices other signs. Cloud billing therefore belongs in security monitoring rather than being treated solely as a finance concern. Attackers creating dozens of expensive compute instances at 3 a.m. may be expressing their malicious intent through the accounting department before the SOC sees anything interesting.

The first defensive priority should be eliminating unnecessary long-lived access keys altogether. AWS recommends using IAM roles and temporary credentials rather than embedding static access keys directly into applications. EC2 workloads can obtain temporary credentials from attached IAM roles, container workloads can use workload-specific identities and users can access multiple AWS accounts through IAM Identity Center. Temporary credentials automatically expire, drastically reducing the useful lifetime of anything accidentally exposed.

Root access keys should be removed completely. AWS explicitly states that one of the best ways to protect an AWS account is to avoid generating root-user access keys and to disable and remove existing ones. Daily administration should instead be performed using appropriately protected administrative identities through IAM Identity Center. Root credentials should be reserved for the very small number of account-management functions that genuinely require them.

For IAM users that still require programmatic credentials, least privilege becomes critical. Applications should receive only the exact API permissions and resources they require. An application that uploads files to one S3 bucket should not receive AdministratorAccess simply because it was easier than designing the correct IAM policy. If such a key leaks, limited permissions can transform a catastrophic account takeover into a much smaller and more manageable incident.

Organisations should also audit the age and usage of every existing IAM access key. Credentials that have not been used recently should be disabled and eventually deleted. Long-lived keys should trigger review, and owners should be identifiable so security teams know which application will be affected during rotation. AWS provides credential reports and access-key usage information precisely for this purpose. Organisations managing multiple AWS accounts should centralise this inventory rather than reviewing each account manually.

Secret scanning needs to cover the entire software-development lifecycle. Git repositories should be scanned both before commits are accepted and continuously after publication. Push protection capable of blocking commits containing recognised secrets is considerably more effective than sending an alert after the credential has already appeared in a public repository. CI/CD logs, Docker images, package artefacts, Terraform state, `.env` files, notebooks and build outputs should also be included because secrets have an impressive ability to migrate into whichever file nobody remembered to scan.

Historical Git content deserves special attention. Removing a secret from the latest version of a file does not necessarily remove it from Git history. Anyone can inspect earlier commits and retrieve the original value. Security teams therefore need tools capable of scanning entire repository histories rather than merely the current branch. Even if the history is later rewritten, the exposed credential should still be rotated because forks and clones may retain the original commit indefinitely.

AI development workflows now need to be included in the same controls. Developers should not paste AWS keys into prompts, notebooks, training datasets or model examples. Organisations should apply data-loss controls and secret scanning to AI pipelines just as they do to source-control systems. The Hugging Face findings demonstrate that AI datasets can unintentionally become enormous archives of credentials originally leaked somewhere else.

CI/CD systems deserve particularly strict treatment because they naturally interact with cloud credentials. Build pipelines should use workload identities, OIDC federation or short-lived STS credentials wherever supported rather than storing static AWS secrets as environment variables. Modern CI platforms can obtain temporary AWS credentials based on signed workload identity assertions, avoiding the need to maintain reusable access keys at all. If an attacker compromises a build log containing a temporary token, its useful lifetime may be minutes or hours rather than five years.

Organisations should also establish automated detection around newly exposed credentials. AWS itself performs checks for publicly exposed access keys and may apply a compromised-key quarantine policy that limits certain actions when exposure is detected. Truffle Security found 929 credentials that had previously been flagged through this mechanism but were still capable of authenticating, in some cases more than three years later. AWS's own documentation warns that any temporary restrictions it places on exposed credentials do not make the account secure and that the affected key should still be deleted immediately.

This is a crucial incident-response lesson. Once AWS or another secret-scanning service alerts that a credential has leaked, the organisation should not simply acknowledge the warning and assume AWS has neutralised the risk. The key should be disabled or revoked immediately, and security teams should investigate what happened between the earliest possible exposure date and revocation.

CloudTrail becomes essential during that investigation. Responders should identify activity associated with the compromised Access Key ID, examine source IP addresses, regions, API calls, resources touched and roles assumed, and compare this activity with the expected application behaviour. If the key had administrative privileges, the investigation should include IAM users, newly created access keys, roles, policies, login profiles and trust-policy modifications because attackers commonly create additional credentials before the original stolen key is revoked.

Responders should also review for unusual compute resources, snapshots, AMIs, Lambda functions, access to Secrets Manager or Systems Manager Parameter Store, S3 data access and changes to logging. An attacker with administrative credentials may attempt to disable CloudTrail, modify GuardDuty or interfere with other defensive services. Log copies should therefore ideally be stored in a separate security account where compromised production credentials cannot alter them.

AWS Organizations can provide another protective layer through Service Control Policies. Organisations can use SCPs to limit certain actions even if an individual IAM identity has broad permissions. For example, highly sensitive actions can be prohibited outside designated administrative roles or accounts. SCPs should not be treated as a replacement for correct IAM permissions, but they can place an additional boundary around what a stolen credential can ultimately do.

Multi-account architecture also reduces blast radius. Production, development, security, logging and shared-services workloads should not all reside inside one enormous AWS account controlled by the same credentials. Separate accounts with carefully designed trust relationships mean that a leaked key in a development environment does not automatically provide access to production data. Cloud environments are cheap to separate logically, so putting every asset behind one administrative credential is an unnecessarily generous design choice.

Network controls remain relevant even in credential-based cloud attacks. Private workloads and management APIs can be restricted through VPC endpoints, security groups and network policies. S3 buckets and databases should not automatically become Internet accessible simply because an attacker possesses AWS API credentials. Strong identity controls and network segmentation complement each other.

Data protection controls can further limit impact. Sensitive S3 buckets should use restrictive bucket policies, logging and appropriate encryption. Critical resources can require specific roles or conditions rather than trusting broad user credentials. Deletion protection, versioning and immutable backups can reduce the damage an attacker can cause even after gaining privileged API access.

Customers should also monitor API behaviour rather than relying solely on authentication events. The attacker is using valid credentials, so AWS authentication may look completely legitimate. Security analytics should therefore identify unusual API sequences, new regions, unfamiliar source networks, unexpected role assumptions, bulk S3 enumeration, sudden IAM changes and resource creation inconsistent with the identity's normal behaviour.

The ProCheckUp case published shortly before this research demonstrates why retrospective investigation matters. In that assessment, a root AWS access key exposed in a source-code repository remained valid for years, and investigators subsequently found unfamiliar privileged IAM accounts created after the apparent exposure along with later reconnaissance involving account, billing and identity services. The timing alone could not prove attribution, but it showed how one forgotten credential can create a potentially long-lived cloud compromise.

The broader lesson is that cloud security increasingly depends on protecting non-human identities. Organisations have invested heavily in MFA, passwordless authentication and user awareness, yet applications, CI/CD systems and automation frequently continue using static secrets that can authenticate indefinitely without any human verification. Attackers understand this imbalance perfectly well. Stealing one administrator-grade API key may be considerably easier than defeating an employee protected by modern MFA.

For customers, the practical response should therefore be layered: remove root access keys, inventory every IAM access key, revoke unused credentials, rotate anything ever exposed publicly, replace static credentials with roles and short-lived STS tokens, enforce least privilege, scan repositories and build artefacts continuously, protect CI/CD pipelines, enable CloudTrail and GuardDuty, configure billing alerts and investigate any exposed key as a potential compromise rather than merely a configuration mistake. AWS also recommends checking accounts for unexpected EC2 instances, Spot requests, IAM users and other unauthorised usage whenever an exposed credential is identified.

The most important takeaway from this research is that a leaked AWS key should be treated much like a stolen administrator password, except potentially worse because the credential may operate silently for years and can be abused entirely through APIs. The fact that 88% of re-tested credentials still authenticated, that hundreds provided effective administrative control and that some had existed for more than a decade shows that secret rotation and cloud identity governance remain weak points in many environments.

Cloud platforms provide extraordinarily powerful security controls, but those controls cannot compensate for an administrator credential published on the Internet and left active for five years. The larger lesson is therefore not that AWS itself is insecure. It is that cloud identity has to be treated as code, continuously inventoried, minimised, monitored and rotated. In an API-driven cloud environment, possession of a credential can be equivalent to possession of the infrastructure itself.

More than 9,300 Amazon Web Services (AWS) access keys publicly exposed between August 2022 and August 2026 are still active and valid. [...]

Source: Hundreds of leaked AWS keys give full control over corporate accounts via Bleeping Computer — published 21 Aug 2026.