TL;DR: A publicly accessible Amazon S3 bucket exposed records for more than 273,000 Indian bank transfers, with researchers finding thousands of new records added daily and at least 38 financial institutions affected, according to UpGuard and the source reporting this incident. The case shows how configuration gaps, not just theft, can turn cloud storage into a persistent data exposure problem.
NHIMG editorial — based on content published by Swarmnetics covering the public S3 bucket exposure: Public-Facing Amazon Storage Bucket Exposed Over 273,000 Indian Bank Transfers
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Audit third-party identities with bucket write privileges Map every vendor, service account, and automation role that can write to storage or alter ACLs.
- 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.
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.
👉 Read Swarmnetics' analysis of the public S3 bucket exposing Indian bank transfer records →
Public S3 bucket exposure: what it means for cloud and identity controls?
Explore further
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.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Public S3 bucket exposure shows how storage misconfigurations become data risk