Amazon Web Services published fixes on 10 September 2026 for two related vulnerabilities in its AI-powered Security Agent tooling. CVE-2026-87912 affects the Security Agent plugin in Amazon aws-agents-for-devsecops before version 1.1.0. CVE-2026-87913 affects the AWS Security Agent MCP server before version 0.2.0.
AWS says both flaws involve a missing ownership check for an S3 bucket whose name is derived from a publicly known AWS account identifier. A remote attacker who registered the expected bucket name first might receive a private source archive submitted for scanning. AWS warns that such an archive can include credentials and infrastructure state.
The bulletin is unusually clear about remediation: upgrade the affected component, then verify that the scan-input bucket is owned by the expected AWS account. An upgrade does not reclaim a bucket name that a third party already registered. Public CVE records independently confirm the affected versions, disclosure date and 5.9 CVSS score, but no public evidence establishes active exploitation or a count of affected users.
How the exposure path works
Security scanning often requires packaging source code and configuration into an archive, then moving that archive to a storage location the scanner can access. In this case, the vulnerable components used a predictable bucket naming pattern. They did not sufficiently verify that the resulting bucket belonged to the account that initiated the scan.
That creates a confused ownership boundary. The agent may be authorized to scan private code, but the destination receiving the archive may not be authorized to hold it. Because repositories can contain deployment files, environment references, secrets and infrastructure definitions, a destination mistake can turn a defensive workflow into a data-exposure path.
The issue affects both a plugin and an MCP server. That matters because MCP can make security tools easier for agents to invoke, but the protocol connection does not replace service-level authorization and resource ownership checks.
The patch is necessary but not sufficient
AWS lists version 1.1.0 as the fixed release for the aws-agents-for-devsecops plugin and version 0.2.0 for the Security Agent MCP server. Forked or derivative code also needs the relevant changes.
Administrators should not stop after updating packages. AWS says they should verify ownership of the scan-input bucket named with the security-agent-scans account and region pattern. If a third party already controls that name, installing the fixed version does not undo the earlier registration.
A controlled response should therefore include four checks:
- Identify every deployment and fork of both affected components.
- Confirm the installed version and the exact package source.
- Verify the owner, policy and access history of each scan bucket.
- Review whether sensitive archives were written to a bucket outside the intended account.
If exposure is plausible, teams should rotate affected credentials, inspect access logs and review downstream systems referenced in the archive. Those actions depend on local evidence. The AWS bulletin does not state that every vulnerable installation leaked data.
What agent security teams should learn
The flaw illustrates why tool-call validation cannot end with a syntactically valid request. A security agent can choose the right operation and still send sensitive material to the wrong resource. Runtime controls need to verify identity, ownership, scope and expected effect at the resource boundary.
For storage writes, the action envelope should include the target account, region, bucket identifier, object path, encryption requirements and retention policy. A pre-execution check should compare the resolved resource owner with the approved owner. A post-execution check should confirm that the archive landed only in the intended location.
Maetra's guide to prompt injection controls for AI agents describes the broader need to constrain tool use when agents handle untrusted inputs. The AI agent inventory checklist can help teams locate affected agents, repositories, tools and owners before remediation.
Evidence to retain
Teams should preserve package versions, deployment locations, bucket ownership results, policies, access logs, archive object histories, credential-rotation records and incident decisions. If a fork includes the vulnerable pattern, record the commit that removed it and the tests proving that an ownership mismatch now fails closed.
An audit record should distinguish vulnerability presence, exploitability, suspected exposure and verified access. Treating all four as the same state can create either false assurance or unnecessary incident escalation.
The AI audit evidence guide provides a structure for linking technical findings to owners, decisions and remediation proof.
Maetra analysis
These vulnerabilities sit at the intersection of AI security and ordinary cloud authorization. The failure was not that the agent chose a malicious task. It was that a trusted workflow lacked a decisive resource-ownership check before transmitting a high-value archive.
The durable fix is broader than upgrading two packages. Security-agent deployments should inventory every external effect, bind each effect to a verified resource identity and retain evidence that the intended state was reached. Teams should also test predictable-name collisions, cross-account resources and stale infrastructure assumptions before granting an agent wider authority.