As reported by BleepingComputer, Truffle Security's multi-year audit of public repositories, Docker images, and CI logs uncovered more than 9,300 AWS access keys exposed since August 2022 — with 88% of a testable subset still valid as of August 10, 2026. 768 of those keys grant full administrative control over corporate AWS accounts. This is not a novel discovery; it is a chronic governance failure.
The headline numbers are striking, but the underlying pattern is what defenders should focus on. The median exposed key was 1,831 days old — roughly five years. Only 13.7% had a newer replacement key, meaning the vast majority were never rotated even after public exposure. 526 were root keys, which AWS has explicitly advised against creating for years. This tells us the problem is not that secrets leak — it is that organizations lack the discipline to invalidate them once they do.
Why This Matters Beyond the Breach
Secret scanning tools have proliferated. GitHub, GitLab, and most CI platforms now include native detection. Yet Truffle Security found 431,875 AWS secrets across public surfaces. The gap is between finding a leaked credential and neutralizing it. Most teams treat secret scanning as a pull-request gate — a preventive control — but have no automated pipeline for revoking keys found in historical commits, Docker layers, or third-party platforms like Hugging Face, which accounted for 8,482 exposures in this dataset alone.
The risk profile here is severe. An attacker with an AdministratorAccess key can exfiltrate data, destroy infrastructure, create backdoor IAM users, and run cryptominers that generate five- to six-figure billing surprises. Only 262 of 2,754 readable accounts had budget alerts configured — meaning most victims would not even notice anomalous spend until invoice time.
The threat is not just data theft. It is silent persistence. A rogue IAM user created today can maintain access long after the original leaked key is rotated.
Who Is Most at Risk
- AI/ML teams using Hugging Face, public datasets, or shared notebooks — the largest single exposure vector in this study
- Organizations with legacy AWS accounts predating IAM best practices, where root keys were created and forgotten
- Startups and SMBs without dedicated cloud security staff, where individual developers commit credentials directly
- Any team using Docker images or CI logs from public registries where secrets persist in layers even after removal from source
Shield53 Recommendations
Defenders should treat this as an operational mandate, not a news item:
- Eliminate all root access keys immediately. Use IAM users or roles with least-privilege policies. If you cannot delete root keys because of a legacy dependency, that dependency needs to be fixed, not accommodated.
- Implement automated key rotation. AWS IAM supports programmatic rotation via the API. Set a maximum age policy — 90 days or less — and enforce it with AWS Config rules or SCPs.
- Deploy secret scanning across your entire attack surface — not just current code. Scan Git history, Docker image layers, CI/CD logs, and any platform where developers share artifacts. Tools like TruffleHog, Gitleaks, or GitHub Advanced Security can cover historical commits.
- Enable AWS Cost Anomaly Detection and budget alerts on every account. Cryptomining abuse produces immediate, abnormal spend patterns that are trivially detectable if alerts exist.
- Audit IAM for dormant identities. After revoking exposed keys, check for IAM users or roles you did not create — especially any with
AdministratorAccessattached. These are persistence markers. - Use temporary credentials via IAM Roles and STS instead of long-lived access keys wherever possible. This eliminates the entire class of risk for workloads running within AWS.
The uncomfortable truth is that secret leakage is inevitable at scale. The maturity differentiator is not whether your credentials appear in a public dataset — it is whether they still work when someone finds them.
