What CVE-2026-16584 in the AWS API MCP Server taught me about MCP security, fail-open systems, and the controls we place between AI agents and real infrastructure.
On July 23, 2026, AWS published a security advisory for a vulnerability I reported in the AWS API MCP Server. It was assigned CVE-2026-16584, rated High, and given a CVSS v4.0 score of 7.3.
My name appears in the acknowledgement as the independent researcher who reported it. That was a meaningful moment for me. I have spent much of my career building backend systems, and more recently I have been looking closely at the security boundaries around AI agents and MCP servers.
Still, I do not want this post to be a victory lap. The interesting part is the failure itself because it is easy to understand, easy to underestimate, and relevant far beyond one open-source project.
Here is the short version:
The server could start even when the data required to enforce its security policy had failed to load. Once that happened, the policy check could be skipped for the lifetime of the process.
The server was running. The security policy was not.
Disclosure note:This article uses only information available in the public AWS security advisory. I am not publishing a proof of concept, step-by-step reproduction instructions, private communication, internal logs, or details that AWS has not made public.
The Model Context Protocol, or MCP, gives AI assistants a standard way to connect to tools and external systems. The AWS API MCP Server allows an assistant to interact with AWS services through AWS CLI commands.
That is useful, but it also places the server on a sensitive boundary. A model is no longer only producing text. It can request an action against real cloud infrastructure.
The server includes an optional, user-configured security policy. Administrators can use that policy to deny or gate selected AWS operations before they are executed.
In normal operation, the flow is simple:
CVE-2026-16584 affected the first step, which then changed what happened at the third.
The AWS API MCP Server loaded its policy-enforcement data during startup. According to the advisory, if that initialization failed, the process could continue running without the enforcement data being available.
When a request arrived later, the policy check could be skipped. When a security policy was configured without fail-closed modes enabled, configured deny and gate rules were not consulted. More importantly, this was not limited to a single request. The server could stay in that weaker state for the lifetime of the process.
| Stage | Expected behaviour | Vulnerable behaviour |
|---|---|---|
| Startup | Policy data loads | Policy data is unavailable |
| Readiness | Server becomes ready after its controls are ready | Server keeps running |
| Request | Policy evaluates the AWS operation | Policy evaluation is skipped |
| Result | Deny or gate rules apply | That policy layer does not restrict the operation |
Initialization failures happen in production. A dependency times out. A file is malformed. Permissions are wrong. Connectivity is degraded. None of that is unusual.
The security question is what the application does after the failure.
In this case, missing enforcement state could lead to permissive behaviour. That is a classic fail-open security problem: a control becomes unavailable, but the protected operation can continue.
The guard was not defeated during a request. It was missing before the request arrived.
When people discuss AI security, the conversation quickly moves to prompt injection, model manipulation, jailbreaks, and malicious tool descriptions. Those are real problems. But this vulnerability was not caused by the model doing something clever.
It was a conventional backend security failure at an AI execution boundary.
That distinction matters. MCP servers sit between an agent’s intent and an external action. If a permission check, approval gate, tenant boundary, tool allowlist, or sandbox is absent, the model does not need to break that control. The application may already be operating without it.
This is why agentic AI security cannot be reduced to better prompts. The full execution path matters:
These are software architecture questions, not language-model questions.
It is important to describe the impact accurately.
CVE-2026-16584 bypassed the optional security-policy layer under the affected MCP server condition. It did not remove AWS IAM permissions from the credentials configured for the server.
If those credentials allowed only read access to a small set of resources, IAM continued to enforce that boundary. If the credentials were broad, the missing MCP policy layer left a much larger set of actions available. The effective risk therefore depended heavily on credential scope.
This is a practical example of why AWS IAM least privilege matters. Least privilege is not only about preventing an intended user from doing too much. It also limits the damage when another security layer fails in an unexpected way.
An MCP policy can add useful context-specific restrictions, but it should not be the only boundary between an AI agent and a high-impact cloud operation.
None
mean? The advisory maps the issue to CWE-455: Non-exit on Failed Initialization. The name sounds dry, but the design problem behind it appears in many systems.
Imagine a security component with three possible states:
The second and third states must never be treated as equivalent.
One is an explicit configuration decision. The other is a security failure. If both become the same empty, null, or false-like value in memory, request-handling code can easily interpret “not available” as “nothing to enforce.”
That is not just an MCP concern. The same pattern can affect:
A missing value is not neutral when that value decides what a system is allowed to do.
This finding changed the way I think about reviewing agent infrastructure. I would not only test whether a deny rule works. I would also follow the control through its failure states.
These are the questions I would ask:
The key test is not only:
Does the security control block the operation?
It is also:
Can the application continue when the security control is unable to block anything?
AWS fixed the issue in awslabs.aws-api-mcp-server
version 1.3.47.
Anyone using an affected version, from 0.2.13 up to 1.3.46, should upgrade to the latest version. Forks and derivative projects should confirm that they include the relevant fix rather than assuming their implementation is unaffected.
The AWS advisory also lists two measures for users who cannot upgrade immediately:
I would add one operational check: verify the version actually running in each environment. Updating a dependency declaration is not the same as confirming that every deployed instance has been replaced.
I reported the issue privately and worked with AWS through the coordinated vulnerability-disclosure process. The vulnerability was fixed before I wrote publicly about its design implications.
Responsible disclosure is slower than posting a finding immediately, but the sequence matters. Users need a patch and clear mitigation guidance before a researcher turns a vulnerability into public content.
For the same reason, I am keeping this discussion at the architectural level. There is enough information here for engineers to recognize and test the failure pattern without turning the post into an exploitation guide. I appreciate AWS for investigating the report, shipping the fix, publishing the advisory, and acknowledging my contribution.
The most memorable security bugs are not always the most complicated ones.
Many reviews focus on finding a clever way around a running control. CVE-2026-16584 points to a simpler question:
What happens if the control never starts?
As MCP adoption grows, we will keep connecting AI agents to cloud platforms, databases, deployment systems, internal APIs, and other high-impact tools. The safety of those systems will depend on much more than model behaviour. It will depend on ordinary engineering details: initialization, state handling, readiness, credentials, error paths, and secure defaults.
My main takeaway is one line:
If the policy is not ready, the server is not ready. That principle applies to far more than this one AWS API MCP Server vulnerability.
If you are building or reviewing an MCP server, check its startup failure paths. They may tell you more about its real security posture than the happy path does. Lav Kumar Vishwakarma is a lead backend engineer and independent security researcher working on agentic AI security, MCP permission boundaries, secure tool execution, runtime isolation, and production AI systems. AWS credited him for responsibly reporting CVE-2026-16584.