al-ice.ai

Capital Letters Beat the Policy: AWS API MCP Server Let Denied Operations Through

AI Vulnerabilities & CVEs by al-ice.ai Editorial

A second AWS API MCP Server authorization flaw in as many months turns on the least glamorous layer of the stack: string normalization. CVE-2026-125271 (GitHub advisory GHSA-4wq9-grf3-qg2p, NVD record published 10 November 2026) describes incorrect normalization of operation names in the server’s custom security policy enforcement: for AWS API operations whose names contain consecutive capital letters, the server normalized the name incorrectly before comparing it against the policy, so denyList and elicitationList entries for those operations were silently not enforced. An actor could then execute operations across AWS services that the operator had explicitly configured the policy to deny or to require elicitation for. All versions from 0.2.13 through before 1.5.1 are affected; the fix is awslabs.aws-api-mcp-server 1.5.1, and the advisory states there is no workaround other than upgrading. NVD scores it 7.8 HIGH (CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H); the GitHub advisory carries 8.5 under CVSS 4.0. AWS published the companion security bulletin 2026-176, and credited Syed Anas Mohiuddin for coordinated disclosure.

What the policy was supposed to stop

The advisory’s impact examples are chosen to frighten correctly: creating a federated identity provider, deactivating an MFA device, and deleting database clusters are all in the class of operations a careful operator would place on a deny list or behind an elicitation gate — and all are the kind of high-consequence, low-frequency calls where a single bypass is total. Three scope boundaries matter. The flaw requires a locally run server with a custom security policy that lists affected operations, plus user interaction with the AI assistant — this is not a remote unauthenticated takeover of every deployment. The remote AWS API MCP Server offering is not affected. And the two global guardrails many operators rely on — READ_OPERATIONS_ONLY and REQUIRE_MUTATION_CONSENT — are explicitly not affected, which usefully narrows the exposed population to custom-policy deployments while leaving no comfort for anyone in that set: their deny lists had holes shaped exactly like real AWS operation names.

The same server, the second policy bug

This is the second authorization defect in this server this site has tracked: CVE-2026-115413 was an audience-validation bypass in which the server accepted tokens from the same tenant regardless of intended audience — a confused-deputy at the token layer. CVE-2026-125271 is the complementary failure one layer down: the token is fine and the policy is written, but the name comparison that binds the two is lossy. Together they tell a story about where MCP server security actually breaks. Not in the cryptography, and not in exotic prompt-injection chains, but in the unglamorous seams between policy intent and policy matching — token audience strings on one side, operation-name canonicalization on the other. Anyone running this server should treat the pair as one remediation event: upgrade to 1.5.1, re-audit the custom policy’s deny and elicit lists against the operations they were meant to cover, and verify — per the advisory’s own warning — that forked or derivative code independently incorporates the fix. Thematically this belongs next to the mcp-go and ChatCLI OAuth resource-confusion pair: different mechanism, same lesson that identity and authorization metadata only protects you if every consumer parses it identically.

What to actually do

  1. Upgrade to awslabs.aws-api-mcp-server 1.5.1 immediately — the advisory is explicit that no workaround exists, and the affected range (>=0.2.13) covers a long tail of deployments.
  2. Re-verify denyList and elicitationList coverage after upgrading, with special attention to operations containing consecutive capitals — confirm each listed operation is actually matched by the enforcement path, not merely present in the config file.
  3. Patch forks and vendored copies: the advisory calls out derivative code directly, and MCP servers are among the most forked components in agent stacks.
  4. Treat past policy violations as undetectable-by-default: if a denied operation was invoked through this bypass, the policy layer believed it was compliant — review AWS CloudTrail for sensitive calls (IAM identity-provider changes, MFA deactivation, database deletions) issued through the MCP server during the exposure window.

Our verification was read-only. We read GHSA-4wq9-grf3-qg2p first-hand in full via the GitHub API (published 10 November 2026, high severity, CVSS 4.0 8.5, summary, impact with the three example operations, affected range >=0.2.13 and <1.5.1, 1.5.1 patch, no-workaround statement, preconditions of locally run server plus custom policy plus user interaction, remote-offering and READ_OPERATIONS_ONLY/REQUIRE_MUTATION_CONSENT exclusions, fork-warning, and Mohiuddin acknowledgement) and the full NVD JSON for CVE-2026-125271 (published 10 November 2026 17:17 UTC, Received, CVSS 3.1 7.8, consecutive-capitals mechanism, references to AWS bulletin 2026-176, the GHSA, and PyPI 1.5.1). The AWS bulletin page itself is JavaScript-rendered and its body text was not independently extracted; it is cited via the NVD reference only. Offseq Threat Radar and Strix listings were used solely as discovery pointers. We ran no server, sent no MCP request, tested no policy, and contacted no vendor. Brave Search was used for discovery only.

Sources: