Cloud Exposure Index 2026: 484,142 open buckets mapped

The Ransomnews research team counted 484,142 publicly listable cloud storage buckets holding 18.05 billion files in October 2026, using the search engines that index open cloud storage. Amazon S3 hosts 72% of them, but Azure Blob is 2.5 to 3.6 times over-represented among buckets named for backups, exports and payroll. Open buckets also list 321,058 credential and key files, and 67% of the exposed .env files were last written this year.

No file was opened for this index. Every number below comes from bucket names, file extensions, file counts and last-modified timestamps. That is a deliberate limit. It keeps the research on the right side of the line, and it turns out to be enough to see where the sensitive material concentrates. We are calling it the Ransomnews Cloud Exposure Index, and we will rerun it quarterly so the numbers can be compared over time.

How many cloud buckets are publicly exposed in 2026?

484,142 buckets across five providers were publicly listable when we took the snapshot, with 18,054,411,545 indexed files between them. Amazon S3 accounts for 71.9% of the buckets, which is roughly its share of the market and not evidence that S3 is worse configured than the rest.

Provider	Open buckets	Share
Amazon S3	347,984	71.9%
Azure Blob	68,532	14.2%
Google Cloud Storage	53,131	11.0%
DigitalOcean Spaces	11,069	2.3%
Alibaba OSS	3,426	0.7%
Total	484,142	100%

A large share of these buckets are public on purpose: website assets, CDN mirrors, open datasets, podcast archives. The index is not 484,142 breaches. It is the population inside which the breaches sit, and the rest of this piece is about narrowing it down to the stores that should never have been listable.

Which cloud provider leaks the most backups?

Azure, by a wide margin relative to its size. Azure Blob holds 14.2% of open buckets, but 37% of the 1,459 buckets with “backup” in the name, 42% of the 399 named for exports, and 51% of the 505 carrying HR or payroll terms. Buckets named for logs, customers and databases sit at 35% to 36%, all around two and a half times Azure’s baseline.

The skew is specific to operational data. Buckets named “dev” sit at Azure’s baseline (15%), and “test” and “staging” sit below it. Our reading is that Azure storage accounts are more often used for line-of-business data, the backups, exports and HR systems that enterprises run on Microsoft, while S3 and Google Cloud carry more application assets. That is a hypothesis the counts suggest, not one they prove, and it is the first thing we want to test in the next run.

Which sectors have the most exposed buckets?

Retail and e-commerce names lead with 5,666 buckets, most of them storefront assets. The more important figure is that names tied to regulated sectors (finance, healthcare, education, government, legal and HR) appear on 10,891 unique open buckets. Those are the sectors where an exposed file is most likely to hold personal, health or financial records, and where regulators expect to be told.

Sector (by bucket name)	Open buckets	Files in them
Retail & e-commerce	5,666	269.9M
Finance & insurance	3,508	58.0M
Healthcare	2,709	47.9M
Media & entertainment	2,696	136.2M
Education	2,393	60.6M
Gaming	2,296	79.0M
Travel & hospitality	1,714	118.7M
Real estate	1,137	60.7M
Government & public sector	1,000	36.2M
Legal	978	11.3M
Crypto	630	11.9M
HR & payroll	505	8.4M

Healthcare names alone cover 2,709 buckets holding 47.9 million files, matched on terms including “hospital” (135 buckets), “patient” (135), “clinic” (277) and “dental” (331). HR and payroll is the smallest sector in the table and the most concentrated on Azure: 259 of its 505 buckets. Treat all of these as name signals rather than verified ownership. The matching is substring-based, so “store” catches object stores as well as shops, and a bucket can count in two sectors.

What sensitive files are sitting in open buckets?

Open buckets list about 4.7 million database and dump files, 321,058 credential and key files and 15,130 mailbox archives, alongside tens of millions of spreadsheets and documents. The credential files are the ones that turn a misconfiguration into an intrusion, so they get the chart.

Each of these file types exists to grant access. A .env file is where developers keep database passwords and API keys. A .ppk file is a PuTTY private key for SSH. A .tfstate file is Terraform’s record of an entire cloud estate, often including secrets in plain text. A .kdbx file is a KeePass vault, encrypted, but now available to anyone who wants to try passwords against it offline. Some of the 113,285 .pem files will be public certificates rather than private keys, and some of everything will be test fixtures. The counts are a ceiling on live secrets, not a measure of them. They are still a large ceiling.

Database files are the bulk of the sensitive material by volume, and the bigger exports are where personal records live.

File type	What it usually holds	Files listed
.sqlite	Embedded app databases	2,561,807
.bak	Database and server backups	752,055
.sql	Database dumps	687,446
.sqlite3	Embedded app databases	488,176
.dump	Database dumps	176,603
.mdb / .accdb	Microsoft Access databases	36,467
.dmp	Memory and crash dumps	12,809
.pst / .ost / .mbox	Mailbox archives	15,130
.eml	Individual saved emails	4,549,665
.csv	Data exports and records	at least 69,580,112
.xlsx / .xls	Spreadsheets	42,544,997
.docx	Word documents	24,936,788
.pdf	Documents, invoices, scans	at least 106,191,393
.log	Application and server logs	at least 61,310,809

