768 Leaked AWS Keys Still Have Full Admin Access — Here's What Every SOC Team Needs to Know
Picture this: a developer at a mid-sized SaaS company pushes a "quick fix" commit at 11:47 PM on a Friday. Buried in a config file is a hardcoded AWS access key — root credentials, no less. He catches it Monday morning, deletes the file, force-pushes a clean commit, and moves on. Case closed, right?
Wrong. That key is still live. It has been sitting in a public GitHub mirror, a Docker image layer, and — unknown to him — a Hugging Face dataset used to fine-tune a code-completion model. Five years later, it still authenticates. It still has AdministratorAccess. Nobody ever rotated it.
This isn't a hypothetical. It's the exact pattern uncovered in a large-scale investigation by Truffle Security, published August 24, 2026, which found 768 publicly exposed AWS credentials that still grant full administrative control over corporate cloud environments. If you run a SOC, manage cloud infrastructure, or touch IAM policy in any capacity, this report should change how you think about "old" leaked secrets.
Table of Contents
- What Actually Happened
- The Numbers That Matter
- Why These Keys Are Still Active After Years
- The Hugging Face Problem
- Key Indicators & What to Check For
- Detection Commands & Tools
- Detection & Prevention Strategy
- Expert Tips From the Field
- Related Reading
- FAQ
- Conclusion
What Actually Happened
Truffle Security — the company behind the open-source secret-scanning tool TruffleHog — spent four years quietly collecting exposed AWS credentials from public sources: Git history, Hugging Face datasets, Docker images, package registries, and CI/CD pipeline logs. Between August 2022 and August 2026, they accumulated 431,875 raw findings, which deduplicated down to 64,024 unique AWS access key pairs tied to roughly 50,654 AWS accounts.
On August 10, 2026, researchers took the subset of keys with complete, testable credentials — 10,616 pairs — and re-verified each one using read-only AWS API calls. No destructive actions, no data access, just enough to confirm whether the key still authenticated and what it could reach.
The result should worry every CISO reading this: 88% of those keys still worked. Of the ones tied to identifiable corporate domains, 768 had privileges high enough to fully take over the account — 526 were root access keys, and 242 belonged to IAM users carrying the AdministratorAccess managed policy.
The Numbers That Matter
Here's the breakdown that should drive your next risk assessment conversation:
| Metric | Finding |
| Total raw AWS secret findings | 431,875 |
| Unique deduplicated key pairs | 64,024 |
| Keys re-verified for activity | 10,616 |
| Still authenticating (88%) | ~9,308 |
| Corporate-linked full-admin keys | 768 (526 root + 242 AdministratorAccess) |
| Median age of a live leaked key | ~1,831 days (≈5 years) |
| Oldest active leaked key | 17.4 years |
| Keys ever rotated after leaking | Only 13.7% |
| Accounts with a budget alert configured | 9.5% |
| Largest single leak source | Hugging Face (8,482 unique keys) |
Read that rotation number again. 86% of leaked keys were never replaced, revoked, or removed after becoming public. That's not a technology failure — that's a process and visibility failure.
Why These Keys Are Still Active After Years
In a typical incident response scenario, you'd assume a leaked secret gets caught fast — a scanner flags it, someone rotates it, done. The data says otherwise, and the reason comes down to three operational blind spots I see repeatedly in real environments:
- Deleted ≠ destroyed. Removing a secret from the current branch does nothing to history. Anyone can
git clonea repo, check out an old commit, and pull the credential straight out of history. - Secrets propagate. Truffle Security found that 43% of leaked keys had surfaced in more than one location — copied from a repo into a Docker image, then re-published in a dataset, then mirrored again. Killing the original source doesn't kill the copies.
- Nobody's watching the account, only the code. Most orgs run secret scanners against source repositories. Very few are watching what their own leaked keys can actually reach in production — which is the exact gap TruffleHog AWS Analyze (launched alongside this research) was built to close.
The Hugging Face Problem
If you're only thinking about GitHub when you think about secret leaks, this report should reset that assumption. Hugging Face was the single largest source of exposed AWS credentials in the entire dataset — 8,482 unique active keys spread across 3,394 public datasets, with 17.9% of them being root keys, the highest root-key concentration of any source tracked.
The mechanism is simple and easy to overlook: developers package source code snapshots, notebooks, or training data into a dataset for machine learning purposes, and any credentials baked into that code go along for the ride. Once it's on Hugging Face, it can be downloaded, forked, and redistributed by anyone building or fine-tuning a model — permanently detaching the secret from its original owner's control.
Key Indicators & What to Check For
If you're triaging this internally, here's what actually matters when you find a potentially leaked AWS key:
- Key type — Is it a root access key (unrestrictable by IAM policy) or an IAM user key? Root keys are the higher-severity find, full stop.
- Attached policy — Does the IAM user carry
AdministratorAccess,IAMFullAccess, or another overly broad managed policy? - AWSCompromisedKeyQuarantine policy — If AWS has already auto-attached this policy to a key in your account, it means AWS's own detection systems flagged the credential as publicly exposed. Treat this as a live incident, not a formality.
- Key age and rotation history — Use
ListAccessKeysto check creation date and whether a second, newer key exists for the same user. - Organization management account exposure — The report flagged 130 live root keys tied to AWS Organizations management accounts. A compromised management-account root key can cascade across every member account in the org.
Detection Commands & Tools
These are the baseline commands I'd run first when auditing exposure. Run them in a controlled environment with proper authorization — never against infrastructure you don't own or manage.
1. List all access keys for an IAM user, including creation date:
aws iam list-access-keys --user-name <username>What it does: Returns every access key associated with that IAM user, along with status (Active/Inactive) and creation date. Use this to spot stale, unrotated keys.
2. Check what identity a given key resolves to:
aws sts get-caller-identityWhat it does: Confirms the account ID, user ARN, and user ID tied to the credentials in use. This is the first thing to run when validating whether a discovered key is still live — it's a read-only call that won't trigger destructive changes.
3. List policies attached to an IAM user:
aws iam list-attached-user-policies --user-name <username>What it does: Shows managed policies attached directly to the user — this is how you confirm whether a leaked key carries AdministratorAccess.
4. Scan your own repos and history for secrets with TruffleHog:
trufflehog git file://path/to/repo --only-verifiedWhat it does: Scans full Git history (not just the current branch) for verified, still-active secrets. The --only-verified flag filters out dead or invalid findings so your team isn't chasing false positives.
⚠️ Warning: Never run credential-testing or enumeration scans against AWS accounts you don't own or have explicit written authorization to test. Unauthorized access attempts, even read-only ones, can constitute a violation of the Computer Fraud and Abuse Act (CFAA) and similar laws outside the US.
Detection & Prevention Techniques
Based on the report's findings and standard cloud hardening practice, here's a practical remediation checklist for security teams:
- Kill root access keys entirely. There is almost never a legitimate reason for a root user to have an active access key. Delete them and use IAM roles or the root user's console login (protected by MFA) for the rare cases root access is genuinely required.
- Enforce a maximum key age policy. Set a hard limit — 90 days is a common enterprise baseline — and automate expiration alerts before that threshold hits.
- Move to short-lived credentials. Replace long-lived IAM access keys with IAM roles and temporary STS tokens wherever workloads allow it, especially in CI/CD pipelines and production compute.
- Scan beyond the current branch. Your secret-scanning coverage needs to include full Git history, container image layers, CI/CD log output, and any datasets or artifacts your teams publish externally — including to platforms like Hugging Face.
- Set AWS Budget alerts on every account. With 90.5% of accounts in this study lacking any budget alert, a compromised key can rack up cryptomining charges for weeks before anyone notices. Even a low-threshold $10 alert is better than silence.
- Investigate any account under AWSCompromisedKeyQuarantine. If AWS has already flagged a key, don't just accept the quarantine — rotate the credential and audit what actions were taken while it was exposed.
- Treat every public commit as a permanent compromise. Once a secret is published, assume it exists in dataset mirrors, cached forks, and archived containers you'll never be able to fully purge. Rotation, not deletion, is the only real fix.
Expert Tips From the Field
- Don't rely solely on pre-commit hooks to catch secrets — they only protect commits made after the hook is installed. Historical exposure requires a full-history scan, run at least quarterly.
- If your organization publishes any code, notebooks, or datasets externally (including to AI platforms), build a pre-publication secret scan into that workflow specifically. It's a different exposure surface than your internal repos.
- When you inherit legacy AWS accounts through M&A or team transitions, run a credential audit before anything else. Forgotten keys from acquired companies are a common blind spot.
- Pair IAM key audits with CloudTrail log review for the same period — if a key was exposed, check whether any anomalous API activity occurred during the exposure window, not just after discovery.
Related Cybersecurity Topics You Should Explore
- Enable Maximum Windows Logging for SOC & Ransomware Detection
- OpenBin.ai & OpenAPK.ai Review: Free AI Reverse Engineering Tool
- Grok Zero-Click Hack Steals Your Chats — No Click Needed
- head Command in Linux: Fast Log Triage for SOC Analysts
- Elementor Pro Bug Lets Hackers Upload PHP — No Login Needed
- tac Command Tutorial: Reverse Logs Fast for Faster Threat Detection
- ToxicPanda 2.0: The Android Trojan Now Hacking 349 Banks
- Windows 11 24H2 Support Ends Oct 13 — Are You at Risk?
- Cat Command in Linux: The SOC Analyst's Secret Weapon
- How a Fake VNC Login Turned Into Full Root Access on macOS
- reconFTW Tutorial: The Recon Tool That Found My Hidden Bounty
- TP-Link Router Flaw Lets Hackers Skip Login Entirely — Here's What's at Risk
- This subfinder Fork Cuts Recon Time in Half — subfaster Review
- 737 Fake VPN Extensions Are Spying on Chrome Users Right Now
- GhostDesk Spyware Alert: Fake CCleaner Steals Passwords & Crypto
- Zoomsday Flaw: Hackers Hijack Zoom Users With Zero Clicks
Frequently Asked Questions
Q1: What is an AWS root access key, and why is it more dangerous than a regular IAM key?
A root access key is tied to the AWS account's root user, which has unrestricted access that cannot be limited by IAM policy. It can change billing settings, close the account, or delete every resource in it. IAM keys, even with AdministratorAccess, can theoretically still be constrained by service control policies (SCPs) in an AWS Organization — root keys generally cannot.
Q2: How can a deleted GitHub commit still expose a secret years later?
Deleting a file or force-pushing over a commit doesn't erase it from Git's object history unless you rewrite history and purge every clone, fork, and mirror. Cached copies, archived forks, and third-party scrapers can retain the original commit indefinitely.
Q3: What is AWSCompromisedKeyQuarantine, and what should I do if I see it?
It's a managed policy AWS automatically attaches to IAM users when its own systems detect that a credential has been publicly exposed. It restricts high-risk actions but doesn't fully disable the key. Treat it as an active incident: rotate the key immediately and audit account activity.
Q4: Why was Hugging Face such a major source of leaked keys?
Developers often package source code, notebooks, or training scripts into public datasets without stripping embedded credentials first. Once published, that data is downloaded and mirrored widely, making the original leak nearly impossible to fully contain.
Q5: How often should companies rotate AWS access keys?
Most enterprise security frameworks recommend a maximum key age of 90 days for any long-lived access key, with automated alerts before expiration. Better still, eliminate long-lived keys entirely in favor of IAM roles and short-lived STS tokens.
Q6: Does deleting a leaked key from a repository make it safe again?
No. The credential itself must be rotated or revoked in AWS. Removing it from a repository only hides the current view — the key remains valid until it is explicitly deactivated or deleted in IAM.
Q7: What's the fastest way to check if my organization has exposed AWS keys right now?
Run a full-history secret scan (tools like TruffleHog support this) across all repositories, container registries, and CI/CD logs, then cross-reference any findings against your active IAM key inventory using aws iam list-access-keys.
Conclusion
The uncomfortable truth in this report isn't that secrets leak — that's a given in any organization writing code at scale. It's that once they leak, almost nobody goes back and finishes the job. A median leaked key sitting active for five years isn't a detection failure at the moment of exposure; it's a failure of process, ownership, and follow-through afterward.
If there's one action item to take from this today, it's this: pull your IAM key inventory, check the creation dates, and ask a hard question about every key older than 90 days — does anyone actually know why it still exists?
Found this useful? Share it with your security team, drop your own credential-rotation war stories in the comments, and subscribe for more real-world breakdowns of the cloud security incidents that actually matter.