Companies Leaked Their AWS Keys Years Ago. Most Still Work.

The unsettling thing about Truffle Security’s latest research is that it describes no clever hack at all. It is a story about neglect. The security firm spent four years collecting Amazon Web Services credentials that companies had accidentally left in public, then went back and tried them. As of August 10, of the roughly 10,600 keys it could fully re-verify, 88% still worked.

Buried in that pile are the ones that matter most. Of the keys tied to real companies, 768 grant full control of an AWS account, 526 of them root keys and another 242 belonging to admin-level users. A root key is the master key to the whole account, unrestricted by the usual permission guardrails, and there is no good reason for one to exist in 2026. Anyone holding a live one can read or delete data, seize servers, spin up rogue accounts, and lock the real owner out. Worst of all, 130 of the live root keys belong to organization-management accounts, the master account that controls every other account in a company’s AWS setup. Compromise one of those and the entire organisation falls at once.

Old keys nobody ever changed

How did keys stay usable for so long? Because almost nobody rotated them. Among keys with a known creation date, the median was about five years old, the oldest had been live for more than 17 years, and only 13.7% had ever been replaced. These are the digital equivalent of a spare key left under the mat and forgotten, except this mat is the public internet. The bill for that carelessness can run high in more ways than one: attackers love using stolen cloud keys to run cryptominers, and only about one in ten of the exposed accounts had even a basic budget alert switched on to catch a sudden spike.

The AI-data twist

The single largest source of leaked keys was not a code host in the traditional sense. It was Hugging Face, the hub where developers share AI models and datasets, which accounted for more than 8,000 unique exposures. That is what happens when AI development inherits software development’s bad habits. And it points to the nastiest part of the whole problem: once a key is committed somewhere public, deleting it later barely helps. A credential dropped into a repository can be scraped into an AI training corpus, copied into container images, and forked into projects the original owner has never heard of. Truffle found many keys sighted repeatedly across the internet. You cannot un-leak a secret.

Amazon, for its part, does respond. It says it notifies affected customers and applies a quarantine policy to keys it detects as exposed, limiting the damage without breaking a customer’s systems. That is real help, though security researchers note the quarantine still permits plenty an attacker could work with, and it only kicks in for keys AWS manages to spot. Under the cloud’s shared-responsibility model, the locks are ultimately the customer’s job.

Worth remembering that Truffle sells the scanning tool this research showcases, so the framing is not disinterested. But the underlying finding is hard to argue with and easy to act on. Delete every root access key, sort your credentials by age and rotate the ancient ones, set a cheap budget alarm, and treat anything ever committed to a public place as already burned. So how many of these forgotten keys are quietly waiting in your own accounts? For a lot of companies, the honest answer is that no one has checked.