Introduction
An unauthenticated command injection flaw in the community maintained aws-mcp-server allows any network client to execute arbitrary operating system commands on the host, with a CVSS score of 9.8 and no patch available. For organizations that have deployed this server with AWS credentials mounted, the vulnerability creates a direct path from network access to full AWS account compromise.
The aws-mcp-server is an open source project by developer Alexei Ledenev that acts as a bridge between AI assistants and the AWS CLI using the Model Context Protocol (MCP). It is a community project with adoption among developers integrating large language models with AWS infrastructure. It is distinct from the official awslabs MCP servers maintained by Amazon Web Services, a distinction that matters significantly when evaluating trust and support expectations.
Technical Information
CVE-2026-5059 is classified under CWE-78: Improper Neutralization of Special Elements used in an OS Command. The root cause lies in the server's handling of its "allowed commands list," where user supplied input is insufficiently validated before being passed to a system call for execution.
The aws-mcp-server is designed to receive requests over the Model Context Protocol and translate them into AWS CLI commands. It maintains an allowed commands list intended to restrict which CLI operations can be invoked. However, the validation logic does not properly sanitize incoming command strings. An attacker can craft input that satisfies the allowed commands check while embedding injected shell commands that the server then executes via a system call.
The server requires no authentication. When deployed using the streamable HTTP transport, it binds to port 8000 by default, creating a direct remote attack surface for any client that can reach the port.
Attack Flow
- The attacker identifies an aws-mcp-server instance accessible over the network, typically on port 8000 when using the streamable HTTP transport.
- The attacker sends a crafted MCP request containing a string that appears to match an allowed AWS CLI command but includes injected shell metacharacters or additional commands.
- The server's allowed commands validation fails to detect the injected payload due to insufficient input sanitization.
- The server passes the attacker controlled string to a system call, which executes both the intended AWS CLI command and the injected arbitrary commands.
- The injected commands run in the context of the MCP server process, giving the attacker code execution on the host.
A typical deployment using the streamable HTTP transport mounts AWS credentials into the container:
docker run --rm -p 8000:8000 \ -e AWS_MCP_TRANSPORT=streamable-http \ -v ~/.aws:/home/appuser/.aws:ro \ ghcr.io/alexei-led/aws-mcp-server:latest
Even with the credentials directory mounted read only, a successful command injection grants the attacker the ability to read and exfiltrate those credentials, enabling lateral movement into the associated AWS account.
A companion vulnerability, CVE-2026-5058 (tracked as ZDI-26-246), shares the exact same root cause and severity, indicating a systemic pattern of insufficient input sanitization in the project's command handling logic rather than an isolated oversight.
Affected Systems and Versions
The vulnerability is confirmed to affect version 1.3.0 of the aws-mcp-server. The status of other versions is currently unknown.
The vulnerable configuration requires the server to be network accessible. This is the case when using the streamable HTTP transport (binding to port 8000 by default). Deployments restricted to local stdio transport have a reduced attack surface, though the underlying code flaw remains present.
This vulnerability does not affect the official awslabs MCP servers maintained by Amazon Web Services. Only the community project at alexei-led/aws-mcp-server is impacted.
Vendor Security History
The disclosure timeline for this vulnerability is notable. The Zero Day Initiative reported CVE-2026-5059 to the vendor on September 3, 2025. The vendor rejected the vulnerability on December 15, 2025. ZDI subsequently published the advisory (ZDI-26-245) as a zero day on March 30, 2026, more than six months after the initial report and without a patch being available.
The existence of a companion vulnerability (CVE-2026-5058 / ZDI-26-246) with the same root cause and the vendor's rejection of both reports suggests a fundamental disagreement about the project's security boundary. The project's security documentation states it assumes a trusted user model, which may explain the vendor's position, but does not eliminate the risk for organizations that have deployed the server in environments where untrusted network access is possible.
