Open S3 Buckets in 2026 — Still the #1 Source of Mass Disclosure

The Cloud's Structural Guarantee: Misconfiguration Will Always Precede Detection

Six years after the Optus breach exposed 9.8 million Australians via an exposed AWS API endpoint, and four years after the Medibank incident revealed similar carelessness across 9.9 million records in misconfigured S3 buckets, the industry continues to respond to S3 exposure incidents as though they were anomalies requiring better compliance posture. They are not anomalies. They are the inevitable outcome of an architectural model that places data visibility and access control at the outer perimeter, where intent and capability converge in plain sight—a design that guarantees breach precedes detection, and detection arrives only after aggregation and exfiltration are complete.

In 2024–2025, the cloud misconfiguration landscape has not improved; it has simply shifted. A Snyk report documented over 28 million publicly accessible cloud storage objects across AWS, Google Cloud, and Azure in the first half of 2024. Wiz's State of Cloud Security research observed that 28% of cloud accounts still exposed sensitive data via misconfigured permissions policies—not through exploitation of code vulnerability or lateral movement, but through basic policy and ACL (Access Control List) misstatement. The Snowflake tenant cascade of early 2024, triggered by compromised service account credentials and exacerbated by overly permissive cross-tenant network policies, demonstrated that even sophisticated SaaS vendors cannot insulate customers from the gravitational pull of default-allow architectures. Yet the industry's response remains mechanical: add cloud access broker enforcement, layer in CSPM (Cloud Security Posture Management) tooling like Prisma Cloud or Wiz, tighten policy templating, and schedule more SSOc reviews. None of these approaches prevents the fundamental condition: data must be stored somewhere it is accessible, and access rules must be declared before they can be misconfigured.

The Industry Narrative: Detection, Remediation, Compliance

The published narrative is well-rehearsed. Security leaders point to the rise of cloud storage usage—estimates suggest over 60% of enterprise data now sits in cloud object storage, with AWS S3 commanding roughly 40% market share. Threat researchers document scanning campaigns: attackers systematically enumerate S3 bucket namespaces using simple wordlists (organisation-prod-backup, company-logs-archive, infrastructure-terraform) and probe ACL configurations using the AWS CLI or boto3, discovering buckets where the bucket-owner-full-control canned ACL has been replaced with public-read or authenticated-users access. AWS itself has published best-practice guidance—requiring explicit bucket policy review, blocking public-access-via-S3 at the account level via the BlockPublicAccess configuration, and enforcing MFA delete on critical buckets. The NIST CSF (Cybersecurity Framework) Identify function and ISO 27001 A.8.3 (Access Control) explicitly require periodic access control review.

Yet the empirical evidence is unambiguous. In 2022, the Latitude Financial breach exposed 14 million Australians and New Zealanders after attackers exploited a vulnerability in Latitude's API, but the cascade amplified through misconfigured cloud storage where backup data had been replicated. The NHS Synnovis incident in 2024—attributed to LockBit and resulting in operational shutdowns across pathology services in London—hinged partly on credential compromise, but propagated through misconfigured backups stored in Azure Blob Storage and AWS S3 with overly permissive service principal permissions. The M&S incident in late 2024, attributed to Scattered Spider, combined social engineering with lateral movement into cloud environments; once inside, the attackers found data lakes with inherited cross-account permissions that had never been exercised and thus never rigorously tested.

