Introduction
An unauthenticated command injection flaw in the community-maintained aws-mcp-server lets any network client execute arbitrary operating system commands on the host. It has a CVSS score of 9.8, and no patch is available. For organizations that have deployed this server with AWS credentials mounted, the vulnerability opens a direct path from network access to full AWS account compromise.
The aws-mcp-server is an open-source project by developer Alexei Ledenev. It uses the Model Context Protocol (MCP) to connect AI assistants to the AWS CLI. It is a community project, used by developers who integrate large language models with AWS infrastructure. It is separate from the official awslabs MCP servers maintained by Amazon Web Services, and that difference matters when you set 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 is the server's handling of its "allowed commands list": the server does not validate user-supplied input well enough before it passes that input to a system call for execution.
The aws-mcp-server receives requests over the Model Context Protocol and translates them into AWS CLI commands. Its allowed commands list is meant to restrict which CLI operations a client can invoke. However, the validation logic does not properly sanitize incoming command strings. An attacker can craft input that passes the allowed commands check while carrying injected shell commands, which the server then executes through a system call.
The server requires no authentication. With the streamable HTTP transport, it binds to port 8000 by default, so any client that can reach the port can attack it directly.
Attack Flow
- The attacker finds an aws-mcp-server instance reachable over the network, typically on port 8000 when it uses the streamable HTTP transport.
- The attacker sends a crafted MCP request with a string that appears to match an allowed AWS CLI command but includes injected shell metacharacters or additional commands.
- Because input sanitization is insufficient, the server's allowed commands validation does not detect the injected payload.
- 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, which gives 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
The read-only mount does not protect those credentials. A successful command injection still lets the attacker read and exfiltrate them, then use them to move laterally into the associated AWS account.
A companion vulnerability, CVE-2026-5058 (tracked as ZDI-26-246), has the same root cause and the same severity. Two such flaws point to a systemic pattern of insufficient input sanitization in the project's command handling logic.
Affected Systems and Versions
The vulnerability is confirmed in 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 reachable over the network. That is the case with the streamable HTTP transport, which binds to port 8000 by default. Deployments restricted to the local stdio transport have a smaller attack surface, though the underlying code flaw is still present.
The official awslabs MCP servers maintained by Amazon Web Services are not affected. The only impacted project is the community one at alexei-led/aws-mcp-server.
Vendor Security History
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 then published the advisory (ZDI-26-245) as a zero day on March 30, 2026, more than six months after the initial report, with no patch available.
The vendor rejected both this report and the one for the companion vulnerability (CVE-2026-5058 / ZDI-26-246), which has the same root cause. That suggests a fundamental disagreement about the project's security boundary. The project's security documentation states that it assumes a trusted-user model. That may explain the vendor's position, but it does not remove the risk for organizations that have deployed the server in environments where untrusted network access is possible.
