The Signature Checked Out and the Audience Walked In: AWS API MCP Server Took Any Token From the Same Tenant
A bearer token answers two questions — who signed this and who is it for — and checking only the first turns every tenant neighbor into a legitimate user. CVE-2026-115413, published 27 October 2026 via AWS Security Bulletin 2026-152, is a missing audience check in the OAuth mode of the awslabs AWS API MCP Server: versions 1.3.0 through 1.5.x validate a bearer token’s signature, issuer, and expiry but never the claim naming the application the token was issued for. A local caller holding any token from the same identity provider — say, one issued to a second app client in the same Amazon Cognito user pool — is accepted, and from there can run AWS API calls with the server’s own configured host credentials. NVD rates it CVSS 7.8 (AV:L/PR:L); the upstream advisory scores 7.3 under CVSS v4. The fix is 1.6.0, which additionally requires operators to configure the expected audience or client ID — the secure setting is now the only setting.
Whose token is it anyway
The advisory (GHSA-4prq-p2x5-w9fh, crediting Yuval Elbar via coordinated disclosure) is precise about scope, and the precision matters. Only deployments serving the streamable-http transport with OAuth authentication are affected; the default stdio transport never sees a bearer token at all. Within that population, exploitation needs a local path to the server plus a low-privilege foothold — any token the nominated provider issued, to anyone, in the same tenant. That is a low bar inside exactly the environments where this server is most useful: shared hosts, dev boxes, and agent sandboxes where several applications share one Cognito pool and the MCP server carries the broadest AWS credentials on the machine. Impact is bounded by those host credentials — an attacker cannot exceed what the server itself may do — but “whatever the automation role allows” is routinely far more than “whatever the token owner allows,” which is the entire gap. AWS’s workaround for operators who cannot upgrade immediately is correspondingly blunt: drop back to stdio until 1.6.0 is in.
Audience blindness is the season’s theme
Step back and this is the third audience-identity failure in MCP-adjacent software in under two weeks. The official TypeScript SDK needed four fixes at once, audience confusion among them; OAuthLib’s CVE-2026-118669, briefed alongside this post, lets one client authorize as another; and this server’s own history rhymes — our July briefing on CVE-2026-16584 covered the same component running without its configured policy gate. The pattern is not that vendors skip authentication; it is that they authenticate the token and forget to authenticate the relationship — which issuer, which audience, which client, under which policy. Each check is individually boring; the missing one is always the one the attacker holds. For defenders, the durable lesson across all three is that token validation has five fields, not three, and “signature valid” is a sentence fragment.
What to do
- Upgrade to 1.6.0 and set the expected audience or client ID. The version both patches the check and makes the configuration mandatory — verify the setting is actually present, since pre-1.6.0 configs will not have it.
- If you cannot upgrade, switch to stdio transport. Per the advisory, that removes the affected surface entirely; do not merely restrict network access to the HTTP port.
- Scope down the host credentials. The blast radius of this class is whatever the server role allows — least-privilege on the automation credentials bounds every current and future token-validation miss.
- Audit forks and vendored copies. AWS explicitly calls out derivative code; an internal fork pinned at 1.5.x is still vulnerable after upstream moves on.
Sources: