One Parameter Read Another Account's SQL on AWS Athena

One Parameter Read Another Account's SQL on AWS Athena

6 min read

One field on an Athena API call returned the full SQL text that other AWS accounts had just run — and the account IDs that ran it. Not query results, but the values inside their INSERT statements and WHERE clauses, in plaintext. Those accounts had no relationship with the researcher’s account: no shared resource, no grant of any kind. A Claude agent found it overnight while left running against AWS. That is the September 8 disclosure from Act Security’s Oren Yomtov, and it compresses two arguments the site has been making for months into a single finding.

The agent did real reachable work

Before the architecture, the part that should change how you read this: an AI agent found a real, cross-customer, data-exfiltrating vulnerability by itself. Yomtov’s account is the agent version of setting something in motion before bed and waking up to a report. He asked Claude to hunt for vulnerabilities in AWS, went to sleep, and woke up to a serious disclosure. This is not a benchmark where the model was handed source code and a known CVE. It is an autonomous agent, pointed at a live black-box service, producing a finding that spans accounts.

That matters because agent security and offensive-agent capability are the same coin. The agent that found this was acting in the researcher’s account with his credentials and his network — exactly the position every agent platform wants to put its models in. The finding is concrete: active AWS customers were one API parameter away from reading each other’s recent query text on a managed service. When an autonomous agent can produce that from a prompt and a set of credentials, the question is no longer whether agents can do security work. The question is which trust boundary you are giving them.

The mechanism: Athena v3 is shared Trino, and system leaked across it

Amazon Athena is AWS’s serverless SQL service: point it at data in S3, query it without running a database, pay per query. The detail that makes this a cross-tenant flaw is that Athena’s version 3 engine is Trino, and Trino queries do not necessarily run on dedicated single-tenant infrastructure. They share the engine.

Trino ships a catalog named system, and inside it system.runtime.queries — a table that logs what ran recently on that infrastructure: query ID, submitting user, state, timing, and the full original SQL text. On a Trino cluster you own, that table is diagnostics: it is how you find the query eating your workers. On Athena, queried cross-tenant, it is a read of every other account on the shared engine.

A catalog name arrives in two places. Put system in the SQL text and Athena refuses it — StartQueryExecution answers “Queries of this type are not supported” and returns no execution ID. But StartQueryExecution also takes a separate QueryExecutionContext parameter holding Database and Catalog, the field that resolves unqualified table names. Leave the catalog out of the SQL and pass Catalog=system there instead, and the query runs.

The validation checked one path and not the other. That asymmetry — the same intent expressed through a second channel bypassing the gate — is a classic cross-tenant boundary failure, and it is exactly the class of bug the site flagged with localhost-as-an-auth-boundary and with approval-gate bypasses. The trust boundary that failed was not IAM, not a blocklist on catalog names, but a single unvalidated parameter in an API the shared engine trusts.

What came back

The researcher’s team read other accounts’ SQL statement text and the account IDs that submitted it. To confirm what those statements contained without reading any stranger’s actual query, they counted pattern matches inside the engine and returned only the integers. Across 200 query landings they saw 2,794 rows, and 2,590 of them belonged to other accounts — 92.7% of what leaked was cross-tenant.

This was not a rare race. 102 of 109 landings returned at least one other account’s row, and one landing held 43 distinct identities. system.runtime.queries also keeps roughly an hour of history, not a moment: in the round where age was measured, 41% of the other accounts’ rows were 15 minutes old or older, and the oldest was about 54 minutes old.

Disclosure: fast, global, no customer action

Act Security reported the finding to AWS on 6 August 2026. AWS answered the same day and opened a review. On 8 August the call stopped working. By 10 August AWS completed the fix in every Region, and Act retested in every enabled Region — the block held in all of them. AWS assigned no CVE, because AWS reserves CVEs for cases where a customer has to act, and here nobody outside AWS had anything to install or change.

What operators should change

This one belonged to AWS and AWS closed it. But it is a clean place to reinforce three standing rules for agent platforms and cloud tenants:

  1. Treat every second input channel as a trust boundary, not the one you documented. The Catalog=system bypass worked because the SQL-text validation did not extend to the API parameter that resolves unqualified names. When you build an agent that calls APIs, audit whether an equivalent intent can be expressed through a parameter, a config file, an env var, or a query-string field you do not validate. The bug was a validation gap, not a permission gap.

  2. The client-side “gotcha” is that you cannot protect yourself here — and that is the point. No customer-side configuration, IAM policy, or blocklist would have changed this outcome. The boundary that failed was inside a shared managed service. The only defense is a vendor that does the hard work of validating every channel on shared infrastructure — and, for the data most at risk, the reminder that a non-dedicated serverless engine that returns query text is only as private as the engine’s internal isolation. If a workload cannot tolerate even a single cross-tenant SQL-through-catalog read, consider whether a shared-engine serverless service is the right substrate for it.

  3. Give your agents credentials that match their reach, and audit what they touch while unsupervised. The capability the agent demonstrated (autonomous, overnight, black-box vuln discovery on a live service) is the same capability that, pointed outward or given too much scope, becomes the incident. Least-privilege, approval gates, and a clear trust boundary around the agent’s environment are not optional hardening — they are the difference between an agent that finds a reproducible cross-tenant bug and an agent that becomes one.

The closing thesis is simple. AWS’s own infrastructure trusted a shared Trino catalog boundary that a single unvalidated parameter could cross, and an autonomous agent found it before any human did. Framing AI agents only as a downstream security risk is incomplete: agents are also upstream — they are the instruments now finding the reachable, cross-tenant, plaintext-data bugs that blocklists and happy-path validation have been missing for years. The leak got fixed in four days. The lesson — that the second input channel is the trust boundary, and that the agent both creates and discovers these — does not get patched.

Sources:

Keep reading

The Pin Was a Label, Not a Check: How Plugin4Shell Walked Past SHA Pinning in Four Coding Agents The Exploit Ships in .git/config When the Agent Can Turn Off Its Own Cage: The DeepSeek Harness Sandbox Escape