TL;DR: A publicly accessible Amazon S3 bucket exposed more than 273,000 Indian bank transfer records, with thousands of new files added daily and at least 38 financial institutions affected, according to Swarmnetics. Storage misconfigurations, not just theft, can turn ordinary cloud access settings into persistent data exposure.
At a glance
What this is: A public Amazon S3 bucket exposed more than 273,000 Indian bank transfer records, showing how a storage configuration gap can create prolonged data exposure.
Why it matters: Cloud teams, IAM leads, and identity governance practitioners should treat bucket exposure as an access-control failure, because public settings, wildcard policy drift, and weak change governance can make sensitive data reachable at internet scale.
Context
A public cloud storage exposure is often less about a single theft event and more about whether access controls were configured and governed correctly from the start. In this case, the security issue sits at the boundary of cloud security and identity governance, because the effective control was who could make the bucket public and how that decision was monitored.
The article describes a publicly accessible Amazon S3 bucket containing banking records, some with sensitive financial details, and says the exposure remained open for about a week and a half after discovery. That makes the case typical of a governance failure where ownership, change control, and access scope were not aligned closely enough to prevent external reachability.
Key questions
Q: What breaks when an S3 bucket is made public without strict governance?
A: Public access turns a storage setting into an external exposure path, which means any sensitive object placed in the bucket can become reachable outside the intended trust boundary. The failure is usually not the absence of data protection entirely, but the absence of change control, approval, and continuous monitoring over who can alter exposure.
Q: Why do public cloud storage exposures create so much risk for regulated data?
A: Because regulated data often remains sensitive even when no account is directly compromised. If a bucket is publicly reachable, discovery tools and repeated access attempts can surface records quickly, and the resulting exposure can affect privacy, fraud, and operational trust. The longer the bucket stays open, the larger the governance failure becomes.
Q: What are the signs that public storage controls are failing?
A: Repeated appearance of newly added objects in a bucket that should be private, weak ownership of public access settings, and inconsistent enforcement of bucket policies are all warning signs. If third parties or broad admin roles can change exposure without alerting security teams, the control is already failing in practice.
Q: Who should be accountable for public cloud bucket exposure governance?
A: Accountability should be shared between cloud security, IAM, and the application or data owner, with clear approval rights for any change that affects reachability. The team that owns the data should not be the only control point if another identity can make the bucket public. Governance must follow the privilege that can change exposure.
Technical breakdown
How public S3 exposure becomes a data governance failure
Amazon S3 buckets are only as safe as their access settings, policy boundaries, and ownership controls. If public access is enabled, or if newly created objects inherit a permissive posture, the storage layer becomes internet-reachable even when the data itself was never meant to be public. In practice, the risk is not limited to one bucket. Misconfigured ACLs, permissive bucket policies, and weak change approval can combine to create a durable exposure path that outlives the original mistake.
Practical implication: Treat public bucket exposure as an access governance problem, not just a storage issue.
Why search tools and automation change exposure risk
Once a bucket is exposed, discovery no longer depends on chance. Search engines for internet-exposed services can surface misconfigured storage quickly, which means attackers or opportunistic scanners do not need insider knowledge to find it. That changes the risk model for cloud storage, because a control that fails silently may still be exploited at scale before the owner notices. The result is a governance gap between intended internal use and actual external reachability.
Practical implication: Assume exposed storage will be discovered quickly and monitor for public reachability continuously.
Where IAM and cloud policy controls break down
This incident also shows how identity and access management controls fail when permissions are too broad. If third parties or internal admins can change public access settings without strong guardrails, identity-based privilege becomes the path to data exposure. Wildcard actions, weak separation of duties, and missing service-control policies make it easier for a legitimate identity to produce an illegitimate outcome. In that sense, the breach is not only about the bucket. It is about who had authority to make it public and whether that authority was constrained.
Practical implication: Use identity-bound guardrails to restrict who can change public access settings.
Threat narrative
Attacker objective: The likely objective is to collect sensitive banking and customer information from a misconfigured cloud storage location without needing to compromise the application directly.
- Entry occurred when a publicly reachable S3 bucket was left exposed to the open internet instead of being restricted to approved users and systems.
- The exposure widened because the bucket continued receiving new records daily, which prolonged the window in which sensitive banking data could be discovered or collected.
- The impact was persistent visibility into transfer records from multiple institutions, including account numbers, bank codes, and contact details.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Symantec mobile apps AWS keys 2022: Symantec found AWS keys hard-coded in 1,859 mobile apps; 77% were valid, many shared via SDKs, one exposing 300,000 fingerprints. No misuse reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Public cloud storage becomes a governance problem the moment exposure is controlled by identity and policy rather than by the data owner alone. This incident is not mainly about Amazon S3 as a product. It is about the failure to make public reachability a controlled exception with accountable approval, review, and revocation. Practitioners should treat bucket exposure as a policy outcome that must be governed like any other privileged configuration change.
Configuration gap is the right label only if it means a real control gap, not a cosmetic misset. The meaningful failure here is that a sensitive banking data store was reachable from the internet and remained so long enough to accumulate fresh records. That points to weak enforcement around public access settings, object inheritance, and third-party change authority. Practitioners should read this as evidence that configuration governance is part of data security, not a separate concern.
Storage exposure and identity exposure are now tightly coupled in cloud environments. A permissive bucket policy, an overbroad admin role, or a vendor account with change rights can all produce the same outcome. That is why cloud security teams and IAM teams need shared accountability for public-data risk, especially where third parties can alter access posture. Practitioners should align bucket governance with least privilege and separation of duties.
Internet-exposed object stores create a standing discovery problem, not a one-time misconfiguration event. Once an object store becomes publicly reachable, automated discovery and repeated access attempts become part of the threat model. The relevant control objective is therefore not just fixing the bucket after discovery, but making exposure hard to create, easy to detect, and impossible to leave unreviewed. Practitioners should measure time-to-detect for public storage as a core risk indicator.
Cloud data exposure now sits at the intersection of NIST-CSF, NHI governance, and privileged configuration management. A bucket that can be made public by the wrong identity is an identity governance failure even when no credential is stolen. The discipline should shift from assuming storage settings are static to assuming they are changeable attack surfaces. Practitioners should bind public-access changes to governed identities and auditable approvals.
What this signals
Public data exposure is now a change-governance issue as much as a storage issue. If a bucket can become internet-reachable through a routine configuration change, then the control problem sits in approval, policy enforcement, and continuous drift detection. Cloud and IAM teams should review who can alter reachability, not just who can read the data.
Standards such as NIST-CSF and least-privilege access matter here because the failure is authority, not syntax. The practical question is whether a legitimate identity can create an illegitimate exposure state. Practitioners should tighten change authority over public-access settings and align it with auditable workflow controls.
Configuration drift in storage should be treated as a standing signal for data security response. Once a public bucket is found, the response should include access review, object classification, and checks for whether sensitive records were ever meant to land there in the first place. The programme lesson is that exposure detection must feed directly into data governance, not wait for a separate incident process.
For practitioners
- Restrict public-access changes to approved identities Use service control policies and equivalent guardrails so only designated administrators can change public access settings on storage buckets.
- Eliminate wildcard policy paths Review identity-based policies for wildcard actions that could allow unintended exposure of storage objects or public read states.
- Monitor for public bucket drift continuously Enable monitoring that flags when a bucket, object, or ACL becomes internet-reachable outside approved change windows.
- Scan exposed storage for sensitive data Use object classification and content inspection to detect banking records, account numbers, and other sensitive data in locations that should remain private.
- Encrypt and classify regulated data before storage Apply encryption at rest and data classification controls to reduce impact if a storage configuration change makes content reachable.
Key takeaways
- A public S3 bucket can become a sustained data exposure event when access settings are misgoverned, not merely misconfigured.
- The article describes more than 273,000 exposed Indian bank transfer records and thousands of new files added daily, which shows how fast cloud exposure can accumulate.
- The most effective control is not only private-by-default storage, but strict approval and monitoring over who can change public reachability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident centers on who could change bucket exposure and whether access was constrained. |
| Recommendation — Restrict bucket exposure changes through governed permissions and auditable approval workflows. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Overbroad administrative authority can make a storage misconfiguration possible. |
| Recommendation — Limit the identities that can alter public access and remove unnecessary privilege. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and privilege governance determines who can create or persist public exposure. |
| Recommendation — Review account rights that can change storage exposure and revoke excess privilege. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud bucket exposure depends on identity governance over privileged configuration changes. |
| Recommendation — Apply cloud IAM governance to public-access changes and third-party administrative paths. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | Publicly exposed storage supports collection and theft of sensitive records. |
| Recommendation — Map exposed object stores to credential access and exfiltration detection priorities. | ||
Key terms
- Public Cloud Storage Exposure: Public cloud storage exposure happens when files stored in a cloud service become reachable beyond the intended audience because of weak access controls, account compromise, or unsafe sharing settings. It often turns routine file sharing into broad internet-accessible risk when sensitive content is synchronized without review.
- Bucket Public Access Control: The policy and permission settings that determine whether an object storage bucket can be read or modified by unauthorised parties. In practice, this includes public access blocks, bucket policies, ACL behaviour, and the governance process that approves changes to those settings.
- Identity-Based Policy Drift: A gradual change in permissions where legitimate roles or accounts accumulate broader access than intended. In cloud environments, drift can let an identity alter storage exposure, create public paths, or bypass separation of duties without triggering obvious alarms.
- Data Exposure Window: The period during which sensitive information remains reachable to unauthorised parties before detection and remediation. Shortening this window depends on continuous monitoring, clear ownership, and fast revocation of the condition that made the data accessible.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management for practitioners who need to connect identity controls to real-world access risk. It helps security teams build the governance discipline needed to manage privileged access across cloud and identity programmes.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org