There’s a comfortable myth most people carry around: that the data they hand to companies is locked somewhere safe. Researchers at Mysterium VPN just ran the numbers, and the numbers disagree. Across 535,480 publicly listable cloud storage buckets on Amazon S3, Google Cloud, Azure, DigitalOcean, and Alibaba, they counted 19.6 billion files accessible to anyone with a browser and a URL. No login. No exploit. Just a web request.
The research team analyzed bucket metadata captured in March 2026, categorizing files by type and filename. They didn’t access or download any content. They didn’t need to. The presence of these file types in open storage is the finding, and it’s bad enough on its own.
Most of those 19.6 billion files are mundane: images, documents, logs, the ordinary debris of running software at scale. The question worth asking is how much of the exposure is the kind of material that should never be reachable by a stranger.
“19.6 billion files are currently exposed across 535,480 publicly listable cloud buckets on Amazon S3, Google Cloud, Azure, DigitalOcean, and Alibaba, with no login and no break-in required.” reads a report published by MysteriumVPN.
“685,047 credential and key files (.env files, private keys, password vault databases) are sitting in open buckets, giving would-be attackers direct access to live systems rather than merely exposing data from those systems.”
An .env file is where an application keeps its passwords, API keys, and authentication tokens. A .kdbx file is literally a password manager’s vault. These aren’t interesting artifacts. They’re master keys.
Database exports add another layer. The research found 985,645 .sql files and 733,040 .bak files sitting in publicly accessible buckets. A live database is protected by the application wrapped around it, with authentication, rate limiting, and query controls in place.
“A live database is guarded by the application wrapped around it.” continues the report. “Meanwhile, a database dump sitting in an open bucket just like this is the same data with all the guards removed, downloadable in one click, and analyzable forever.”
Customer names, addresses, order histories, support tickets, and plain-text passwords are all fair game for anyone who finds one.
The filename counts alone signal the scope of the problem. Researchers found 764,015 files containing the word “secret,” 250,563 containing “salary,” 195,475 containing “kyc,” and 124,967 containing “credentials.” Files named “password,” “passport,” “invoice,” and “backup” each exceeded one million, the ceiling at which the query stops counting. People don’t label files “kyc” or “confidential” by accident.
The real danger isn’t any single file. It’s how they connect. An attacker scanning open buckets finds an .env file. Inside are database credentials. Those credentials open a .sql export in the same bucket, which contains customer email addresses and password hashes. The hashes get cracked offline at leisure. Many people reuse passwords, so a fraction of those accounts unlock email inboxes. Those inboxes contain invoice-approval workflows, executive contacts, and password-reset links to everything else. One open bucket becomes a complete attack kit, pre-assembled, requiring no technical skill beyond knowing where to look.
More than two-thirds of the exposed storage sits on AWS. That’s not because S3 is less secure than the alternatives. It’s because it’s the default choice for most of the world, and defaults are where mistakes scale.
“More than two-thirds of exposed storage sits on AWS. Not because S3 is less secure than the alternatives, but because it is the default choice for most of the world, and defaults are where mistakes scale.” continues the report. “The lesson here is not “avoid Amazon.” It’s that exposure follows wherever the crowd goes. When one platform hosts the majority of the world’s cloud workloads, it also hosts the majority of the world’s misconfigured ones.”
There’s no exploit in this story. No zero-day, no malware, no intrusion. Every one of those 19.6 billion files is exposed because of a setting. A bucket flipped to “list” instead of “private.” A backup script pointed at the wrong path. A developer who put an .env file somewhere it didn’t belong. The structural problem is that centralization turns a single wrong toggle into a complete data spill. A credential file only unlocks the kingdom when the kingdom is centralized behind it.
For anyone running cloud storage, the fix is straightforward even if the execution requires discipline: default everything to private, never store secrets in object storage, encrypt every backup, and scan your own footprint the way an attacker would. If you can list a bucket without logging in, so can everyone else. For everyone else, the data sitting in those buckets was handed to companies you’ve dealt with, and you can’t change their settings. What you can do is use unique passwords everywhere, turn on multi-factor authentication on anything that touches money or email, and share less with fewer services. Data that was never collected can’t leak. That’s not a security philosophy. It’s arithmetic.
“The open buckets in this report will keep accumulating faster than they are cleaned up. The filename counts alone prove it.” concludes the report. “The organizations responsible for these buckets should be treating misconfiguration as a structural failure, not an occasional mistake to patch. And if they will not, their users should be shrinking the footprint those organizations can expose on their behalf.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Amazon S3)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。