{"slug": "the-server-was-up-its-security-policy-wasnt", "title": "The Server Was Up. Its Security Policy Wasn’t.", "summary": "An independent researcher reported a high-severity vulnerability, CVE-2026-16584, in the AWS API MCP Server, which allows AI assistants to interact with AWS services. The flaw could cause the server to start without loading its security policy data, leading to fail-open behavior where configured deny and gate rules are skipped for the lifetime of the process. The researcher emphasizes that this is a conventional backend security failure at an AI execution boundary, not a model manipulation issue.", "body_md": "*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.*\n\nOn 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.\n\nMy 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.\n\nStill, 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.\n\nHere is the short version:\n\nThe 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.\n\nThe server was running. The security policy was not.\n\nDisclosure 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.\n\nThe 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.\n\nThat 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.\n\nThe server includes an optional, user-configured security policy. Administrators can use that policy to deny or gate selected AWS operations before they are executed.\n\nIn normal operation, the flow is simple:\n\nCVE-2026-16584 affected the first step, which then changed what happened at the third.\n\nThe 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.\n\nWhen 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.\n\n| Stage | Expected behaviour | Vulnerable behaviour |\n|---|---|---|\n| Startup | Policy data loads | Policy data is unavailable |\n| Readiness | Server becomes ready after its controls are ready | Server keeps running |\n| Request | Policy evaluates the AWS operation | Policy evaluation is skipped |\n| Result | Deny or gate rules apply | That policy layer does not restrict the operation |\n\nInitialization failures happen in production. A dependency times out. A file is malformed. Permissions are wrong. Connectivity is degraded. None of that is unusual.\n\nThe security question is what the application does after the failure.\n\nIn 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.\n\nThe guard was not defeated during a request. It was missing before the request arrived.\n\nWhen 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.\n\nIt was a conventional backend security failure at an AI execution boundary.\n\nThat 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.\n\nThis is why agentic AI security cannot be reduced to better prompts. The full execution path matters:\n\nThese are software architecture questions, not language-model questions.\n\nIt is important to describe the impact accurately.\n\nCVE-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.\n\nIf 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.\n\nThe effective risk therefore depended heavily on credential scope.\n\nThis 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.\n\nAn 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.\n\n`None`\n\nmean?\nThe advisory maps the issue to [CWE-455: Non-exit on Failed Initialization](https://cwe.mitre.org/data/definitions/455.html). The name sounds dry, but the design problem behind it appears in many systems.\n\nImagine a security component with three possible states:\n\nThe second and third states must never be treated as equivalent.\n\nOne 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.”\n\nThat is not just an MCP concern. The same pattern can affect:\n\nA missing value is not neutral when that value decides what a system is allowed to do.\n\nThis 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.\n\nThese are the questions I would ask:\n\nThe key test is not only:\n\nDoes the security control block the operation?\n\nIt is also:\n\nCan the application continue when the security control is unable to block anything?\n\nAWS fixed the issue in `awslabs.aws-api-mcp-server`\n\nversion **1.3.47**.\n\nAnyone 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.\n\nThe AWS advisory also lists two measures for users who cannot upgrade immediately:\n\nI 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.\n\nI 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.\n\nResponsible 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.\n\nFor 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.\n\nI appreciate AWS for investigating the report, shipping the fix, publishing the advisory, and acknowledging my contribution.\n\nThe most memorable security bugs are not always the most complicated ones.\n\nMany reviews focus on finding a clever way around a running control. CVE-2026-16584 points to a simpler question:\n\nWhat happens if the control never starts?\n\nAs 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.\n\nMy main takeaway is one line:\n\nIf the policy is not ready, the server is not ready.\n\nThat principle applies to far more than this one AWS API MCP Server vulnerability.\n\nIf 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.\n\nLav 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.", "url": "https://wpnews.pro/news/the-server-was-up-its-security-policy-wasnt", "canonical_source": "https://dev.to/lav_vishwakarma/the-server-was-up-its-security-policy-wasnt-2kej", "published_at": "2026-08-13 14:08:48+00:00", "updated_at": "2026-08-13 14:19:41.487724+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-infrastructure", "ai-policy"], "entities": ["AWS", "CVE-2026-16584", "AWS API MCP Server", "Model Context Protocol"], "alternates": {"html": "https://wpnews.pro/news/the-server-was-up-its-security-policy-wasnt", "markdown": "https://wpnews.pro/news/the-server-was-up-its-security-policy-wasnt.md", "text": "https://wpnews.pro/news/the-server-was-up-its-security-policy-wasnt.txt", "jsonld": "https://wpnews.pro/news/the-server-was-up-its-security-policy-wasnt.jsonld"}}