Disk images are rarer and worse: 2,959 VMware disks (.vmdk), 4,427 Hyper-V disks (.vhd and .vhdx), 4,036 QEMU images (.qcow2) and 10,161 virtual appliances (.ova). A single disk image can contain a whole server, credentials included.

Are these exposures old or still live?

Both, and the split is informative. 54,317 of the 80,495 listed .env files (67%) were last written in 2026, which points to buckets in active use rather than forgotten archives. Only .env skews that clearly recent. Certificates (.pem) are mixed, with 28% written in 2026 and 58% before 2025. SQLite databases are 19% and 66%.

Backups are the forgotten category: 89% of the 752,055 listed .bak files were last written before 2025. PuTTY keys are a single-year spike: 97% of the 24,302 listed .ppk files were written in 2024 and almost none since, which looks like a few large uploads that nobody has revisited. Both patterns are stories. Live leaks are the urgent one. Buckets left open for years are the governance one.

The flow has not stopped. Measured against the newest file in the index (9 September 2026), at least 113.6 million files were written to publicly listable buckets in the preceding seven days. In the 30 days to that date, 21,125 SQL dumps, 20,958 .bak backups, 4,477 .pem files and 1,298 .env files landed in buckets anyone can list.

This is why we care about it on a ransomware site. A working database password in a public .env file is exactly the product that initial access brokers sell to affiliates, and the same class of material that turns up in stealer logs. The difference is that nobody had to infect a machine to get it. Someone just had to search.

What should organisations do?

Nothing here is new, which is the uncomfortable part. Every provider has had an account-level switch for this for years.

• Turn on the account-level block. S3 Block Public Access at the account level, disallow anonymous blob access on every Azure storage account, and public access prevention on Google Cloud. Set it at the organisation or account level so a new bucket cannot opt out.
• Search your own storage for the file types in this article. .env, .sql, .bak, .pem, .ppk, .tfstate and .kdbx have no business in a bucket that serves a website. The same search engines we used will show you what the internet already sees of your estate.
• Rotate any secret that has ever sat in a public bucket. Closing the bucket does not un-leak the key. Assume anything that was listable was copied.
• Treat Terraform state and disk images as secrets infrastructure. They deserve the controls you give a password manager: private storage, encryption at rest with your own keys, and access logging.
• Keep backups off public storage and test the restore. A backup that an attacker can read is a data breach; a backup that an attacker can reach is a ransomware target. Our guide to ransomware protection for business covers the backup and EDR side.
• Fix the posture, not the bucket. One open bucket is a mistake. Dozens is a process gap, and the misconfigurations that cause most cloud breaches are the same handful every year.

How we built the index

We queried commercial search engines that index publicly listable cloud storage on 25 October 2026. The bucket list was current to 7 October 2026 and the newest indexed file was dated 9 September 2026, so the file-level figures lag the bucket list by about a month. Every figure is an aggregate count returned by the index: bucket names, file extensions, per-bucket file counts and last-modified timestamps. No file was downloaded or opened, and no bucket is named in this article.

• Providers. Bucket counts per provider are the index’s own totals.
• Sectors and purpose. A bucket counts for a sector when its name contains one of 61 fixed terms. Matching is substring-based, so the sector figures are name signals, not verified ownership. We dropped generic folder words such as “media” and “video” because they name asset folders, not companies.
• File types. Counts are listed files whose extension matches. The index caps any single count at one million, so we split the larger types into date windows and summed them. Where our query budget ran out before every window resolved, the figure is a lower bound and marked “at least”.
• Recency. A last-modified timestamp says when a file was written, not when it was exposed or found. It is a proxy for whether the bucket is still in use.
• Limits. A file listed in an open bucket is not proof that its contents are readable, and test fixtures and sample files are in the counts. Extension counts are a ceiling on sensitive material. Quote the sector figures as “buckets with sector-linked names”.

The exposures with a known owner in regulated sectors are going through responsible disclosure separately, with the relevant national CERTs copied where the owner is public sector or does not respond. If you find your organisation in this dataset, the search engines we used will show you before anyone else needs to. For the same picture of a different category, see our count of exposed AI endpoints, where the open-by-default rate was 98%.

Frequently asked questions

Sources and further reading

• AWS documentation: Blocking public access to your Amazon S3 storage
• Microsoft Learn: Remediate anonymous read access to blob data
• Google Cloud documentation: Public access prevention for Cloud Storage
• Related reading on Ransomnews: 36,769 exposed AI endpoints, only 2% ask for a login, the top cloud misconfigurations that cause breaches, and initial access brokers in the 2026 ransomware supply chain.