~/news/2026-09-10-aws-security-agent-bucket-ownership.md

What happened. On 2026-09-10 AWS published bulletin 2026-105-AWS for CVE-2026-87912 and CVE-2026-87913. The Security Agent plugin for aws-agents-for-devsecops up to 1.0.0 and the awslabs security-agent-mcp-server up to 0.1.5 uploaded a scanned workspace's source archive to an S3 bucket whose name they derived from the caller's account ID and Region. They checked that the bucket existed, not whose it was. Whoever registered that name first was handed the archive.

Why it matters. The scanner you buy for this class of mistake in your own estate shipped one. The payload was worth having: .env files, private keys, Terraform state. Account IDs are not secret, since ARNs and ECR URIs publish them, and S3 names are global, so the exploit is knowing a name and getting there first. AWS is blunt that upgrading does not release a bucket name a third party has already registered: the patch closes the door and says nothing about what walked through it.

Mechanism. The name was deterministic: security-agent-scans-<account-id>-<region>. The plugin confirmed the bucket existed, then wrote to it, treating a name nobody had visibly taken as one nobody else owned. The fix in aws-agents-for-devsecops 1.1.0 and security-agent-mcp-server 0.2.0 passes ExpectedBucketOwner on S3 operations and treats a bucket owned by another account as fatal, so ownership becomes something the API asserts rather than something inferred from a string. Reported by Nadav Claude Cohen at glow.io.

What to do. Upgrade, then do the half the upgrade cannot do: confirm that security-agent-scans-<account-id>-<region> in each of your accounts is owned by an account you control. If it does not exist, create it yourself before the first scan, so the name cannot be squatted later. If it exists and is not yours, assume every scan run from those accounts was disclosed and rotate what the archives held. A predictable name in a global namespace is a guessable target, and existence is not ownership.