BlueRock Security's analysis of roughly 7,000 public MCP servers found that 41% require no authentication at all, 36.7% are vulnerable to server-side request forgery, 53% of authenticated servers rely on static API keys, and only 8.5% use OAuth. Those numbers have been sitting in security research since early 2026, but most of the teams adding MCP servers to their Cursor or Claude Code setups have never seen them. Installing an MCP server feels like installing a browser extension. The security story is closer to opening a shell on your laptop and leaving it listening.
What the OX Security disclosure actually found
On April 15, 2026, OX Security published an advisory describing a flaw that lets anyone execute arbitrary OS commands on servers that integrate the Model Context Protocol. It is not a library bug and not a single vendor's mistake - it is a design choice baked into Anthropic's official SDKs.
The mechanism is simple. The flaw allows any process command passed to the MCP STDIO interface to execute on the host system regardless of whether it initializes a valid MCP server.
It is baked into Anthropic's official MCP SDKs across every supported programming language, including Python, TypeScript, Java, and Rust. If you built an MCP integration using the reference SDK, you inherited it.
The numbers: over 150 million total downloads, 7,000 publicly reachable servers, 14 CVEs already assigned, and more than 30 RCE issues affecting flagship products including LiteLLM, LangFlow, Windsurf, Cursor, Flowise, DocsGPT, and GPT Researcher.
When OX disclosed this to Anthropic, the response was blunt. Anthropic confirmed the behavior is by design and declined to modify the protocol, stating the STDIO execution model represents a secure default and that sanitization is the developer's responsibility.
Anthropic subsequently updated its SECURITY.md file nine days after OX's initial contact to note that STDIO adapters should be used with caution, but made no architectural changes to the SDK.
A documentation note is what you ship when you cannot ship a patch. It transfers the responsibility of remembering the warning onto every developer who touches the SDK from now until forever.
The authentication problem runs deeper than one CVE
The OX disclosure is the loudest alarm, but it is not the only one.
An analysis of 2,614 MCP implementations found that 82% use file system operations prone to path traversal, 67% use APIs related to code injection, and 34% are susceptible to command injection.
Knostic independently mapped 1,862 exposed MCP servers via Shodan and found all 119 manually verified servers granted unauthenticated access to internal tool listings. That is not a sample with some bad actors in it - it is every single verified server in the sample.
A landmark April 2026 disclosure by OX Security confirmed that an architectural flaw baked into official MCP SDKs across Python, TypeScript, Java, and Rust exposes over 150 million downloads, 7,000 publicly accessible servers, and up to 200,000 total vulnerable instances to remote code execution.
There is also a specific, demonstrated attack path worth knowing. BlueRock discovered a security gap in Microsoft's Markitdown MCP server that enables SSRF, privilege escalation, and AWS account takeover via unbounded URI calls.
The research started by filtering servers with SSRF findings on high-adoption examples - Microsoft's Markitdown MCP server has 85,000 stars on GitHub - then deploying an instance and evaluating it for security gaps. Popularity is not a proxy for safety.
Security researchers filed over 30 CVEs against MCP servers in a single 60-day window in early 2026, and Trend Micro separately found 492 MCP servers publicly exposed with zero authentication.
What teams should actually do before connecting a server
MCP security is not a reason to stop using MCP. The 2026-07-28 spec revision makes things materially better - it delivers a stateless core, tighter OAuth and OpenID Connect alignment, and a formal deprecation policy so the protocol can evolve without breaking what you have built. But the new spec does not retroactively fix servers built on the old one, and it does not protect you from what is already in the registries.
Here is a short checklist worth running before any new MCP server goes near production credentials:
Check authentication first. Does the server require auth, and is it OAuth or a static key? BlueRock's Trust Registry evaluates MCP servers across 22+ security rules covering exposure and authentication, tool risk, data and egress, and runtime dependencies including unpinned packages and CVEs. Running a server through it before install costs minutes.
Read the tool definitions, not just the README. Tool poisoning - where a malicious tool definition overrides a benign one - is a documented attack class. About 5.5% of 1,899 servers showed tool poisoning in one academic study; a separate AgentSeal scan of 1,808 servers reported 66% had some security finding.
Run servers with the minimum process privileges you can. Microsoft's own guidance on their Markitdown GitHub repo notes that the server does not support authentication and runs with the privileges of the user running it, recommending the server be bound to localhost when in SSE or Streamable HTTP mode. Most quickstarts skip that sentence.
Pin package versions. Unpinned dependencies are a documented risk category in BlueRock's ruleset; a rug-pull (silent tool redefinition after install) has been demonstrated in the wild.
Isolate credentials per server. Give each MCP server its own scoped API key, not your personal or team-wide credentials. If a server is compromised, the blast radius stays contained.
Prefer servers that have shipped a CVE response. A server with a patched CVE is almost certainly safer than one with no security history at all - it means someone was watching.
Beagle in action#infra-team, 10:52amThe practical reality for small teams: you are probably running three to five MCP servers - filesystem, GitHub, maybe a Slack or Notion connector - and you almost certainly have not audited their tool definitions or scoped their credentials separately. That is where the risk actually lives, not in abstract vulnerability statistics.
Over 13,000 MCP server implementations were created on GitHub in 2025 alone, with the protocol adopted across every major IDE, AI assistant, and automation platform by early 2026. This rapid growth has outpaced security maturity by a significant margin. The ecosystem is moving faster than its security practices, and the teams connecting these servers to internal tooling are the ones who will find that out the hard way.
MCP server security: common questions
What makes MCP servers a security risk?
MCP servers sit between your AI agent and your tools, data, and credentials. A vulnerable server can be used to exfiltrate API keys, traverse your file system, or make requests to internal services. The root risk is that most MCP servers run with the full privileges of the user who launched them and, in 41% of cases analyzed by BlueRock, require no authentication from the calling agent.
Is the OX Security MCP vulnerability fixed?
Not at the protocol level. Despite over 30 responsible disclosures and more than 10 High/Critical CVEs filed, the root cause remains unaddressed at the protocol level. Individual frameworks like LiteLLM have shipped patches for their specific implementations. Anthropic's position is that input sanitization is the developer's responsibility.
Does the new MCP 2026-07-28 spec fix the authentication problem?
The new spec improves the situation. It aligns authorization more closely with OAuth and OpenID Connect deployments and introduces a formal deprecation policy. But it does not retrofit existing servers, and it does not force server authors to implement auth. You still need to vet each server individually.
How do I check if an MCP server is safe to install?
Run it through BlueRock's MCP Trust Registry (mcp-trust.com) before connecting it. Check whether it uses OAuth or a static API key. Read the tool definitions, not just the README. Run it in a sandboxed process with scoped credentials, and pin the package version so a silent update cannot redefine what the tools do.
Which AI coding tools are affected by MCP prompt injection?
Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI are all vulnerable to MCP-based prompt injection attacks.
Windsurf was the only IDE where exploitation required zero user interaction. Running these tools with only verified, scoped MCP servers is currently the best available mitigation.