Intelligence
Join the waitlist
AEW-042

Existence of a predictably named destination is treated as ownership of it

A system names the destination it writes consequential data to from information about the caller that is public rather than secret, then checks only that a destination bearing that name exists and is reachable, never that the caller's own account actually owns it.

Status: publishedExecution AuthorityEnvironment Boundaries

Description

This weakness appears at the point a system computes, rather than is handed, the identifier of a destination it is about to write consequential data into: an account id, a region, or another observable value goes in, and a bucket, queue, topic or similar addressable resource name comes out, deterministically and with no random or secret component. The system's own check before writing then asks only whether a destination bearing that computed name exists and can be reached, never whether the account or principal holding it is the same one the caller is acting for. A third party who can observe the same public inputs, most often because they are the caller's own publicly known account identifier, can compute the identical name and register it first, in a resource of their own, before the legitimate caller ever does. Every subsequent operation that derives the same name from the same public inputs keeps writing to the third party's pre-registered destination, because the existence check the system performs continues to pass regardless of who actually holds what it found. It differs from reachability treated as authority (AEW-008): AEW-008's own mechanism is an environment or network boundary that never constrains a target at all, so anything reachable is actionable; here a check does run and does constrain the destination to a specific computed name, and the gap is that the check verifies existence under that name rather than ownership of it. It differs from authority over a destination treated as authority over the source that fills it (AEW-018): AEW-018's own mechanism is a two sided transfer where one side, the destination, is genuinely confined and the other, the source, receives no location check at all; here there is one side, the destination itself, and the single check that runs answers the wrong question about it rather than one side going unchecked while the other is correctly confined. The corrective is to bind the destination to the caller's own account with an explicit, independently enforced ownership assertion checked at the moment of write, never to infer ownership from a computed name resolving to something that exists.

The authority gap

The authority required is that the destination the system is about to write into actually belongs to the account the caller is acting for. The authority presented is that a destination bearing the expected, predictably derived name exists and is reachable, and existence under a name the system itself computed from public identifiers is treated as though it had settled ownership too.

Failure conditions

  • A system derives the identifier of a destination it will write consequential data to from information about the caller that is public or otherwise observable, with no random or secret component.
  • The system's own check before writing confirms only that a destination bearing that derived name exists and is reachable, not that the account holding it is the caller's own account.
  • Nothing independent of the derived name itself, such as a cloud provider's own explicit bucket owner condition asserted and enforced at write time, binds the destination to the caller's own account.

Consequences shown by the evidence

  • A third party who can compute the same predictable destination name from public information registers it first, in a resource they control, before the legitimate caller ever does.
  • Every subsequent legitimate operation that derives the same name keeps writing to the third party's pre-registered destination undetected, because the system's own existence check continues to pass.
  • Content meant to stay private, source archives, credentials and infrastructure state included, lands in an account or resource the intended owner never controlled and was never asked to trust.

Detection signals

  • A destination identifier, a bucket, queue or topic name, is computed deterministically from an account id, a region or another publicly observable value, with no random or secret component anywhere in the derivation.
  • The code path that uploads or writes to that destination checks only that it resolves or exists, with no provider level ownership condition asserted and enforced at the same call.
  • A vendor's own remediation for a defect of this shape states that upgrading alone does not fix an already affected deployment, because the destination's own name, not only the code that computed it, was what a third party compromised.

Known examples

  • GitHub Security Advisory GHSA-2px6-hhjp-3g5x, formally assigning CVE-2026-87912 on 10 September 2026 and fetched directly by this record, documents the AWS Security Agent plugin (aws-agents-for-devsecops, through version 1.0.0) deriving the name of the S3 bucket a scanned workspace's archive is uploaded to from the customer's own account id and region, and checking only that a bucket bearing that name exists, never that it belongs to the customer's own account. An attacker who computes the same name from a target's public account id and registers it first, in an account of their own, receives the target's own subsequent scan uploads, source archives, files such as .env and private keys, and infrastructure state included. Fixed in version 1.1.0, which this record confirmed directly adds bucket ownership verification on every S3 operation.
  • GitHub Security Advisory GHSA-3jxw-vj8m-8x77, formally assigning CVE-2026-87913 the same day and fetched directly by this record, documents the identical mechanism in a second, distinct component of the same product, the AWS Security Agent MCP server (awslabs.security-agent-mcp-server, versions 0.1.0 through 0.1.5), deriving bucket names from caller account ids and regions with the identical missing ownership check. Fixed in version 0.2.0, which this record confirmed directly implements ExpectedBucketOwner parameter validation and enforces ownership checks before upload operations, treating a foreign owned bucket as a fatal error. Both advisories, published by AWS the same day and credited to the same reporter, Nadav Claude Cohen of glow.io, name upgrading alone as insufficient: a bucket name a third party already registered under the old, unverified logic is not released or reclaimed by either fixed version, which is why AWS's own remediation guidance separately asks customers to verify that their own scan output bucket is actually owned by their own account.

Protocol evidence

Published authority architectures whose artifacts bear on the requirement this weakness names: which satisfy it, which expose a way past it, and which leave it unanswered.

  • No protocol change

    Agent Control Standard (ACS)

    OWASP GenAI Security Project, originally Zenity

    ACS's own conformance document addresses whether a consequential action reaches an independent mediation point at all; the AWS Security Agent plugin's and MCP server's own S3 upload paths are not that kind of gap. A check genuinely ran before every upload, confirming that a bucket bearing the derived name existed and was reachable, and the defect is that this check answered a different question from the one that mattered, existence rather than ownership, not that no check ran at all. Nothing in the material available to this session states or implies a requirement, of ACS's or of any other protocol draft this registry currently holds, that would have engaged differently here: the fix AWS shipped, ExpectedBucketOwner parameter validation, is a provider specific destination ownership assertion, not the adoption of a new mediation, delegation or containment requirement this dataset's protocol material already covers in the abstract. Recorded as no change rather than supporting or missing evidence for any specific protocol requirement.

    View protocol evidence