TL;DR: aws-sdk-pandas still let Athena query results land in attacker-owned S3 buckets because its default bucket logic recreated a known squatting pattern and never verified ownership, according to Upwind. The same gap also enabled CTAS manifest hijacking, so result reads could be poisoned as well as stolen.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Upwind's research: Athena query defaults in aws-sdk-pandas could write results into attacker-owned S3 buckets and enable CTAS manifest poisoning, turning a service fix into an unresolved SDK-level exposure.
Why it matters: IAM, cloud storage ownership, and data integrity controls all matter here because a predictable bucket name can become a silent exfiltration path unless ownership is verified at write time.
Context
Athena result handling depends on S3 bucket ownership, not just on query execution. When a client library creates a predictable default destination and accepts any bucket that matches the name, the control shifts from access governance to assumption, which is where the security gap opens.
This is a cloud data governance problem with a clear identity angle: the bucket owner is part of the trust decision, and the SDK failed to confirm it before using the destination. The pattern is atypical in healthy Athena deployments because the safe default should fail closed, not proceed silently.
Key questions
Q: How do I prevent Athena query results from writing to the wrong S3 bucket?
A: Set an explicit Athena S3 output location for every workgroup and query, then restrict the bucket policy so only the intended account and role can write there. Also enable expected bucket owner checks, use separate buckets per environment, and remove any writable default destination that could be claimed by another account.
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: How does CTAS manifest hijacking affect Athena result integrity?
A: CTAS manifest hijacking targets the manifest file that Athena uses to record objects created by a CREATE TABLE AS SELECT query. If an attacker can influence the manifest location or contents, downstream readers may trust the wrong result set, so result integrity depends on locked-down S3 paths, write permissions, and owner validation.
Q: What should teams do first after discovering bucket squatting exposure?
A: First, identify every query workgroup, default S3 destination, and bucket policy that could accept the writes, then revoke public or cross-account write access. After that, move to fixed output locations, enable expected bucket owner checks, and review any queries that may already have written results to a squatted bucket.
Technical breakdown
How predictable Athena result buckets become a trust boundary
aws-sdk-pandas falls back to a default Athena result bucket when no explicit output location is provided. That bucket name is deterministic, so any account that can predict the victim account ID and region can pre-create the same name and wait for the client library to use it. The security problem is not Athena query execution itself, but the assumption that a matching bucket name implies the intended owner. When a library treats bucket existence and bucket ownership as interchangeable, it converts name resolution into a trust decision.
Practical implication: Treat deterministic output locations as security-sensitive inputs and require ownership validation before any read or write path proceeds.
Why BucketAlreadyExists must not be handled like a safe retry
The critical bug is the identical handling of BucketAlreadyExists and BucketAlreadyOwnedByYou. The first means an attacker already owns the bucket, while the second means the caller does. Swallowing both exceptions and proceeding removes the only signal that distinguishes safe from unsafe bucket resolution. In AWS data workflows, that distinction matters because the library is not just choosing a path, it is choosing where sensitive query output is delivered. A debug log cannot substitute for a hard ownership check.
Practical implication: Fail closed on ownership ambiguity and require explicit expected-bucket-owner checks on all S3 destinations.
How CTAS manifest hijacking changes result integrity
CTAS workflows add a second layer of exposure because Athena writes a manifest that tells the client which Parquet files to read back. If an attacker controls the bucket, they can replace the manifest or point it at altered files before the victim consumes the result. That turns a query-result channel into a data-integrity channel, where the victim may receive modified rows or injected columns while the original output still appears normal. The weakness is not the query engine but the absence of manifest integrity validation and bucket ownership enforcement.
Practical implication: Validate result manifests and the bucket owner before deserializing any CTAS output.
Threat narrative
Attacker objective: Steal Athena query outputs at scale and, where possible, tamper with the data pipeline so victims consume attacker-modified results.
- Entry occurs when the victim uses aws-sdk-pandas with Athena and accepts the library's deterministic default S3 output location.
- Credential or trust abuse follows when the attacker pre-creates the matching bucket in a separate AWS account and relies on the library's missing ownership check.
- Impact arrives as silent query-result exfiltration or CTAS manifest hijacking, allowing the attacker to read data or alter what downstream systems consume.
Breaches seen in the wild
- Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
- 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.
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
Predictable storage destinations create a governance failure, not just a coding bug. Once a client library decides where sensitive query output goes by constructing a name that an attacker can preempt, the bucket owner becomes part of the security model. That means the trust decision has moved out of the service and into the SDK, where it is easier to miss. Practitioners should treat deterministic cloud storage paths as identity-bound trust boundaries, not convenience defaults.
The real control gap is ownership verification at write time. Bucket existence is not a permission signal, and a matching name does not prove the destination is safe. This is where cloud governance and NHI discipline meet: the system is effectively handing data to whichever principal controls the bucket first, so the platform must confirm the intended owner before any Athena result is committed.
CTAS output handling needs integrity controls, not just availability controls. Query-result pipelines are often assumed to be read-only and ephemeral, but CTAS introduces a writable manifest that can redirect downstream consumption. That makes the data plane vulnerable to tampering even when the original query still succeeds. The named concept here is result destination trust collapse: when a predictable output path, missing ownership check, and mutable manifest combine to erase the boundary between intended and attacker-controlled storage.
This pattern validates why service-side remediation is not enough when client libraries replicate the same logic. The cloud provider may patch one path, but if the SDK reimplements the old behavior, the exposure survives in practice. Identity and access governance has to extend to the tools that construct destinations and consume storage metadata, not only to the service enforcing the query itself.
For security teams, this is a reminder that exfiltration often begins as a control-assumption mismatch. The attacker does not need to break authentication to succeed here. They need only exploit the gap between what the service assumed had been fixed and what the SDK still did with bucket ownership.
From our research library:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
- Read next: Data Exfiltration Playbook
What this signals
Result destination trust collapse: predictable output paths can erase the security distinction between intended storage and attacker-controlled storage when ownership checks are missing. That means the control has to move earlier, to destination validation and ownership enforcement, before any query result is written.
Athena-style result handling shows how a patched service can still leave client-side exposure behind when SDK logic recreates the old behavior. Teams should watch for libraries that duplicate cloud service naming conventions without duplicating the service's ownership checks, because that is where silent exfiltration paths survive.
The operational signal is simple: if a data pipeline trusts the bucket name more than the bucket owner, it is already depending on a broken assumption. Once that assumption exists, manifest validation, explicit output configuration, and result-path monitoring all become necessary rather than optional.
For practitioners
- Explicitly set Athena output locations Do not rely on library defaults for Athena query results. Require every workflow to specify an owned S3 output bucket and reject executions that fall back to a predictable name.
- Enforce expected-bucket-owner checks Validate the bucket owner before any Athena result write or read path proceeds, including CTAS workflows that consume manifests and Parquet files.
- Harden workgroup configuration Set Athena workgroups to enforce configuration and use an explicit ResultConfiguration output location so client-side fallbacks cannot override the approved destination.
- Monitor for suspicious default bucket creation Alert on creation or access patterns involving aws-athena-query-results-{account_id}-{region}, especially when the bucket appears before legitimate first use.
- Upgrade the SDK and re-test result handling Move to aws-sdk-pandas v3.16.1 or later, then verify that ownership validation and manifest integrity checks are active in your Athena paths.
Key takeaways
- Predictable Athena result buckets can become an exfiltration channel when client libraries do not verify who owns the destination.
- The same trust gap can also undermine data integrity through CTAS manifest manipulation, not just leak query output.
- Ownership validation, explicit output locations, and manifest checks are the controls that would have limited this exposure.
Related NHI Mgmt Group resources: Data Exfiltration Playbook · Codefinger S3 ransomware 2025 · Football Australia AWS keys exposure 2024 · Twilio TaskRouter SDK compromise 2020
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Predictable bucket defaults and missing ownership checks are a cloud access misconfiguration analogue. |
| Recommendation — Harden destination handling so storage defaults cannot bypass ownership verification. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Bucket ownership is the authorization decision that the SDK failed to enforce. |
| Recommendation — Verify entitlements before any Athena result is written to or read from S3. | ||
| CIS Controls v8 | CIS-5 — Account Management | The attack depends on account-level control of a predictable storage target. |
| Recommendation — Review account ownership assumptions for shared cloud storage destinations and revoke unsafe paths. | ||
| MITRE ATT&CK | TA0009;TA0010 — Collection; Exfiltration | The attack chain is built around collecting query output and exfiltrating it through attacker-owned storage. |
| Recommendation — Map predictable-result-bucket exposure to collection and exfiltration tactics in detection content. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM governance must include ownership checks for service-created storage targets. |
| Recommendation — Apply cloud IAM governance to enforce ownership validation on service-generated storage paths. | ||
Key terms
- Athena: Athena is a serverless SQL query service for analysing data stored in object storage. Users submit SQL queries against files without provisioning database servers, and access is controlled through IAM permissions, query workgroups and the underlying data location.
- CTAS Manifest: CTAS Manifest is the file Athena writes to describe the objects produced by a CREATE TABLE AS SELECT query. It is used by downstream processes to locate and trust the result files, so control of the manifest path or contents can affect result integrity and object handling.
- S3 Bucket Squatting: S3 Bucket Squatting is the practice of creating or claiming an Amazon S3 bucket name that someone else expected to use. Because bucket names are globally unique, predictable names can be taken over and then receive unintended writes or data.
- ExpectedBucketOwner: ExpectedBucketOwner is an S3 request condition that checks the AWS account ID that owns the target bucket. If the owner does not match, the request fails, which helps stop cross-account writes to a bucket with a guessed name.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps security and identity practitioners connect access governance to the broader control plane 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