The Bucket Existed. AWS Never Checked Who Owned It.

A name is not a claim of ownership, even when a system computes it correctly. Two advisories AWS published on the same day, against two different components of the same product, state that same distinction plainly, in AWS's own words, after building both components to derive a private destination's name from public information and never once asking who actually held it.

What the advisories themselves state

GitHub Security Advisory GHSA-2px6-hhjp-3g5x, fetched directly by this session, formally assigns CVE-2026-87912 on 10 September 2026 against the AWS Security Agent plugin in the aws-agents-for-devsecops package, versions through 1.0.0, corrected in 1.1.0. Its own description states that the plugin failed to verify bucket ownership when uploading source code archives to S3, and that an attacker could pre-register a predictably named bucket in their own account using a target's public AWS account id. Its own stated consequence: uploaded archives containing credentials, such as .env and private key files, and infrastructure state would be disclosed to the attacker. Severity is Moderate, CVSS 4.0 base score 5.1, vector AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N, weaknesses CWE-283, Unverified Ownership, and CWE-341, Predictable from Observable State. The advisory credits Nadav Claude Cohen of glow.io.

GitHub Security Advisory GHSA-3jxw-vj8m-8x77, also fetched directly, formally assigns CVE-2026-87913 the same day against a distinct package, awslabs.security-agent-mcp-server, the MCP server AWS ships alongside the plugin, versions 0.1.0 through 0.1.5, corrected in 0.2.0. Its own description states the mechanism in near identical terms: the server derives bucket names from caller account ids and regions without verifying ownership, and an attacker can pre-register the predictable name in their own account and intercept uploaded workspace archives containing credentials and infrastructure data, needing only the target's public account identifier. Same severity, same CVSS vector, same pair of weaknesses. Same credited reporter, Nadav Claude Cohen of glow.io, through what reads as one coordinated disclosure covering both components at once rather than two independent findings.

The fix names the check that was missing

Both advisories describe the same corrective mechanism. The plugin's own advisory states version 1.1.0 addresses the issue by verifying bucket ownership on all S3 operations, and recommends users pre create their scan input bucket as a precautionary measure. The MCP server's own advisory is more specific about the mechanism: version 0.2.0 implements ExpectedBucketOwner parameter validation and enforces ownership checks before upload operations, treating foreign owned buckets as fatal errors. ExpectedBucketOwner is Amazon S3's own API parameter for exactly this problem, a caller supplied account id that S3 itself checks against the bucket's actual owner before the operation proceeds, refusing the call if they do not match. Before this fix, per both advisories' own account, no such assertion existed anywhere in either component's own upload path: the only gate was whether a bucket bearing the computed name could be found and written to at all, a check a bucket registered by anyone, in any account, satisfies identically.

Why a version upgrade alone does not finish the remediation

The originating signal this record processes states a fact neither advisory needs to restate for it to matter: upgrading does not fix an already captured bucket name. That follows directly from the mechanism both advisories describe rather than from any separate claim. The corrected code can refuse, at the moment of upload, to write into a bucket it does not own once ExpectedBucketOwner is set and enforced. It cannot reach backward and un-register a bucket a third party already claimed under the same predictable name before the customer ever upgraded. A customer who was exposed under the old, unverified logic and then upgrades to 1.1.0 or 0.2.0 gains a component that will now correctly refuse to write into the attacker's bucket, a real and material improvement, but the attacker's own registration of that name does not expire or get reassigned by AWS shipping a new release. That is why AWS's own remediation guidance asks customers to separately verify that the scan output bucket in their own account is actually owned by their own account, a distinct, per deployment check no code upgrade performs on a customer's behalf.

The Authority Provenance ledger

Authority grantor. AWS, through the affected component's own design, which is meant to write a scanned workspace's archive only into a bucket the calling customer's own account controls.

Caller identity. The AWS Security Agent plugin or MCP server, acting with the customer's own configured AWS credentials during a scan the customer initiated.

Caller mandate. Upload the scan's output archive to the customer's own scan output bucket, and to that bucket alone.

Intermediary. The component's own bucket resolution logic, which computes a destination name from the customer's account id and region and checks that a bucket bearing that name exists and is reachable.

