S3 Bucket Public Access Misconfigurations Across Disclosed Incidents

Cloud misconfigurations caused 23% of all cloud security incidents in 2025, and Gartner's own projection holds that almost all cloud security failures through the same period trace back to the customer, not the provider. That split matters, because it means the industry has spent a decade telling people exactly where the fault line sits, and the fault line has not moved. Cloud-conscious intrusion attempts rose 37% year over year in 2025, and that growth rate itself sped up compared to the year before, meaning attackers are not just finding more targets, they're getting faster at it. Meanwhile the average time to catch a cloud breach sat at 241 days in 2025, plenty of runway for a scraper to copy and re-index a bucket's contents dozens of times before anyone notices. None of this is new: a running list of AWS exposure incidents stretches from 2017 through at least 2024, with gaps between clusters that look less like a fading problem and more like a structural one that never actually got fixed, just quieter for a while. Shared responsibility model is the conceptual anchor. AWS secures the infrastructure, bucket configuration, access policy, and lifecycle management are the customer's job, and that boundary is where most failures happen.

How widespread bucket exposure is across research samples

Numbers help size the problem, and they're not encouraging. Datadog's 2024 State of Cloud Security Report found that the share of AWS S3 buckets that were effectively public had barely moved from the prior year, despite growing adoption of Block Public Access features. Qualys found 31% of the buckets in its sample open to the public, and a separate Rapid7 study of a large bucket sample turned up a substantial chunk exposed, collectively holding an enormous pile of files. Laminar Security, since folded into Rubrik, dug through hundreds of millions of files spread across tens of thousands of exposed buckets and found a significant share held sensitive data. CybelAngel's research pushes the number higher still: close to half of all AWS S3 buckets are potentially misconfigured, and more than half of everything analyzed contained sensitive or personally identifiable information. Putting a dollar figure on operational scale makes it look worse. The average enterprise carries more than 3,000 misconfigured cloud assets at any given moment, which is less a security gap and more a standing inventory problem nobody's clearing out.

How attackers find open buckets before owners know they exist

None of this requires a nation-state budget or a zero-day. Tools like S3Scanner, BucketLoot, and Slurp sit on GitHub, free, and check for common misconfiguration patterns across cloud providers without asking the operator to know much of anything about cloud architecture. GrayhatWarfare has already done the indexing work for anyone curious: it catalogs publicly accessible S3 buckets and lets a user search by filename, keyword, or file extension, and its premium tier costs next to nothing set against what a breach actually runs. Other approaches skip search entirely and go straight to mapping. Buckets that block public listing aren't necessarily safe either: filename brute-forcing still works, since attackers just try the obvious names, backup.zip, credentials.json, and enough of them land. Once a bucket is found, cloning it is trivial. A single recursive download command pulls the entire folder structure, and keyword filters afterward sort out credentials, financial records, and anything marked confidential. It looks like the predictable outcome of free tooling meeting infrastructure nobody's watching. IP range-based scanning maps publicly published AWS IP ranges to detect object storage endpoints; if a bucket responds with an HTTP 200 on listing, it is flagged automatically. In the ShinyHunters/Nemesis operation of December 2024, a vast number of websites were scanned and a substantial volume of credentials, source code, and account secrets were exfiltrated from AWS customers, then stored in the attackers' own open S3 bucket.

Directly public buckets: incidents where the misconfiguration was the whole story

The simplest failure mode is also the most common one in the public record: someone sets a bucket to public, and that single decision is the entire incident. Accenture's 2017 exposure involved at least four buckets left open, spilling master AWS KMS access keys, nearly 40,000 passwords (most stored in plaintext), architecture code for a client-facing cloud platform, decryption keys, certificates, and API data, and it's still cited as one of the more damaging leaks of that year purely on business-risk grounds. The same year, a national defense department Department of Defense turned up in multiple separate leak disclosures pointing to the same systemic problem: a scraped archive of billions of social media posts, résumés for intelligence-track positions listing security clearance history, and private encryption keys for an intra-agency intelligence platform, all sitting in open storage.

