MCPStore.nl

Published:

AWS patches its own MCP servers and agent tools: API MCP Server accepted tokens meant for other apps

In short: between 1 and 28 October 2026, AWS published five security bulletins for its own MCP servers and its Strands agent tooling. The most important (CVE-2026-115413, 27 October): in OAuth mode, the AWS API MCP Server did not check which application a token was issued for. Version 1.6.0 fixes it and requires you to configure the audience. The managed AWS MCP Server was fixed on AWS's side.

AWS publishes a broad set of open-source MCP servers in the awslabs/mcp repository and also runs a managed AWS MCP Server. Both are listed in our cloud and infrastructure directory. In October, five entries in the AWS security bulletin feed concerned MCP servers or agent tooling directly. The most severe one, CVE-2026-115413, is not on CISA's list of known exploited vulnerabilities.

What went wrong in the AWS API MCP Server?

The AWS API MCP Server lets an AI assistant call AWS APIs using the AWS credentials configured on the host. Since version 1.3.0 it can run over the streamable-http transport, with OAuth authentication against an identity provider of the operator's choice. According to the GitHub advisory (GHSA-4prq-p2x5-w9fh), the server checked each token's signature, issuer and expiry, but not the claim identifying which application the token was issued to.

The result: a token the same identity provider issued to a different application in the same tenant was accepted too. The advisory's example is a token for a second app client in the same Amazon Cognito user pool. A local caller holding such a token could run AWS operations with the server's credentials, limited only by what those credentials allow.

What were the other bulletins?

Why does this matter for organisations?

The API MCP Server is effectively a key ring: it makes AWS calls with whatever permissions you hand it. An access-control flaw therefore lands directly in your cloud environment. The pattern is not new either. Earlier this month we covered security advisories for the official MCP SDKs, where audience validation was also a recurring theme. If you run a remote MCP server with OAuth, whether self-built or from a vendor, verify that check explicitly.

The Strands bulletins carry a second lesson: an agent should never decide on a security setting itself. As soon as the model can set a parameter like "mask secrets: yes/no", so can a prompt injection.

Our advice

(1) If you run awslabs.aws-api-mcp-server with streamable-http and OAuth: upgrade to 1.6.0, set AUTH_AUDIENCE or AUTH_CLIENT_ID, and review in CloudTrail which calls the server made since version 1.3.0. (2) Give such a server's credentials minimal IAM permissions, never admin rights. (3) If you run Strands agents: upgrade SDK and tools, and rotate keys if the environment tool was loaded. (4) For every remote MCP server, including from major vendors, ask how tokens are validated. More in MCP security and build an MCP server.

The bigger picture: AWS disclosing flaws in its own MCP tooling with CVE numbers and clear upgrade steps is mature behaviour. It also shows that "official, from the cloud vendor" does not mean you can skip configuration: the 1.6.0 fix only protects you once you actually set the audience.

Sources

Frequently asked questions

Which version of the AWS API MCP Server is safe?

Version 1.6.0 of awslabs.aws-api-mcp-server (27 October 2026). Versions 1.3.0 up to 1.6.0 are affected, and only when using the streamable-http transport with OAuth. After upgrading, OAuth deployments must set AUTH_AUDIENCE, or AUTH_CLIENT_ID for providers such as Amazon Cognito.

Do I need to do anything for the managed AWS MCP Server?

No. AWS says the run_script sandbox flaw (CVE-2026-115845) was fixed service-side and no customer action is required. According to the bulletin, code could only run inside the user's own isolated session.

What is token audience validation and why does it matter?

An OAuth token carries a claim stating which application it was issued for (the audience or client ID). If a server only checks signature, issuer and expiry, it also accepts tokens the same identity provider issued for a completely different application. Anyone holding such a token can then reach a server they were never granted access to.

Last updated: