TL;DR: S3 bucket squatting still persists in AWS open-source paths despite account-namespaced buckets and prior service patches, according to Upwind, because SDK defaults, ownership checks and remediation logic each failed in different ways. Half-fixed controls leave the old attack pattern alive long after the headline fix lands.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Upwind's research: S3 bucket squatting survives when SDK defaults, predictable names and missing ownership checks remain in place across AWS service layers.
Why it matters: This matters because cloud workloads, ML pipelines and logging paths can be redirected to attacker-owned storage when identity and ownership checks are not enforced at the point of use.
Context
S3 bucket squatting is a cloud resource hijack pattern, not a novel malware family. It appears when a service or SDK assumes a bucket name implies ownership, even though the same name can be claimed or reused in ways the caller does not control.
The underlying security gap is responsibility drift between platform fixes, SDK defaults and customer deployments. When a remedial change lands in one layer but not the others, defenders can end up trusting a control that no longer reaches the actual attack path.
In AWS environments, that gap becomes more dangerous because storage targets are often embedded in ML jobs, analytics workflows and log pipelines. The result is a predictable cloud exposure pattern, not an isolated misconfiguration.
Key questions
Q: Why does a predictable S3 bucket name create data exfiltration risk?
A: A predictable S3 bucket name can let another account create the same name first, so Athena or other clients may write query results or logs to an attacker-controlled bucket. That can expose data, break integrity, and redirect outputs unless the bucket policy, ownership checks, and naming scheme prevent cross-account collisions.
Q: What should teams do first when a storage target may be squatted?
A: Teams should verify ownership before use, then pin the target to the expected account or project and refuse writes unless the owner matches. That means checking DNS, bucket, or volume ownership records, claiming abandoned names quickly, and using service-side controls such as expected-owner headers or allow-lists to stop squatting and hijack of storage targets.
Q: Why do SDK defaults keep storage hijack risks alive?
A: SDK defaults keep storage hijack risks alive because the client library may auto-generate or reuse a bucket name, endpoint, or region without validating who owns the destination. If the application trusts that default, a squatter can register the target first and receive data. Service-side owner checks and explicit destination configuration remove that dependency.
Q: What is the difference between a service-level fix and an SDK-level fix?
A: A service-level fix changes the storage platform’s own control plane, such as enforcing ownership checks, rejecting ambiguous names, or requiring explicit bucket confirmation. An SDK-level fix changes the client library behaviour, such as avoiding unsafe defaults or forcing the caller to supply the destination. The former protects all clients; the latter only protects users of that library.
Technical breakdown
Shared bucket namespaces and predictable naming
S3 bucket squatting works when a service derives a bucket name from stable values such as account ID, region or service prefix. If the namespace is shared and the name is guessable, an attacker can pre-create the target before the legitimate workload runs. The key failure is not storage access alone. It is the combination of deterministic naming and a trust decision that treats name match as sufficient. That pattern appears in SDK defaults, autogenerated resources and documentation-driven code reuse. Once the bucket exists, the workload may route data, logs or code to the attacker-owned destination without any obvious authentication failure. See the Amazon S3 Security Guide.
Practical implication: Treat predictable bucket naming as an access-control issue, not a convenience feature, and remove it from default code paths.
Why ownership checks fail in client-side paths
An ownership check only protects the flow it actually reaches. In these bucket squatting cases, the check could exist in one branch, one API path or one console action while other SDK calls still trust the bucket name alone. That creates a partial remediation problem: the defense looks present, but the vulnerable branch remains reachable through a different code path. The technical weakness is often subtle, such as checking ownership only after a condition that already implies the user owns the bucket. A fix that does not sit at the same decision point as the risky operation can leave the attack fully open.
Practical implication: Verify that ownership validation executes on every create, write and read path that can resolve a bucket target.
Default storage targets in ML and analytics workflows
ML and analytics services are especially exposed because they routinely move code, model artifacts, query outputs and logs through storage buckets. When those services auto-build bucket names, a squatted bucket can become a durable interception point for high-value payloads. That is why the impact can range from silent data capture to execution on live workloads. The storage destination is not just a sink. It is part of the execution chain. If the workload accepts a bucket reference without verifying ownership, the control plane can be bypassed while the data plane still behaves normally from the application's point of view. See the T1530 Data from Cloud Storage Defensive Guide.
Practical implication: Review every ML and analytics workflow that auto-populates S3 destinations and require explicit owner validation before execution.
Threat narrative
Attacker objective: The attacker wants to intercept workload output, harvest sensitive data or inject code through a bucket that the victim application trusts by name.
- Entry occurs when the attacker claims a predictable S3 bucket name before the legitimate AWS workload or SDK creates it.
- Credential or data abuse follows when the service writes code, logs, query output or artifacts into the attacker-controlled bucket without validating ownership.
- Impact lands as remote code execution, silent data exfiltration or log capture, depending on which workflow is redirected.
Breaches seen in the wild
- Football Australia AWS keys exposure 2024: AWS keys hard-coded in a Football Australia web page reportedly opened 127 storage buckets of player and fan data; fixed within hours, no misuse confirmed.
- Twilio TaskRouter SDK compromise 2020: A bucket policy letting any AWS principal write let attackers swap Twilio's TaskRouter JS SDK for a malvertising version for about nine hours.
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
Half-patched remediation is its own vulnerability class: A fix that lands in one service, console or SDK does not close the attack if adjacent paths still resolve the same storage target. In cloud environments, remediation has to be measured against the actual call path, not the intent of the patch. If one branch still trusts a predictable bucket name, the exploit survives through that branch.
Predictable bucket naming creates an ownership illusion: When services auto-generate storage names from account or region metadata, they create a false sense that name resolution equals asset control. That is especially dangerous in workflows that carry executable code, logs or query results. The control gap is not storage availability. It is bucket ownership validation at the moment the workload chooses its destination.
The real failure is governance across the stack, not a single bad line of code: Account-namespaced buckets address the platform primitive, but SDK defaults, tutorials and copied deployment patterns can keep the old assumption alive. That means cloud governance has to cover documentation, libraries and runtime checks together. Practitioners should treat default bucket selection as a governed control surface, not a convenience feature.
This pattern belongs in the same threat family as storage hijack and data redirection: The attacker does not need to break identity at login when the application itself routes data into an attacker-owned destination. In identity terms, the workload is making an unsafe trust decision about a non-human target. That is a machine identity and authorization problem as much as it is a storage problem.
What this signals
Default bucket resolution is the control point that matters: If the library decides the storage target, then the security decision has already moved out of the service boundary and into code that many teams never review. The practical shift is to govern destination selection as part of workload authorization, not as a convenience setting.
Cloud teams should expect more research to focus on remediation gaps between platform changes and client libraries. That means inventorying default resource creation paths, documenting every implicit storage target and treating copied examples as part of the attack surface.
Where ML and analytics pipelines write to S3 automatically, the issue is not just data exposure. It is a trust decision about where non-human workloads are allowed to send output, and that decision needs ownership checks at runtime.
For practitioners
- Audit default bucket resolution paths Trace every SDK, CLI and service workflow that constructs S3 destinations automatically, then identify where the bucket name is derived from account ID, region or service defaults. See the Amazon S3 Security Guide.
- Enforce ownership checks on all S3 operations Require owner validation on create, write and read paths, including SDK branches that never call a bucket creation API. See the AWS Security Guide.
- Replace predictable storage names with explicit targets Remove implicit bucket naming from ML, analytics and logging workflows and pass uniquely named buckets that your account already owns. See the Cloud Storage Exposure Playbook.
- Review workload destinations, not just buckets Inventory EMR, SageMaker and Athena resources that reference S3 URIs and compare those references with owned bucket inventories.
Key takeaways
- S3 bucket squatting persists when cloud services and SDKs continue to trust predictable bucket names more than verified ownership.
- The research shows that partial fixes can leave the same attack path open across service, console and client-library layers.
- Defenders should focus on runtime ownership checks, explicit bucket targets and review of every workload that auto-selects storage destinations.
Related NHI Mgmt Group resources: Amazon S3 Security Guide · AWS Security Guide · Cloud Storage Exposure Playbook · T1530 Data from Cloud Storage Defensive Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Predictable S3 bucket defaults and weak ownership checks are cloud deployment weaknesses that expose non-human workloads. |
| NHI-05 — Overprivileged NHI | Workloads writing to attacker-owned buckets act with broader access than intended and can leak high-value output. | |
| Recommendation — Remove implicit bucket defaults and enforce owner validation wherever workloads resolve S3 destinations. Limit workload write scope so storage targets are explicit, owned and narrowly authorised. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Excessive trust in default storage paths expands the access available to a workload beyond what it should need. |
| Recommendation — Apply least privilege to storage destinations and deny writes outside approved account-owned buckets. | ||
| CIS Controls v8 | CIS-5 — Account Management | The vulnerability hinges on which account effectively controls the bucket and related workload resources. |
| Recommendation — Maintain authoritative ownership records for all bucket-backed workloads and revoke any unapproved dependency. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The described attacks use trusted cloud paths to collect credentials, logs or results and move them out through S3. |
| Recommendation — Map bucket squatting to credential access and exfiltration tactics and monitor for redirected storage flows. | ||
Key terms
- S3 Bucket Squatting: S3 bucket squatting is a takeover pattern in which an attacker claims a predictable bucket name before the legitimate workload uses it. The application then writes data, logs or code into the attacker-controlled bucket because it trusts the name instead of verifying ownership.
- ExpectedBucketOwner: ExpectedBucketOwner is a request setting that tells an object storage service which account should own the bucket or target. The service compares that value with the actual owner before completing the request, which helps prevent writes to a squatted or misdirected bucket.
- Shared Namespace: A shared namespace is a naming space where many tenants can create or claim identifiers from the same pool. In cloud storage and similar services, that means a bucket or resource name can be globally unique and exposed to takeover if ownership is not verified before use.
- Default Bucket Name: A default bucket name is the automatically chosen storage bucket name created or selected by a tool or SDK when the caller does not specify one. These defaults can be unsafe if they are predictable, reused, or not checked against the expected owner, because another party may claim the name first.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners connect workload identity controls to the broader access model their programmes depend on.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org