The healthcare and consumer-data incidents read almost identically to each other, differing mainly in scale. Premier Diagnostics, a Utah-based COVID-19 testing service, had two publicly accessible S3 buckets between February and March 2021 that together exposed tens of thousands of patient records: one named "patient-images" held more than 200,000 images, four files per patient of insurance and ID cards, and a second labeled "paper-records" held names, dates of birth, and test sample IDs, with neither bucket having password protection or authentication. The International Spy Museum's Q1 2023 exposure was smaller in raw count, 100 credit card authorization forms tied to student reservations, but the irony of a spy museum failing basic opsec writes its own headline. A UK freelance doctors' staffing agency left buckets open in 2023 that disclosed personal data on thousands of people, discovered by Cybernews researchers who estimated tens of thousands of files sitting inside. The World Baseball Softball Confederation, headquartered in Switzerland, had a September 2023 exposure spanning tens of thousands of files, including copies of 4,600 national passports. A now-defunct New York marketing firm called Reindeer left tens of thousands of files open, touching hundreds of thousands of people with full names, addresses, emails, phone numbers, and hashed passwords. Pegasus Airlines leaked 6.5 terabytes in May 2022, including flight crew personal data and operational details.

CybelAngel's research found that cloud misconfigurations caused 23% of all cloud security incidents in 2025, and Gartner projects that the vast majority of cloud security failures through 2025 will be the customer's fault, not the provider's. Aye Finance and fintech partner Nupay had a public bucket in September 2025 spilling hundreds of thousands of NACH bank-transfer PDFs across dozens of Indian banks and lenders, unredacted account numbers, transaction amounts, names, phone numbers, and emails included, with the IPO-bound Aye Finance taking the brunt of the exposure while Nupay claimed responsibility for the bucket itself. Navy Federal Credit Union had 378 GB of internal backup files in a publicly accessible S3 bucket, discovered by researcher Jeremiah Fowler in September 2025, containing hashed passwords, encryption keys, database structures, and operational metadata in.gz,.sql, and.twbx files. Fatal Model, Brazil's largest escort platform, left two databases and its AWS storage open in March 2026; the logging database alone spilled AWS access keys for the storage account, and the combined exposure ran to millions of records and hundreds of gigabytes, escort photos, admin access tokens, and device data among them, again surfaced by Fowler, with the storage bucket staying open until a formal disclosure notice went out. Carla, a car rental aggregator, was still actively adding new files to an unsecured bucket when Cybernews found it in June 2026, roughly 48,000 booking confirmation PDFs carrying names, emails, phone numbers, booking numbers, rental dates, costs, and pickup locations, detailed enough to tell a burglar exactly when a customer's house would sit empty.

When the industry and the file type are stripped away, every one of these cases shares the same shape: a bucket readable by anyone, no credential required, discoverable by whoever bothered to point a scanner or a search tool at it. The data ranged from mundane operational records to sensitive personal information that turns a misconfiguration into a regulatory event, but the mechanism never changed.

Active buckets mistaken for abandoned ones, and abandoned ones forgotten entirely

A separate failure runs underneath the headline cases above: the deeper problem is less about carelessness at setup than about what happens after. Some open buckets are live production systems that everyone assumes someone else is watching. A 2025 financial services exposure involving bank-transfer PDFs, full names, addresses, phone numbers, account numbers, and routing codes, kept accumulating new files while researchers were actively studying it, proof it wasn't some forgotten test bucket but a working part of somebody's pipeline. A separate open bucket discovered in December 2024 turned out to be doing double duty as a shared network drive, holding customer data, keys, and secrets, with access controls that had simply never been turned on for what was, in practice, daily operational infrastructure.

Then there's the opposite failure: buckets nobody remembers exist. Capita, a London-based outsourcing firm, had roughly 3,000 files totaling 655 GB exposed to the internet since 2016, discovered in 2023, seven years of open exposure before discovery. CybelAngel's 2026 data puts average detection time for a configuration issue past 180 days, and attributes a good chunk of that lag to lifecycle neglect: test buckets and retired workloads that stay online long after the project that spun them up has wrapped. McGraw Hill's July 2022 exposure ran into many terabytes and hundreds of millions of files, including student grades and personal data, at a scale that suggests infrastructure grown faster than anyone's audit process could track.

