AWS API MCP Server Could Run Without Its Configured Policy Gate — CVE-2026-16584
AWS has fixed a fail-open condition in its open-source AWS API MCP Server. In versions 0.2.13 through 1.3.46, a failure while loading security-policy data at startup could leave the server running while silently skipping the policy check on every subsequent request. Version 1.3.47 repairs CVE-2026-16584.
The affected policy is the server’s optional control for denying or gating selected AWS operations. When the vulnerable startup path occurred and fail-closed modes were not enabled, an actor could cause operations blocked by that policy to execute. The AWS identity attached to the server still had to authorize those operations: AWS explicitly says IAM permissions remained in effect.
That distinction matters operationally. This was not an IAM bypass, but it could erase a deliberately narrower agent-specific boundary and expose the full authority of the configured AWS credentials. AWS rates the issue high severity; NVD records CVSS 4.0 score 7.3 and CVSS 3.1 score 7.0, with no known exploitation in CISA’s SSVC data at publication time.
A startup dependency became a lifetime authorization decision
The MCP server lets an AI assistant execute AWS CLI operations. Its security policy can place a deny or human gate in front of operations even when the underlying IAM principal is technically allowed to perform them. This defense-in-depth model is useful only if failure to initialize the policy prevents the privileged service from becoming available.
In the vulnerable versions, the server continued after the enforcement data failed to load. AWS’s advisory says the per-request check was then skipped for the lifetime of that process. A temporary startup problem—such as degraded connectivity—could therefore create a persistent, less-restricted runtime that looked alive to ordinary process supervision.
The upstream fix changes the policy loader to fail closed: the relevant commit converts policy-loading failures into a security-policy initialization error and adds tests confirming that authorization does not continue without the required data. Operators should still upgrade rather than rely on detecting one particular failure mode.
Why IAM remains the final boundary
An MCP policy and IAM solve different problems. IAM constrains what the workload identity can do in AWS. The MCP policy constrains which subset of those actions an agent should be allowed to request under its own workflow rules. If the second boundary disappears, the first becomes the effective maximum blast radius.
Broad credentials are consequently more dangerous than the label “policy bypass” initially suggests. A policy that denies destructive, expensive, or data-exporting operations cannot compensate for an execution role that already permits them when enforcement fails. Agent deployments should treat the MCP policy as supplemental authorization, never as a replacement for task-scoped IAM.
A healthy process is also not proof that policy initialization succeeded. Readiness checks should verify the security state needed to serve requests, not merely that a port answers. Startup errors, policy-load messages, and unexpected restarts belong in the same monitoring path as denied tool calls.
Defensive response checklist
- Upgrade the package. Move
awslabs.aws-api-mcp-serverto 1.3.47 or later, rebuild pinned environments, and restart every server instance. - Patch derivatives. AWS specifically calls out forked or derivative code. Confirm that vendored copies include the upstream fail-closed change rather than checking only a package manifest.
- Verify the running artifact. Record the resolved package version, image digest, process start time, and deployment revision. Do not infer remediation from a changed lockfile alone.
- Reduce IAM authority. Use a task-specific role and explicit permissions. AWS suggests least-privileged credentials, such as a read-only role where appropriate, as a pre-upgrade mitigation.
- Review startup telemetry. Search for policy initialization, connectivity, and enforcement-data load failures, then correlate affected process lifetimes with CloudTrail activity.
- Restart after degraded startup. If an unpatched server started while connectivity was impaired, AWS advises restarting after connectivity returns so policy data can load. Upgrade remains the durable fix.
- Test failure behavior. In a non-production environment, make policy initialization fail and verify that the patched service refuses to become ready and cannot execute an AWS operation.
- Hunt by identity, not just host. Review operations performed by each MCP server role during suspect windows, especially actions the configured MCP policy was meant to deny or gate.
CVE-2026-16584 is a concise example of why authorization components must fail closed. Agent runtimes join probabilistic decision-making to deterministic cloud APIs; an optional policy check can be valuable defense in depth, but only if the service cannot quietly outlive the control’s initialization failure.
The remediation also complements AWS’s earlier fix for host-side SSRF in the HealthLake MCP Server. In both cases, isolation at one layer did not remove the need to constrain the authority exercised elsewhere. MCP operators need narrow workload credentials, enforced policy, observable startup state, and network controls together.
Sources: