AWS patches S3 bucket flaw in Security Agent MCP server
A missing ownership check let attackers pre-register scan output buckets and collect private source archives, credentials and infrastructure state.
By The Agentic Times ·
Amazon Web Services has fixed a flaw in its Security Agent MCP server that could have handed private workspace archives to strangers. The vulnerability, tracked as CVE-2026-87913, was published in the US National Vulnerability Database on 10 September 2026. It affects all versions of the AWS Security Agent MCP server before 0.2.0.
According to the NVD entry, the server did not verify that it owned the Amazon S3 bucket it wrote scan output to. S3 is AWS's object storage service, and bucket names are global: once a name is taken in any account, nobody else can use it. The bucket name used by the tool was derived from a publicly known account identifier. That combination is the whole problem. An attacker who could work out the name in advance could register it in their own account first, and then simply wait for the victim's scan results to arrive.
The NVD record says the data at stake is the private source archive of a scanned workspace, including credentials and infrastructure state contained in that archive. In other words, the material a security scanning tool needs to see is exactly the material that could end up in someone else's storage. The entry describes the attacker as remote and does not require them to have any access to the victim's account.
MCP, the Model Context Protocol, is the interface standard that lets AI agents call external tools. The AWS Security Agent MCP server is one such tool, published by AWS Labs. Because MCP servers run with whatever permissions the surrounding agent and account grant them, a bug in how one handles storage can quietly reroute sensitive output without any user action.
The fix is to upgrade to version 0.2.0, which is available on PyPI. But the NVD entry carries an unusual second instruction, and it matters. Users should also check that the scan output bucket in their own account is actually owned by their account. Upgrading does not release a bucket name that a third party has already registered. If an attacker claimed the name before the patch, that claim survives the update. Anyone who ran an affected version needs to confirm ownership manually rather than assume the new release has cleaned up after them.
AWS has published a security bulletin for the issue, and AWS Labs has issued a GitHub security advisory, GHSA-3jxw-vj8m-8x77. The listed sources do not say whether the flaw was exploited in the wild, who reported it, or how many deployments were affected.
The pattern here is not new to cloud security, but it lands differently in an agent context. Predictable global names plus automated tools that write output without checking who owns the destination is a combination worth auditing across any MCP server that stores results in shared cloud namespaces.
Sources
- nvd.nist.govhttps://nvd.nist.gov/vuln/detail/CVE-2026-87913
