- Truffle Security dug out 768 leaked AWS functioning keys, including 526 root keys.
- Amazon’s safety policy still lets an attacker do a lot of harm with a stolen key.
- Most of the exposed keys are years old, and Europe’s new banking rules make this risk bigger.
A cloud security firm found hundreds of stolen AWS keys that still open company accounts. Truffle Security shared the findings this month, and the numbers are troubling.
How Researchers Found so Many Working Keys
Truffle Security searched far and wide for lost AWS secrets. The team pulled out AWS secrets up to 431,875 from code repositories, git history, Docker images, public datasets, and CI logs. They narrowed that huge pile down to 64,024 unique keys in total.
Not every key had full details attached. Researchers could only test ones with complete credentials, leaving 10,616 keys ready for checking. The results surprised even the researchers. As of August 10, 88% of those tested keys still worked, meaning nine out of ten stolen keys could still log in, years after they first leaked online.
Among the working keys, 768 gave full control of a company account. This group included 526 root keys, the most powerful type of key any AWS user can hold. Root access works like a master key that opens every door in a whole building.
Another 242 keys carried AdministratorAccess rights. This setting unlocks almost every tool inside an account, short of true root power.
One surprising source stood out from the rest. Hugging Face, a popular hub for sharing AI models, accounted for 8,482 unique exposed keys. It seems teams building AI tools repeat the same mistakes coders have long made with secret keys.
Age made the problem worse. The typical exposed key that still worked was about five years old. Only 13.7% of accounts had ever swapped in a fresh key.
What a Stolen Key can Still do
Amazon does try to catch leaked keys once they surface online. When it spots one, it applies a quarantine policy. This step aims to stop a hacker from running up huge bills or wrecking a customer’s setup.
But the quarantine policy still leaves a long list of actions open to a hacker. Corey Quinn, a cloud economist, wrote about this gap in The Register. According to Quinn, a locked key can still switch into other roles inside the very same account.
A blocked key can also send commands to live servers already running. It can even shut off CloudTrail, the tool that records account activity. Turning that off wipes out the trail investigators would need.
One example worries Quinn the most. A quarantined key can still write new files into storage buckets. It can also set something called object lock and retention rules on those very files.
That mix lets a hacker flood storage with junk files and lock them in place. Nobody, not even AWS support, can shorten that lock without deleting the whole account. Quinn built this list straight from Amazon’s own published rules.
Amazon has said its goal is to stop fraud charges without breaking a customer’s existing setup. Quinn’s reading of the published policy shows the balance still tilts toward attackers in several places.
Why Old, Unused Keys Matter More in Europe
Nobody seems to be swapping out these old keys on any regular schedule. A key created five years ago and still active shows nobody is watching it closely.
This habit becomes a bigger deal for firms based in Europe. Banks and other financial firms there must follow a rule called the Digital Operational Resilience Act, or DORA. That rule has applied to them since January 2025.
The combination of old, unrotated keys and DORA pressure is part of a larger pattern of exposed identity infrastructure. In November 2025, Cybernews researchers discovered an unsecured MongoDB database tied to IDMerit, an AI-powered identity verification company, that contained roughly 1 billion personal records across 26 countries, including full names, national ID numbers, dates of birth, physical addresses, and phone numbers.
TNW reported that most financial firms across Europe still are not ready to meet these new rules. The rule asks firms to track and write down risks tied to outside tech providers they depend on daily.
A forgotten root key sitting inside a public dataset fits that exact risk category. The regulation expects firms to find gaps like this and record them clearly. This story is not about one single hack happening right now. It is about accounts sitting wide open for years, waiting for someone to notice.
Companies that use AWS should check the age of their own keys today. Old, unrotated keys pose a quiet but very real danger to any business. A five-year-old key that was never replaced is a risk nobody should keep ignoring.
Share this article
About the Author
Farwa is an experienced InfoSec writer and cybersecurity journalist skilled in writing articles related to cybersecurity, AI, DevOps, Big Data, Cloud security, VPNs, IAM, and Cloud Computing. Also a contributor on Tripwire.com, Infosecurity Magazine, Security Boulevard, DevOps.com, and CPO Magazine.
More from Farwa SajjadRelated Posts
Uber Fined Over $960 Million by Dutch Regulator Over Automated Driver Suspensions
The Dutch Data Protection Authority fined Uber €825 million, close to $966 million, for how it suspe...
ChatGPT Gains Access to Mac Messages, Raising New Apple Privacy Concerns
OpenAI launched a new plug-in that lets ChatGPT read, search, draft and send messages on Mac compute...
South Korea Telecom Data Breaches Drive More Customers to Switch Carriers
A fresh study links South Korea’s telecom data breaches to a jump in customers changing carrie...
StopAndProtect Hijacks 2,000 WordPress Sites to Spread Malware and Ransomware
A new malware operation called StopAndProtect hijacks WordPress sites to build hidden command center...
Firefox Users on iOS Can Now Block Ads without an Extension
Mozilla is slowly rolling out a built-in ad blocker for Firefox on iPhones and iPads, no extension n...
Suspected Chinese Hackers Exploit Critical VMware vCenter Flaw Across 47 Countries
Several servers across 47 countries record a compromise via an exploit of Vmware vCenter directory-t...
