high · 7CVE-2026-16584Jul 24, 2026

CVE-2026-16584: AWS API MCP Server Security Policy Bypass via Startup Initialization Failure

Rohit Hatagale
AI Security Researcher, SecureLayer7

If the AWS API MCP Server fails to load its security policy enforcement data at startup, it silently skips all per-request policy checks for the life of the process, letting any caller run operations…

Packageawslabs.aws-api-mcp-server
Ecosystempip
Affected>= 0.2.13, < 1.3.47
Fixed in1.3.47
CVE-2026-16584: AWS API MCP Server Security Policy Bypass via Startup Initialization Failure

The problem

The AWS API MCP Server loads enforcement data at startup to power its user-configured security policy. If that load fails (for example, due to a network hiccup or a missing resource), the server continues running without the enforcement data.

In the default configuration, every subsequent per-request policy check is silently skipped. Configured deny rules and gate rules are never consulted. Any AWS API operation the policy was meant to restrict executes freely for the entire lifetime of the process.

Proof of concept

A working proof-of-concept for CVE-2026-16584 in awslabs.aws-api-mcp-server, with the exact payload below.

json
# Trigger condition: cause policy enforcement data to fail loading at server startup,
# then issue an operation that the policy should deny.
#
# Example: start the server in an environment where the policy data source is unreachable
# (e.g., degraded/no network connectivity, misconfigured endpoint, or corrupt data file).
# The server starts successfully despite the init failure and emits no fatal error.
#
# Once running, submit a normally-denied AWS CLI call via the MCP tool:
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "execute_aws_command",
    "arguments": {
      "command": "aws s3 rb s3://target-bucket --force"
    }
  }
}
# Expected (patched): server refuses or gates the call per configured policy.
# Actual (vulnerable): policy check is skipped; the CLI command executes.

The root cause is CWE-636 (Non-Exit on Failed Initialization). Before the patch, the startup routine caught exceptions thrown by the policy data loader but continued execution with the enforcement object in a null or uninitialized state. The per-request check then performed a truthiness test on that object: if the object was falsy or None, the check short-circuited and returned "allow" instead of failing closed.

The patch (PR #4315, commit ab1bbebc) corrects this by making a failed initialization fatal: the server now raises an unhandled exception (or explicit SystemExit) so the process terminates rather than running without enforcement data. This is the canonical fix for CWE-636: fail loudly on bad initialization instead of silently degrading.

Public PoC not yet available; trigger condition and request derived from advisory description and patch behavior analysis.

The fix

Upgrade to awslabs.aws-api-mcp-server >= 1.3.47. Until you can upgrade, use least-privilege IAM credentials scoped to the task (IAM enforcement is unaffected by this bug), and if the server started during degraded connectivity, restart it once connectivity is restored so the policy data loads successfully.

Reported by Lav Kumar Vishwakarma.

References: [1][2][3][4][5][6]

Related research