MCP flaw may expose 150 million downloads

Ox Security says an MCP design flaw could expose 150 million downloads and up to 200,000 vulnerable instances.

A security report published on 15 April 2026 says a flaw in the Model Context Protocol could let attackers run commands on affected systems. The claim matters because MCP is the plumbing many AI tools use to reach files, databases, and APIs.

Ox Security says the issue touches more than 200 open source projects, 7,000-plus publicly accessible servers, and as many as 200,000 vulnerable instances. If those numbers hold up, this is bigger than a single bad library update; it is a supply-chain problem sitting inside a standard.

What Ox Security says is broken

Ox Security argues the issue is baked into the way the official MCP SDKs handle STDIO-based server startup. In its report, the company says the command runs even when the process fails to start, which means a malicious command can execute before the developer gets a useful warning.

That is a nasty failure mode because it removes the normal friction that catches bad input. Instead of a clear stop sign, the developer toolchain can keep moving while the attacker’s command already ran.

According to the report, this affects Anthropic’s official SDKs across Python, TypeScript, Java, and Rust. Ox Security also says the flaw can lead to arbitrary command execution, which opens the door to sensitive data theft, API key exposure, internal database access, and chat history leaks.

• Execution path: STDIO interface used to launch a local server process
• Impact: arbitrary command execution on vulnerable systems
• Potential exposure: user data, API keys, internal databases, chat logs
• Languages named: Python, TypeScript, Java, Rust

Why this is bigger than one bug

The most worrying part is not the technical trick itself. It is the fact that a protocol used to connect AI models to external tools can turn into a common failure point across many products at once.

MCP is open source and widely adopted because it makes agent integrations easier. That convenience has a cost when the protocol’s defaults assume developers will sanitize everything correctly, especially in a fast-moving AI stack where teams are shipping connectors as quickly as they can.

“We are trusting these systems with increasingly sensitive data and real-world actions. If the very protocol meant to connect AI agents is this fragile and its creators will not fix it then every company and developer building on top of it needs to treat this as an immediate wake-up call,” said Kevin Curran, professor of cybersecurity at Ulster University and IEEE senior member.

Curran’s point is blunt, and it is hard to argue with. When a protocol becomes the shared base for lots of AI products, the security model needs to be boring and predictable, not clever and permissive.

The blame dispute matters for developers

Ox Security says it tried to get Anthropic to patch the issue, but the company reportedly called the behavior expected. That response shifts the burden to developers, who now have to decide whether the protocol’s defaults are safe enough for production use.

That is the key policy question here: should a protocol for agentic systems default to execution, or should it default to safety and require explicit opt-in? Anthropic’s reported position treats sanitization as the developer’s job. Ox Security thinks that is dangerous because security mistakes tend to repeat at scale.

The report also says Ox Security has issued more than 30 responsible disclosures and found more than 10 high- or critical-severity CVEs while helping patch individual open source projects. That suggests the firm is treating this as a broad ecosystem issue, not a one-off advisory.

• Responsible disclosures: 30+
• High or critical CVEs found: 10+
• Reported vulnerable projects: 200+
• Reported exposure: up to 200,000 instances

What teams should do now

If your team is building on MCP, the practical move is to audit every place where a connector can spawn local processes or pass through shell-like input. Treat SDK defaults as unsafe until you verify how commands are built, escaped, and logged.

Security teams should also inventory exposed MCP servers, review which ones are public, and check whether connectors have access to secrets, internal data stores, or chat transcripts. If a connector can reach those assets, it needs the same review you would give any remote execution path.

For now, the safest assumption is simple: MCP adoption has outpaced some of its security thinking. The next question is whether vendors patch the protocol itself or whether the ecosystem spends the next year papering over the same design choice in every implementation.

Teams that rely on AI agents should ask one direct question this week: if an attacker controls an MCP command string, what exactly stops it from running?