The pattern is consistent across sectors. Change Healthcare's 2024 incident—the largest healthcare data breach in US history, affecting over 100 million individuals—followed exploitation of a zero-day in Synthetichealth's MOVEit software, but the subsequent data aggregation and exfiltration leveraged cloud storage misconfigurations that were already in place. Financial regulator enforcement is now tightening: the FCA's Senior Management Certification Regime (SM&CR) now holds C-suite executives personally accountable for data control failures, not merely as risk-management oversights but as failures of statutory duty. The SEC's 4-day breach notification rule, DORA (the EU's Digital Operational Resilience Act), and NIS2 all now mandate that organisations demonstrate not just that breaches are detected within days, but that loss-prevention is engineered into the infrastructure itself.

Why Posture Management is a Treadmill

The cybersecurity industry's response has been to move detection upstream. Gartner's CSPM quadrant now includes Prisma Cloud (Palo Alto), Wiz, Lacework, and Snyk—tools that scan S3 buckets, Azure Blob containers, and GCP Cloud Storage for misconfigured ACLs, overly permissive bucket policies, and unencrypted or unversioned objects. These tools are genuinely useful for cataloguing risk, but they are fundamentally reactive: they report what is misconfigured after misconfiguration has occurred. They offer no mechanism to prevent the misconfiguration in the first place, nor to render data inaccessible even if misconfiguration occurs. A CSPM alert fires when a Terraform module or CloudFormation template is deployed with "Principal": "" in a bucket policy; the alert is post facto*, issued after the stack has been provisioned. The remediation cycle—alert, investigation, policy change, redeployment—is days or weeks long. In that interval, data is exposed. The Snowflake cascade happened while Snowflake's own security team was refining their detection logic. This is not a detection problem. It is a data exposure problem, and no amount of posture scanning eliminates it.

The architectural assumption underlying CSPM is that humans will read alerts and make correct decisions quickly. The evidence suggests otherwise. Many organisations discover their S3 misconfigurations not through CSPM tools but through public disclosure, third-party security researchers, or forensic investigation after breach. The 2024 Snyk data—28 million exposed objects—was detected largely through security research sweeps, not through proactive customer CSPM implementations. AWS's own BlockPublicAccess feature, introduced in 2018, requires explicit account-level enablement and does not ship as default; organisations that deploy it retroactively often do so only after incident. The compliance model—audit S3 configurations quarterly, remediate findings within 30 days—assumes that exposure risk is proportional to dwell time. But dwell time is not the constraint. Enumeration is. An attacker who knows that your bucket acme-corp-prod-backups exists and carries public-read ACL can exfiltrate years' worth of historical snapshots in minutes. Posture remediation, done weekly or quarterly, is always too late.

The Structural Failure Mode

PULSE's reading of this landscape is straightforward: cloud object storage is architecturally incapable of preventing misconfiguration-driven disclosure because it treats access control as a policy layer outside the data plane. In S3's model, data exists in a bucket; the bucket has an ACL, a policy, and identity-based permissions; these are evaluated before data is returned. If evaluation is incorrect—if the policy is malformed, if the principal identifier is too broad, if environment variables or template variables render the policy more permissive than intended—data flows outward. There is no substrate-level mechanism that prevents the flow. No cryptographic commitment that renders data unreadable even if ACL evaluation is bypassed. No architectural separation between the storage of data and the storage of permission to access that data.

Compare this to AWS KMS (Key Management Service), where encryption keys are held in a hardware security module (HSM) and never leave the service boundary. You cannot misconfigure your way into plaintext decryption if the key itself is unreachable. Yet S3 does not ship with mandatory end-to-end encryption, and even where encryption is enabled (S3-managed or customer-managed KMS), the key policy is itself another attachment point for misconfiguration—a policy that grants unintended principals access to decrypt. The model guarantees that as long as data is stored unencrypted, or as long as the decryption key is accessible via misconfigured KMS policy, the risk is present. The control-plane (policy, ACL, identity) and the data-plane (actual object storage) are not separated by any mechanism that prevents misconfigured intent from executing on data.

The regulatory environment now recognises this implicitly. DORA, which came into force in January 2025, mandates "operational resilience" and explicitly requires that organisations demonstrate they cannot lose access to critical data due to ICT (Information and Communication Technology) incidents—a clause that includes misconfiguration. NIS2 similarly requires "organisational and technical measures" to ensure that "loss of availability, authenticity or integrity of data does not impede essential functions". These are not audit requirements. They are architectural mandates. You cannot satisfy them by running CSPM tools. You satisfy them by ensuring that misconfiguration of access controls cannot result in data loss or disclosure.

Architectural Principles from the PULSE Doctrine

Post-breach resistance via architecture, not detection, means moving from "prevent misconfiguration" to "make misconfiguration irrelevant". This requires three architectural shifts.

First: Zero-Knowledge Substrate. Data must be stored encrypted at rest, with decryption keys held in a boundary that is logically and operationally separate from the storage layer. More precisely: no object in cloud storage should be readable without explicit cryptographic proof of authorisation, and that proof should be issued by a service that is not itself misconfigurable in the same way the storage layer is. This is not S3 server-side encryption with KMS. It is encryption before upload, where the plaintext never touches AWS infrastructure, and where the key remains with the client or in a separate hardware boundary. Alternatively, it is a thin custody layer—a service that holds encrypted data on behalf of clients but refuses to decrypt without continuous verification that the request is authorised at the time of request, not merely at the time of initial permission-granting. This is zero-knowledge: AWS (or Azure, or GCP) holds ciphertext and cannot read plaintext. Misconfiguration of IAM policies or bucket ACLs yields access to encrypted bytes, not data.

Second: Control-Plane and Data-Plane Separation. Access control decisions must not be made by the same service that holds the data. A client application requesting data from S3 should not receive plaintext; instead, it should receive a signed token from an authorisation service (separate from storage) that proves "this principal may access this object right now". The storage service validates the token before responding. If the token is forged or expired, or if the authorisation service revokes the token (because misconfiguration was detected), the storage layer rejects the request. This creates an audit boundary: every access becomes a logged event in the authorisation service, not merely a policy evaluation in S3. And more importantly, it means the authorisation service can be designed with far fewer degrees of freedom—fewer configuration vectors, more constrained by domain logic.

Third: Adaptive Adversarial Posture. Rather than assuming "misconfiguration is rare and should be detected", assume "misconfiguration is endemic and should be expected". This means: (a) continuous automated testing of access control boundaries—every hour, every deployment, a synthetic requester tests whether unauthorised principals can read data; (b) immediate revocation: if any synthetic test passes when it should fail, all tokens to that resource are revoked and a real-time alert is issued; (c) rapid redeployment: the infrastructure automatically resets to a known-good state. This is not "quarterly posture review". It is "continuous adversarial validation".

Domain-specific automation engineered into the substrate means the authorisation service is not a generic ABAC (attribute-based access control) engine like Okta or Ping Identity, which can be misconfigured in infinite ways. It is a thin service that knows exactly what data it is protecting and enforces a small, fixed set of rules: "customer A can access their own records", "read-only tokens expire after 4 hours", "tokens are non-transferable", "if three failed decryption attempts occur, alert and revoke all tokens to this principal". The rule set is domain-specific, not role-based. It is implemented in code that is version-controlled, tested before deployment, and audited by people who understand the domain.

The Practical Implication

An organisation protecting 500 million healthcare records should not be relying on S3 bucket policies and IAM role assumptions to prevent disclosure. They should be using a storage architecture where: (1) data is encrypted before it leaves their boundary, (2) keys are held in a separate custody layer, (3) every access is validated by an authorisation service that understands the business logic ("this patient's record can be accessed by this clinician during their shifts"), and (4) the authorisation service is tested every hour to ensure it is not issuing tokens when it should not be. If a Terraform variable is misconfigured and a bucket ACL is inadvertently set to public, the exposure is of encrypted bytes, not patient data. If an IAM role is overly permissive, an attacker who assumes that role gets a token from the authorisation service—and the service has already rejected invalid token requests and alerted the security team.

This is not novel cryptography. It is disciplined application of already-existing primitives: client-side encryption, hardware security modules, stateless token validation, continuous testing. But it requires moving away from the assumption that S3 is a "secure by default" service (it is not) and that misconfiguration is "an operator problem" (it is an architecture problem).

Regulatory Alignment and Closure

The regulatory environment—DORA, NIS2, FCA SM&CR—now explicitly requires organisations to engineer loss-prevention into infrastructure. AWS's own Responsible Disclosure Policy now includes a clause acknowledging that misconfiguration is the organisation's responsibility, not AWS's—a legal position that absolves the vendor of liability for breaches caused by overly permissive bucket policies. This shift places the burden squarely on organisations: you must ensure that misconfiguration cannot cause disclosure. Posture management tools satisfy the audit tick-box, not the statutory obligation.

The empirical pattern—Optus, Medibank, Latitude, Synnovis, M&S, Change Healthcare—all demonstrate the same failure mode: data stored in a location that can be accessed if permission rules are misconfigured, and no architectural mechanism that renders data inaccessible even if permission is misconfigured. Six years of CSPMs and SOCc reviews have not moved the needle. The 2024 Snyk research proves it. Bucket enumeration and misconfiguration discovery remain trivial. Detection, as an industry strategy, has flatlined.

If your organisation holds or transfers data subject to DORA, NIS2, APRA CPS 234, MAS TRM, FCA SM&CR, or SEC requirements, you are now operationally required to engineer post-breach resistance into your infrastructure. This means storage architectures where misconfiguration of access controls cannot result in disclosure. Posture scanning is necessary; architectural redesign is mandatory.

Qualified operators in regulated industries are invited to request a confidential briefing on zero-knowledge substrate patterns and domain-specific authorisation architectures under executed mutual NDA.