{
  "question": "We run the AWS API MCP Server over streamable HTTP with OAuth against our Cognito user pool. Could a token our identity provider issued to a different app get in, which version fixes it, and what do we have to configure after upgrading?",
  "slug": "can-an-oauth-token-issued-to-another-app-reach-the-aws-api-mcp-server-cve-2026-115413",
  "url": "https://www.rightshold.com/answers/can-an-oauth-token-issued-to-another-app-reach-the-aws-api-mcp-server-cve-2026-115413",
  "short_answer": "Yes, in awslabs.aws-api-mcp-server 1.3.0 up to 1.6.0 when it serves the streamable-http transport with OAuth. Advisory GHSA-4prq-p2x5-w9fh (CVE-2026-115413, high, CVSS 4.0 7.3, published October 27, 2026) says the server checked a bearer token's signature, issuer and expiry but not the claim naming the application it was issued for, so a token the same identity provider issued to another application in the same tenant, such as a second app client in the same Amazon Cognito user pool, was accepted. A local caller holding one could make AWS API calls with the credentials configured on the host, limited only by those credentials' IAM permissions. Upgrade to 1.6.0, and set AUTH_AUDIENCE (checked against aud) or AUTH_CLIENT_ID (checked against client_id or azp): 1.6.0 refuses to start with AUTH_TYPE=oauth unless one of them is set. Cognito access tokens name the app in client_id, so use AUTH_CLIENT_ID there. If you can't upgrade yet, the advisory's workaround is the default stdio transport. The default stdio setup was never affected.",
  "checklist": [
    "Check whether you're exposed: only the streamable-http transport with OAuth authentication on awslabs.aws-api-mcp-server 1.3.0 or later and before 1.6.0 is affected. stdio, the default, isn't.",
    "Upgrade to 1.6.0 or later (1.6.0 was published on PyPI on October 27, 2026 and was still the newest on November 11, 2026).",
    "Set the claim that names your server's client app before restarting: AUTH_AUDIENCE for providers that put your API in aud, AUTH_CLIENT_ID for providers that name the app in client_id or azp, Amazon Cognito among them. Set both and the server checks both.",
    "Expect a startup error if you skip that step: 1.6.0 raises an error with AUTH_TYPE=oauth unless AUTH_AUDIENCE or AUTH_CLIENT_ID is set, alongside the AUTH_ISSUER and AUTH_JWKS_URI it already needed.",
    "List every app client in the same user pool or tenant. Until you upgrade, a valid token for any of them could reach the server; if you can't upgrade at once, switch to stdio as the advisory suggests.",
    "Keep the host credentials narrow. The advisory bounds the impact by the IAM permissions of the credentials configured on the host, so a read-only or task-scoped role caps what a stray token could do.",
    "Keep the HTTP listener on 127.0.0.1 or behind a firewall: the README says HTTP mode is for single-customer use, not multi-tenant serving, and recommends TLS.",
    "If you run your own MCP server behind OAuth, test it the same way: mint a valid token for a different client in the same tenant and confirm the server rejects it with 401."
  ],
  "sections": [
    {
      "heading": "What CVE-2026-115413 let through",
      "points": [
        "The AWS API MCP Server lets an AI assistant run AWS CLI commands with credentials configured on its host. It can serve the streamable-http transport with OAuth, validating bearer tokens against an identity provider the operator names with AUTH_ISSUER and AUTH_JWKS_URI. Advisory GHSA-4prq-p2x5-w9fh says affected versions validated the token's signature, issuer and expiry, but not the claim identifying the application the token was issued for.",
        "So any token the nominated identity provider issued to another application in the same tenant was accepted, for example one issued to a second app client in the same Amazon Cognito user pool. The advisory says a local caller holding such a token can reach the server and make AWS API calls with the host's credentials, bounded by the permissions of those credentials. It rates the issue high (CVSS 4.0 7.3, CWE-346 origin validation error) and lists versions 1.3.0 up to, not including, 1.6.0.",
        "The configuration code before the fix built its verifier from only the issuer and the JWKS URI. OAuth support arrived in the server in December 2025 (version 1.3.0 was published on PyPI on December 23, 2025), so the gap covered every OAuth-enabled release until the fix."
      ]
    },
    {
      "heading": "What 1.6.0 changes and what you have to set",
      "points": [
        "Version 1.6.0, published on PyPI on October 27, 2026, the same day as the advisory, adds two settings. AUTH_AUDIENCE is the audience of your server, checked against the token's aud claim. AUTH_CLIENT_ID is the OAuth client ID the server accepts tokens from, checked against the client_id claim, or azp for issuers that don't emit client_id. When both are set, both are checked.",
        "One of them is now required. The fix raises an error at startup when AUTH_TYPE is oauth and neither is set, so an unattended upgrade of an OAuth deployment can stop the server until you add the setting. Plan the restart with the value in hand rather than discovering it from a crash loop.",
        "Pick the claim your provider actually fills. Amazon Cognito's documentation says an access token's client_id claim names the user pool app client that authenticated the user, and that its aud claim is present only if the application requested a resource binding. The fix's notes say an audience-only check can't tell Cognito applications apart, which is why AUTH_CLIENT_ID exists; the server's README says to use AUTH_CLIENT_ID with providers whose access tokens carry no aud claim."
      ]
    },
    {
      "heading": "The same check in any MCP server you run",
      "points": [
        "Signature, issuer and expiry prove a token came from your identity provider and is current. They don't prove it was meant for your server. In a shared tenant, every other app, script and test client gets tokens that pass those three checks, so the audience or client claim is the line between them and you.",
        "The MCP authorization specification puts that check on the server: tokens must be issued specifically for it, and clients name the server with the RFC 8707 resource parameter. Providers that don't support resource indicators often express the same thing through a client ID, which is the case this advisory hit.",
        "Write the negative test as well as the positive one. The fix's own tests mint a token for an unrelated app client and expect rejection; do the same in your suite for a different client, a missing claim and a different audience, so a later library or configuration change can't quietly widen who gets in."
      ]
    }
  ],
  "checks": [],
  "ask_rightshold": {
    "start": "https://www.rightshold.com/start?ref=seo",
    "mcp_endpoint": "https://www.rightshold.com/mcp",
    "ask": "Our AWS API MCP Server over HTTP served a call from a token issued to a different Cognito app client before we upgraded to 1.6.0 and set AUTH_CLIENT_ID. Record what happened and the fix under one event, with no token or account details, so we have a dated entry for the review.",
    "mcp_call": {
      "tool": "record_action",
      "arguments": {
        "action_type": "security.config_change",
        "outcome": "success",
        "occurred_at": "2026-11-11T19:00:00Z",
        "client_event_id": "aws-api-mcp:cve-2026-115413:upgrade",
        "summary": "Upgraded awslabs.aws-api-mcp-server to 1.6.0 (GHSA-4prq-p2x5-w9fh); set AUTH_CLIENT_ID to the server's app client; other app clients in the pool now rejected with 401"
      }
    },
    "also": [
      "Needs your API key (or accept_terms:true once to open a free account; the key comes back once). It returns a ledger-committed receipt showing what you recorded and when. It proves the entry was submitted, not that the upgrade happened.",
      "It doesn't scan your server, read its version or settings, or inspect tokens. Keep tokens, account IDs and user details out of summary; hash a private incident note and send action_sha256 if you need to tie the entry to it."
    ],
    "scope": "Rightshold isn't affiliated with AWS or the awslabs/mcp project. It doesn't scan MCP servers, identity providers or AWS accounts, and a recorded entry isn't a finding that a deployment is secure. Advisory details are as published in the awslabs/mcp repository on GitHub, configuration behavior as described in the server's README, changelog and fix pull request, Cognito token claims as described in AWS documentation, and release dates as listed on PyPI, all read November 11, 2026; advisories get updated, so confirm fixed versions on the linked pages."
  },
  "sources": [
    {
      "title": "awslabs/mcp: GHSA-4prq-p2x5-w9fh, AWS API MCP Server OAuth token audience validation bypass (CVE-2026-115413)",
      "url": "https://github.com/awslabs/mcp/security/advisories/GHSA-4prq-p2x5-w9fh"
    },
    {
      "title": "awslabs/mcp pull request 4865: check which application an OAuth token was issued for",
      "url": "https://github.com/awslabs/mcp/pull/4865"
    },
    {
      "title": "awslabs/mcp: AWS API MCP Server README (HTTP mode, AUTH_AUDIENCE, AUTH_CLIENT_ID)",
      "url": "https://github.com/awslabs/mcp/blob/main/src/aws-api-mcp-server/README.md"
    },
    {
      "title": "PyPI: awslabs.aws-api-mcp-server release history",
      "url": "https://pypi.org/project/awslabs.aws-api-mcp-server/#history"
    },
    {
      "title": "AWS: Understanding the Amazon Cognito user pool access token",
      "url": "https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html"
    }
  ],
  "related": [
    {
      "title": "MCP OAuth wrong-audience tokens: what they are and how to defend",
      "url": "https://www.rightshold.com/answers/mcp-oauth-wrong-audience-tokens"
    },
    {
      "title": "Why an MCP server's tool deny list can silently miss dangerous calls",
      "url": "https://www.rightshold.com/answers/why-an-mcp-servers-tool-deny-list-can-silently-miss-dangerous-calls"
    },
    {
      "title": "Can a malicious MCP server steal your OAuth refresh token or client secret?",
      "url": "https://www.rightshold.com/answers/can-a-malicious-mcp-server-steal-your-oauth-refresh-token-or-client-secret"
    },
    {
      "title": "Sharing one MCP server across a company with per-user auth",
      "url": "https://www.rightshold.com/answers/how-to-share-one-mcp-server-across-a-company-with-per-user-auth"
    }
  ],
  "computed_from": "Curated guidance; license verdicts computed from Rightshold's license profiles at render time. Not legal advice.",
  "updated": "2026-11-11"
}