Public S3 bucket exposure shows how storage misconfigurations become data risk

At a glance

What this is: A publicly accessible Amazon S3 bucket exposed bank transfer records and other sensitive financial data for over 273,000 transactions in India.

Why it matters: This matters because cloud storage exposure is often an access-control failure first, and identity governance teams need visibility into who can change public settings, not just who can read data.

By the numbers:

• Some studies have indicated that about 7% of all Amazon storage buckets of this sort are exposed to the internet, and about 21% of these contain some sort of sensitive data.

👉 Read Swarmnetics' analysis of the public S3 bucket exposing Indian bank transfer records

Context

Amazon S3 exposure is a cloud security and data governance problem, but it also has an identity angle because public access is usually the result of mis-scoped permissions, weak change control, or over-broad third-party access. In this case, the primary failure was not a sophisticated exploit but a storage configuration gap that left sensitive banking data reachable from the internet.

The article centres on banking transfer records tied to India’s National Automated Clearing House, so the issue spans data security, cloud posture, and access governance. That makes it relevant to teams responsible for cloud IAM, third-party permissions, and controls that prevent one account from making a bucket public for everyone else.

Key questions

Q: What fails when an S3 bucket is made public by mistake?

A: A public bucket fails the basic assumption that storage access is mediated by identity and policy. Once public access is enabled, the control boundary moves from authenticated users to anyone who can find the object path, which makes sensitive data exposure possible even without account compromise. The failure is usually not encryption but access governance and change control.

Q: Why do third-party identities make cloud storage exposure harder to govern?

A: Third-party identities often need temporary write access, but that access can include the ability to change object visibility or public settings if it is not tightly scoped. When vendor roles are not time-bound and reviewed, a short operational task can become persistent exposure. That creates both security risk and accountability problems when data is later found in public storage.

Q: How do security teams know if public cloud storage controls are working?

A: Measure how quickly changes to bucket policies and ACLs are detected, and track how many identities can alter public access without approval. If sensitive objects are still landing in buckets that external scanners can find, the control is not working. Effective governance should show narrow change authority, clear logs, and rapid remediation of drift.

Q: Who is accountable when sensitive data crosses cloud and on-prem boundaries?

A: Accountability should sit with the team that owns the access path, key custody, and monitoring controls, not just the storage platform owner. In practice, that means identity, security, and compliance teams need a shared governance model with clear ownership for residency, session control, and evidence retention across environments.

Technical breakdown

How public S3 exposure happens

Public S3 exposure usually starts when bucket policies, ACLs, or account-level public access controls are changed in a way that permits anonymous retrieval. Even when AWS has default protections, a mis-scoped policy or a third-party account with excessive rights can override the intended boundary. Once the object path is public, security depends on whether the data is indexed, discovered, and copied before the misconfiguration is corrected. In many incidents, the technical failure is not encryption or storage itself but the absence of a strict control plane around who can alter exposure settings.

Practical implication: restrict who can change bucket exposure and require change approvals for any public-access modification.

Why third-party access becomes a storage governance problem

Third-party vendors frequently need write or maintenance access to cloud buckets, but that access can become risky when identities are not tightly scoped. If a vendor role can create objects, change ACLs, or modify public-access settings, the trust boundary shifts from data owner to external operator. That is an identity governance issue as much as a cloud issue, because the organisation must know which accounts can change visibility, when those permissions expire, and whether those actions are logged and reviewed. Without lifecycle control, a temporary vendor task can become permanent exposure.

Practical implication: inventory third-party identities with write privileges and review whether they can alter access settings at all.

Why exposed data becomes easy to find and hard to ignore

Public buckets are not only vulnerable to opportunistic browsing. Search tooling, crawler infrastructure, and internet-wide scanners can surface exposed storage quickly, which compresses the time from misconfiguration to discovery. In regulated financial data environments, that means an exposure can persist long enough to create reporting, remediation, and accountability problems even if the owner later closes it. The risk is amplified when new records keep landing in the bucket, because the exposure window is continuously refreshed instead of being a one-time mistake.

Practical implication: monitor public exposure continuously and alert on any bucket that keeps receiving sensitive records while publicly reachable.

Threat narrative

Attacker objective: The objective would be to collect sensitive banking and customer data from a publicly reachable cloud storage location without needing to defeat authentication.

1. Entry occurred when a publicly accessible Amazon S3 bucket was left open to the internet through a configuration gap.
2. Escalation followed because the bucket contained ongoing bank transfer records, so every new upload extended the exposure window and increased the amount of retrievable data.
3. Impact was the exposure of records tied to at least 38 financial institutions, including account numbers, bank codes, transaction details, and personal contact information.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Configuration gap exposure is a governance failure, not just a cloud mistake: this incident shows that a bucket can be technically reachable because access control was not bounded tightly enough. The problem is not only whether public access was turned on, but who had the authority to change that setting and how quickly the change was detected. For IAM and cloud governance teams, the lesson is that public-access controls are identity controls in disguise.

Third-party write access becomes dangerous when lifecycle controls are weak: the report describes a fintech company taking responsibility, which points to delegated operational access as a likely governance pressure point. If a vendor role can alter object visibility, create new records, or persist after the task ends, the organisation has no clean boundary between service delivery and data exposure. That is where cloud IAM, offboarding, and approval workflows must converge.

Persistent ingestion turns a single misconfiguration into a moving target: thousands of new records being added daily means the exposure was not static. This is the kind of operational pattern that makes manual remediation unreliable, because the risk window keeps reopening as new data lands in the bucket. Practitioners should treat public exposure as a control-state drift problem, not a one-time incident response problem.

Access visibility has to extend beyond human users to the service accounts and vendor identities that touch storage: many storage incidents are enabled by non-human identities with broad permissions. When those identities can modify bucket policy, object ACLs, or public settings, the cloud boundary is only as strong as the weakest machine identity governance process. The practical conclusion is that cloud storage must be governed as part of NHI and IAM, not outside it.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Forward look: The NHI Lifecycle Management Guide shows how to bind access, rotation, and offboarding into a single control pattern.

What this signals

Public storage exposure is increasingly a governance and identity problem, not only a misconfiguration problem: when third-party identities can influence bucket visibility, cloud security teams need lifecycle controls for those identities, not just better scanning. The practical shift is toward tighter approval boundaries, shorter-lived delegated access, and direct oversight of who can alter exposure settings.

Configuration drift needs to be treated as an access event: a bucket becoming public should trigger the same attention as an unusual privilege grant. Continuous detection of policy changes, coupled with asset-level sensitivity tagging, gives teams a chance to stop exposure before more records accumulate.

The broader signal is that cloud storage now sits at the intersection of data security, IAM, and vendor governance. Teams that already track service-account ownership, permission scope, and offboarding discipline will be better positioned to reduce exposure windows when storage settings drift.

For practitioners

• Lock down who can change public access settings Use account-level guardrails and approval workflows so only a small set of trusted identities can modify bucket exposure. Pair that with explicit denial of wildcard policy actions and periodic review of any roles that can make storage public.
• Audit third-party identities with bucket write privileges Map every vendor, service account, and automation role that can write to storage or alter ACLs. Remove permissions to change visibility unless there is a documented operational need, and set expiry on temporary access.
• Continuously scan for public storage and sensitive objects Enable continuous monitoring for externally reachable buckets and run sensitive-data discovery on all storage locations that may receive regulated records. Alert on any bucket that remains public while new objects are still being added.
• Treat storage policy drift as an incident signal Build detection for changes to bucket policies, ACLs, and public-access controls, then route those changes into SOC triage and cloud governance review. The goal is to catch exposure at the moment it is created, not after data has accumulated.

Key takeaways

• A public S3 bucket can expose regulated data without any credential theft if access control is mis-scoped.
• The scale matters because thousands of new records being added daily turn a single mistake into a persistent exposure window.
• The control gap is governance over who can change visibility, especially among third-party and service identities.

Key terms

• Public Storage Exposure: A public storage exposure occurs when cloud objects or buckets are reachable from the internet without the intended authentication or authorisation boundary. In practice, the weakness is usually a policy, ACL, or account-level setting that permits anonymous access to data that should have remained restricted.
• Context Gap: The context gap is the distance between a rule that looks correct on paper and the real meaning of a request inside an AI workflow. It appears when language changes meaning through history, sequence, or social engineering, and it is one reason fixed filters struggle with agentic abuse.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• Bucket Policy Drift: Bucket policy drift is the gradual or sudden divergence between the intended access rules for a storage bucket and the rules currently in force. It matters because small permission changes can reopen public access, extend exposure windows, or allow new data to become visible without approval.

What's in the full analysis

Swarmnetics' full article covers the incident detail this post intentionally leaves for the source:

• The incident timeline and the sequence of discovery, disclosure, and remediation for the exposed bucket.
• The researchers' file sampling approach, including the 55,000-file analysis and what it revealed about the data types involved.
• The vendor response and the specific explanation offered for the exposure, including the configuration gap framing.
• Amazon control recommendations for bucket public-access settings, monitoring, and sensitive-data scanning.

👉 Swarmnetics' full post covers the exposed data scope, discovery details, and the response from the responsible fintech company.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps practitioners connect identity controls to real operational risk across modern security programmes.