What matters here isn't severity, it's intent. A bucket someone knows is public and just hasn't fixed yet is a management failure. A bucket nobody remembers provisioning is a different animal entirely, and no access review catches what nobody thinks to look for.

Third-party and inherited access as a compounding factor

Not every breach belongs to the organization whose name ends up in the headline. The Alteryx exposure of Experian's ConsumerView database is the clean version of this problem: the misconfigured bucket was Alteryx's, but the data inside belonged to Experian, so the company whose customers were actually at risk had zero control over the bucket that put them there. Laminar Security's research backs this up at scale, finding that a large share of what it calls mismanaged PII doesn't originate with the company whose name is on the data, it comes from a third-party vendor's sloppy environment instead. The BroadSoft/Time Warner Cable case from earlier fits the same mold precisely: the exposure sat in BroadSoft's infrastructure, not Time Warner Cable's, yet it was Time Warner Cable's customers whose information ended up loose.

SEGA Europe's January 2022 exposure widened the blast radius further. Its open bucket held AWS keys alongside third-party service keys for Steam and MailChimp, plus a path into Football Manager forum data touching hundreds of thousands of users, so one misconfiguration handed over access to several separate companies' systems at once. MPD FM, a UK facility management and security firm working across multiple government departments, left a bucket open in August 2023 packed with passports, visas, national IDs, driving licenses, birth certificates, vetting reports, right-to-work checks, contracts, and bank statements, and the individuals exposed were government employees, not MPD FM's own staff. PwC Nigeria's September 2023 exposure ran along the same fault line: thousands of files including copies of passports and government-issued IDs, résumés, and degree certificates were exposed. An organization can run internal bucket hygiene perfectly and still turn up in a breach notice, because the vendor holding its data somewhere downstream didn't.

When credentials inside the bucket become the second-stage attack

Exposed data and compromised credentials tend to get filed as separate problems. They shouldn't be, because a bucket doesn't have to choose between holding sensitive files and holding the keys to something bigger. It can, and often does, hold both. Accenture's 2017 bucket is the clearest early example: alongside the plaintext passwords sat master AWS KMS access keys, decryption keys, certificates, and API data, credentials that reach well past whatever files were sitting in that bucket at the time. SEGA Europe's 2022 incident repeats the pattern in miniature, one open bucket yielding AWS keys plus Steam and MailChimp keys, a single failure point that opened doors into several unrelated systems. Fatal Model's March 2026 exposure showed the loop closing in real time: the publicly accessible logging database spilled the AWS access keys for the associated cloud storage account, so access to one resource automatically yielded the credential to access the other.

ShinyHunters/Nemesis turned this into an operating model rather than an accident. The Codefinger ransomware group, active from January 2025, skipped the harvesting step and went straight to weaponizing stolen AWS credentials: it accessed victim buckets and applied SSE-C encryption using attacker-generated AES-256 keys that AWS itself never retains, so there's no decrypting the data without paying whoever holds the key. A related operation surfaced a huge cache of AWS secret key records, and a large share of those keys turned out still active and got used to encrypt more buckets. A mid-sized US software company ran into a similar exposure in early 2025, when an anonymous actor claimed access to its buckets and listed that access for sale on dark web forums, the result of access controls that simply weren't tight enough to stop it. Datadog's 2024 report ties the whole pattern together at the root cause: long-lived cloud credentials that never expire, and that keep turning up leaked in source code, container images, build logs, and application artifacts, are the single most common cause of the cloud breaches that actually get documented publicly. A bucket holding a key is both a storage problem and a credential problem. It's already both, and has been from the start. In the ShinyHunters/Nemesis operation of December 2024, websites were scanned for improperly configured public sites, over 2 TB of credentials and source code were exfiltrated, and the data was then stored in an open S3 bucket the operation itself controlled (demonstrating the full chain from discovery to credential harvest to reuse).