AWS has patched an authorization vulnerability in its open-source AWS API MCP Server that could allow a local caller to make cloud API requests using credentials configured on the server’s host.

Tracked as CVE-2026-115413, the flaw affects versions 1.3.0 through versions before 1.6.0. AWS published its bulletin on 27 October 2026 at 11:30 pm IST. This is follow-up coverage of that disclosure, not a newly announced incident.

A valid token for the wrong application

The AWS API MCP Server connects AI assistants to AWS services through AWS CLI commands. As our MCP explainer describes, the protocol connects agents to external tools and data.

According to the maintainer advisory, affected OAuth configurations checked a token’s signature, issuer and expiry but did not verify the claim identifying the application it was issued for. Consequently, a token issued to another application within the same configured identity-provider tenant could be accepted.

The advisory gives a second application client in the same Amazon Cognito user pool as an example. A local caller holding such a token could reach the server and invoke AWS APIs using its host-configured credentials, within those credentials’ permissions.

Not every deployment is affected

The disclosed issue applies specifically to deployments combining the streamable-HTTP transport with OAuth authentication. The default stdio transport is outside the affected configuration.

The prerequisites matter. This is not a disclosure that any unauthenticated internet user could access every AWS account. The advisory specifies a local caller with a valid token from the configured tenant and rates the vulnerability High, with a CVSS 4.0 score of 7.3.

“Host-level cloud permissions” also needs careful interpretation. The disclosed consequence is AWS API access under the host’s configured identity. It does not, by itself, establish operating-system administrator access, stolen credential material or permissions beyond that identity’s existing limits.

The reviewed AWS and maintainer disclosures do not report confirmed exploitation or identify compromised customers. That is a limitation of the public evidence, not proof that exploitation never occurred.

Updating requires checking configuration

AWS identifies version 1.6.0 as the fix and recommends upgrading to the latest version, including patching forks or derivative code. Operators unable to upgrade immediately can use the default stdio transport instead of streamable HTTP.

The patched package’s documentation requires OAuth deployments to configure an expected audience or client ID. AUTH_AUDIENCE validates the token’s aud claim.

AUTH_CLIENT_ID supports providers whose access tokens identify the application through client_id or azp, including the documented Cognito case. If both settings are configured, both claims are validated. The 1.6.0 package is available on PyPI.

Why this matters for agent infrastructure

The broader lesson is that a genuine, unexpired token is not necessarily valid for every service trusting its issuer. MCP’s authorization specification explicitly requires servers to verify that tokens were issued for their intended use.

For agent operators, our analysis is that two boundaries deserve separate attention: which callers can invoke a tool server, and what cloud authority that server holds. A failure at the first boundary can expose the capabilities granted at the second. This distinction also runs through our coverage of agent identity controls and cross-cloud containment.

Alongside the vendor-prescribed update, teams should review the AWS identity assigned to their agent infrastructure and whether its permissions exceed the workflow’s needs. That is a defense-in-depth recommendation, not a substitute for correcting token validation.

What we would test

In an isolated tenant with synthetic resources and narrowly scoped test credentials, our proposed test would compare an affected deployment with a patched, correctly configured deployment. It would check whether a valid token issued for another application is rejected before any AWS operation executes, using a correctly targeted token as a control. No such testing has been performed by AgentsCalling.

About Puneet Sharma

Puneet Sharma

Puneet Sharma · Freelance Writer

Puneet Sharma is a freelance writer covering AI agents, automation and the software changing how we work. His coverage at AgentsCalling starts with the questions a reader might ask over a conversation: What does this tool actually do? Where does it fall short? And is it useful beyond the demo? His articles explore new launches, practical workflows and the trade-offs behind giving software more responsibility, with explanations that make room for readers who are still getting familiar with AI.

More articles by Puneet Sharma