Apr 17, 2026 Ilya Kabanov

Clone a repo, run Codex, lose your AWS keys

TLDR: 24 MCP CVEs in two weeks from Microsoft, OpenAI, Splunk, Apache, and Prefect. MCP servers run on developer laptops with full production credentials: infrastructure-grade access, side-project-grade security. You can't wait until Anthropic matures the MCP spec, so start by removing production credentials from developer laptops.

Model Context Protocol (MCP) is the open standard that lets AI assistants reach external tools and data. Servers come in three shapes. Most are local stdio subprocesses on developer laptops, running unsandboxed with full credentials (AWS keys, SSH, Git tokens, VPN), typically side projects from npm or PyPI with no review (aws-mcp-server 127 stars, api-lab-mcp 10). Some are HTTP daemons on localhost, browser-reachable via DNS rebinding and CSRF (Apollo MCP). And some are self-hosted or vendor services accessed over the network (Azure MCP Server, Splunk MCP, Nginx UI), where trust shifts from the developer to the vendor or ops team.

Between March 30 and April 15, 2026, 24 MCP-specific CVEs were published: seven critical, twelve high, three medium, two unscored. Vendors include Microsoft, OpenAI, Splunk, Apache, and Prefect. The dominant vulnerability classes are command injection, SSRF, missing authentication, and confused-deputy, the same classes from the OWASP Top 10, now landing on the protocol that connects AI to your infrastructure.

Source: modelcontextprotocol.io

Four common patterns across these vulnerabilities:

1. STDIO config is the exploit.

The STDIO transport spawns a child process from config (spawn(command, args)). Whoever writes the config gets RCE. Five CVEs:

LangChain-ChatChat (CVE-2026-30617, 8.6), Agent Zero (CVE-2026-30624, 8.6), Jaaz (CVE-2026-30616, 7.3): MCP config writable through exposed network interfaces. Attacker writes a STDIO config remotely; agent session spawns the attacker's process.
Upsonic (CVE-2026-30625): allowlist includes npm and npx. npx -c "malicious command" gives full shell.
OpenAI Codex CLI (CVE-2025-61260): .codex/config.toml auto-loaded from the working directory. Clone a malicious repo, run codex, attacker's MCP config executes.

Four unrelated vendors, same failure mode. The Codex CLI variant is the worst for enterprises because cloning repos is universal: a developer clones a repo from Slack, runs their AI assistant inside it, and the attacker's config executes with the developer's full credentials. No phishing, no malware, just a config file in a repo.

2. Tool argument reaches shell unsanitized.

MCP tools wrapping CLIs (AWS, Stata, kubectl) pass LLM-supplied parameters to shell execution sinks. Five CVEs:

Zero sanitization. mcp-javadc (CVE-2026-5802, 7.3) and stata-mcp (CVE-2026-31040, 9.8): tool parameters passed directly to process execution with no validation.
Allowlist present but bypassable. aws-mcp-server (CVE-2026-5058, 9.8) and CVE-2026-5059 (9.8): the allowlist checks the command name but not its arguments, so an allowed binary still runs attacker-controlled shell.
One tool wrong, rest correct. mcp-server-kubernetes (CVE-2026-39884, 8.3): port_forward uses string concatenation while every other tool in the same codebase uses safe array-based args. Attacker injects --address=0.0.0.0 to expose internal Kubernetes services.

The mcp-server-kubernetes case is instructive: 1,377 stars, kubectl access to production clusters, vulnerability in the maintainer's own code. 13 other tools in the same repo were safe. No review process caught the one that wasn't.

3. Tool fetches attacker-controlled URLs.

Five SSRF CVEs, two paths. Direct: n8n-MCP (CVE-2026-39974, 8.5) reflects response bodies from caller-supplied URLs, exposing AWS IMDS, GCP metadata, and internal services. api-lab-mcp (CVE-2026-5832, 7.3) fetches user-supplied URLs in analyze_api_spec(). Apache SkyWalking MCP (CVE-2026-34476, 7.1) takes URLs from the SW-URL header.

Indirect: FastMCP (CVE-2026-32871, 10.0) substitutes path parameters into URL templates without encoding, then urljoin() resolves ../, so attackers escape the API prefix and reach arbitrary backends with forwarded auth headers. FrontMCP (CVE-2026-39885, 7.5) dereferences $ref pointers in OpenAPI specs without URL restrictions; a spec pointing at http://169.254.169.254/ fetches cloud metadata on initialize().

On EC2 with an IAM role, the attacker gets temporary cloud credentials. On a developer laptop, they probe internal services through the MCP server; responses flow back to the AI context, where follow-up tool calls exfiltrate them.

4. MCP endpoint exposed without authentication.

Four CVEs. Azure MCP Server (CVE-2026-32211, 9.1): critical function with no auth, published April 3. Seven days later, Microsoft announced Azure MCP Server 2.0 with "security and operational safety" as "central design priorities" and no mention of the CVE that prompted it.

Nginx UI MCP (CVE-2026-33032, 9.8): empty IP allowlist means /mcp_message allows everyone, exposing every tool, including nginx restart and config rewrite. Unpatched. MCPHub (CVE-2025-13822, 5.3) and Apollo MCP Server (CVE-2026-35577, 6.8): missing auth middleware and missing Host header validation respectively.

All Shodan-scannable. If you run nginx-ui with MCP enabled, every tool is reachable from your network right now.

My take:

Infrastructure-grade access, side-project-grade security. MCP servers that touch AWS, Kubernetes, databases, and CI/CD pipelines are built as open-source side projects, installed with a single npm install, and connected to environments holding production credentials. mcp-server-kubernetes gives an AI assistant kubectl access to production clusters. It has 1,377 stars. Of its 14 tools, one had an argument injection vulnerability; the other 13 were safe. No one reviewed the code because no review process exists. This is the norm, not the exception.
We are building critical infrastructure for AI on protocols that have no baseline conformance benchmarks. The only safety net is a line in the Apache 2.0 license that says "WITHOUT WARRANTY OF ANY KIND." Twenty-four CVEs in 16 days is what fragile infrastructure looks like.
The spec makes authorization optional for MCP. HTTP transports should conform and STDIO transports should instead inherit credentials from the environment. That is pragmatic (OAuth does not fit a local child-process model), but it leaves STDIO with no spec-level guidance on config integrity or least-privilege. 5 of 24 CVEs exist in that gap.
The entire AI coding tool ecosystem relies on project-level files that influence what the AI does, so you can't just ban them. But you can keep production credentials off developer laptops. Replace long-lived AWS keys, static kubeconfigs, and SSH private keys with short-lived tokens behind identity providers.