Thousands of Leaked AWS Keys Are Still Working
Security researchers have uncovered a deeply troubling finding: more than 9,300 Amazon Web Services (AWS) access keys that were publicly exposed between August 2022 and August 2026 are still active and valid. The keys — leaked across public code repositories, pastebins, container images, and misconfigured storage — provide full control over the corporate AWS accounts they belong to.
The scale of the exposure and the failure to rotate compromised credentials represents one of the most significant ongoing cloud credential risks documented to date.
What Was Found
| Metric | Detail |
|---|---|
| Keys Exposed | 9,300+ |
| Exposure Window | August 2022 – August 2026 |
| Status | Still active and valid |
| Account Type | Corporate AWS accounts |
| Access Level | Full account control in many cases |
Researchers found the credentials exposed across a range of public-facing surfaces including:
- GitHub and GitLab repositories — hardcoded keys committed to public repos
- Public S3 buckets — configuration files containing API credentials left world-readable
- Docker Hub images — credentials baked into container layers
- Pastebin and code-sharing sites — snippets uploaded during debugging sessions
- CI/CD logs — pipeline output inadvertently printed secrets to public build logs
Why This Matters
AWS access keys consist of an Access Key ID and a Secret Access Key. Together, they authenticate as a specific IAM user or role. Keys with broad permissions can be used to:
- Enumerate and exfiltrate data from S3 buckets, RDS databases, and DynamoDB tables
- Spin up compute resources for cryptomining or botnet activity (generating large bills for victims)
- Exfiltrate secrets from AWS Secrets Manager and Parameter Store
- Modify IAM policies to create backdoor accounts
- Delete or encrypt resources for ransomware-style attacks
- Pivot to other cloud providers via stored cross-cloud credentials
The fact that these keys remain active four years after initial exposure suggests that many organizations either:
- Do not have automated secret scanning and rotation pipelines
- Are unaware the keys were ever exposed
- Lack sufficient AWS CloudTrail monitoring to detect active abuse
The Credential Lifecycle Problem
When a developer commits an AWS key to a public GitHub repo, best practice calls for immediate key rotation — even if the commit is deleted within seconds. Modern internet scanners and bots continuously monitor GitHub events and will capture leaked credentials within minutes of publication.
Yet the research findings indicate that the majority of the 9,300+ leaked keys were never rotated. This creates a persistent attack surface that grows over time as the credentials age without rotation.
Common Sources of Credential Leaks
# Developer accidentally commits .env file
git add .env && git commit -m "add config"
# Hardcoded in application code
aws_access_key_id = "AKIA..."
aws_secret_access_key = "abc123..."
# Left in CI/CD environment variable logs
echo "Deploying with key: $AWS_ACCESS_KEY_ID"Immediate Actions for Organizations
1. Audit Existing Keys
# List all IAM users and their access keys
aws iam list-users --query 'Users[*].UserName' --output text | \
xargs -I{} aws iam list-access-keys --user-name {}
# Check for keys older than 90 days
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d2. Enable AWS Secrets Scanner
AWS now offers Amazon CodeGuru Secrets Detector and integrates with GitHub Advanced Security for secret scanning. Enable these guardrails across all repositories.
3. Implement Key Rotation Policies
- Set IAM password and key rotation policies via AWS Config rules
- Enable AWS IAM Access Analyzer to continuously monitor for public exposure
- Use AWS Secrets Manager with automatic rotation instead of static keys where possible
4. Adopt IAM Roles Over Long-Lived Keys
For EC2, Lambda, ECS, and other AWS-native workloads, use IAM roles rather than static access keys. Roles issue short-lived credentials automatically and eliminate the rotation problem entirely.
5. Monitor CloudTrail for Abuse
Enable CloudTrail in all regions and set up AWS GuardDuty to detect anomalous API activity including:
- API calls from unfamiliar IP addresses or geographies
- Unusual IAM operations (creating users, attaching policies)
- High-volume S3 GetObject requests (data exfiltration)
- EC2 or Lambda provisioning outside normal patterns
Prevention: Shift Left on Secrets
| Tool | Purpose |
|---|---|
| git-secrets | Pre-commit hook to block credential commits |
| truffleHog | Scan git history for leaked secrets |
| detect-secrets | Baseline and drift detection |
| AWS Secrets Manager | Centralized secret storage with auto-rotation |
| SOPS | Encrypted secrets in version control |