Intermediary credential. The customer's own AWS credentials configured for the plugin or the MCP server, whatever S3 write access those credentials separately carry.

Downstream target. An S3 bucket bearing the derived, predictable name, pre registered by an attacker in an account the attacker controls rather than the customer's own.

Failed limit. Named directly by both advisories: no assertion anywhere in the pre fix upload path required the destination bucket to belong to the calling account, only that a bucket bearing the computed name existed.

Inherited assumption. That a bucket name computed deterministically from the customer's own account id and region would, in practice, only ever be registered by that same customer, an assumption CWE-341's own classification, predictable from observable state, states is unsound the moment the inputs to that computation are public.

Credential binding. Absent for the destination: the customer's own credentials authorized the write operation itself, but nothing bound the destination bucket to the customer's own account before the write proceeded.

Destination binding. Absent before the fix, per both advisories' own account; present and enforced from version 1.1.0 and 0.2.0 onward, through S3's own ExpectedBucketOwner parameter.

Challenge authority. None on the application layer before the fix; S3's own ExpectedBucketOwner check is the challenge authority the fix introduces, refusing the operation the instant the resolved bucket's actual owner does not match the caller's own account id.

Revocation or modification. Shipped. Version 1.1.0 for the plugin and version 0.2.0 for the MCP server, both confirmed directly by this record against the advisories' own patched version fields, published the same day as the advisories themselves, 10 September 2026.

Recovery path. Upgrade to the corrected version, per both advisories' own stated remediation, and separately verify that the scan output bucket in the customer's own account is actually owned by that account, since the version upgrade alone does not release, or reclaim, a bucket name a third party had already registered.

Exploitation. Unknown. Neither advisory states that this was exploited against a real customer, and nothing available to this record establishes an exploitation count or an affected customer count; both remain exactly as unestablished as the originating signal states them.

Provenance evidence quality. Strong for both advisories' own stated facts: this session fetched GHSA-2px6-hhjp-3g5x and GHSA-3jxw-vj8m-8x77 directly, rather than through a summary, and confirmed the CVE ids, the shared CWE pair, the shared CVSS vector, the affected and corrected version boundaries for each distinct package, and the shared credited reporter. Weaker for AWS's own first party framing of the same event: direct fetch of aws.amazon.com's own Security Bulletin 2026-105-AWS, the source named in the originating signal, was blocked by this session's network egress policy on every attempted route, consistent with this desk's prior experience fetching other AWS security bulletins directly in this same period. This record relies on the GitHub Security Advisory Database's own two records instead, graded verified, and does not attribute to AWS's own bulletin page any wording this session did not itself read there.

Where this sits in the pattern

This is not the first time this desk has recorded AWS's own security tooling shipping a check that works on one dimension and is silently trusted to have covered a second, separate one. A companion record on this desk already found AWS Labs' own postgres-mcp-server enforcing read only mode through a blocklist that, in its own words, was never meant to be a complete security boundary, and a further record found amazon-ssm-agent's own S3 download path joining a caller influenced object key into a destination path with a function that never checked whether the result stayed inside it, while a correctly containing sibling function already existed in the same file. Here the shape is different again: the check that ran, does a bucket bearing this name exist and can I reach it, was not incomplete or misapplied so much as answering an entirely different question from the one that mattered, does the account I am about to trust with a private archive actually belong to the customer I am running this scan for. Existence and reachability are the same substitution this desk's own AEW-008, reachability treated as authority, already names in general form. What sharpens past that general form here, evidenced newly and directly by this pair of AWS advisories, is a destination whose very name is computed from information anyone can observe, so an attacker never needs to find or guess anything: the target's own public account id hands the attacker the exact name to register first, in an account of their own choosing, before the legitimate customer ever runs a scan.

What this record does not establish

This record does not claim CVE-2026-87912 or CVE-2026-87913 has been exploited against a real customer, that any specific attacker controlled bucket has been identified, that every customer running an affected version was necessarily exposed, or that AWS's own Security Bulletin 2026-105-AWS states anything beyond what the originating signal and the two GitHub Security Advisories this record fetched directly already establish. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from the pattern its own companion records already establish for other AWS tooling.