MCP Server Security: October CVE Wave Exposes Protocol Trust Gap

A month of the same mistakes

October 2026 has made one thing hard to deny. The weak point in agentic AI is no longer only the model. It is the Model Context Protocol (MCP) server that gives the model hands. In about two weeks, disclosures piled up across reference code, official SDKs and popular third-party integrations. Very few of them were new kinds of bug. Most were familiar weaknesses turning up again in new codebases.12

The list is long. On October 5, Langflow disclosed a remote code execution flaw rated CVSS 9.9. The product ran the command field from MCP server configurations through bash -c with no allowlist, so any authenticated user could run operating system commands. A public proof of concept exists, and fixes shipped in versions 1.9.0 and 1.10.3.12 Three days earlier, a server-side request forgery (SSRF) bug rated 7.3 was published against the fetch_url tool in the project's own mcp-server-fetch package. That means the reference implementation, the code many developers copy, carried the flaw.12 On October 9, an x64dbg MCP server was found exposing every debugger function over unauthenticated HTTP on all network interfaces. Anyone who could reach it could read and write process memory.12

Outside the server code itself, Cycode disclosed an account-takeover flaw in Anthropic's official MCP Python SDK. A malicious server could abuse a fallback discovery path in the OAuth flow. The user would still see a genuine Google, Okta or Azure AD login page, while the client secret, authorization code and PKCE proof key were sent to an attacker-controlled token endpoint.17 The bug affected versions 1.9.1 through 2.1.1. It also exposed machine-to-machine setups that need no user interaction, and fixes landed in 1.30.0 and 2.2.0.17 Cycode's Robbins pointed out the lasting cost. An attacker keeps that access for as long as the stolen client secret goes unrotated, so updating the package alone does not end the exposure.17

Enterprise vendors are affected as well. Splunk patched CVE-2026-76404, a CVSS 9.1 insecure-deserialization RCE in its MCP Server's credential management component, in version 1.2.1.11

The repeat bug: SSRF across three continents

The clearest example of the pattern comes from Syed Anas Mohiuddin, an independent researcher based in Chicago. Over five months he reported the same SSRF weakness in MCP implementations at Google, JPMorgan Chase, a French government directorate, a vector database company and the city government of Tangerang, Indonesia. Five unrelated teams confirmed and fixed it.14

The details show how routine the mistake is. Google's MCP Toolbox for Databases used a standard Go HTTP client with no redirect policy and no check on destination IP addresses. Google rated the advisory High, scoring 8.0 under CVSS v4.14 JPMorgan's documentation-search server had two content-fetching tools. One applied a domain allowlist. The other, called related(), fetched any URL a caller supplied.14 Tangerang's Wazuh MCP server claimed in its documentation that it blocked private IP addresses. In practice it rejected only literal IP strings, not hostnames that resolve to private addresses.14

These gaps matter because DNS rebinding and redirect chains defeat simple allowlists. Once an attacker can reach cloud metadata endpoints such as 169.254.169.254, they can collect IAM credentials for the infrastructure the server runs on.14

The least comfortable finding concerns the US government. Mohiuddin filed five private advisories on September 2 against MCP servers run by the General Services Administration's Technology Transformation Services. Six weeks later, none had been patched. One server, which handles Veterans Affairs benefits claims, reportedly writes veterans' names, Social Security numbers and dates of birth into unredacted error responses.14 No public patch timeline has been announced.14

Why this keeps happening: the spec has no security floor

On the root cause, the coverage largely agrees. MCP, now governed by the Agentic AI Foundation under the Linux Foundation, sets no mandatory (normative) security requirements. Each implementer has to work out the same defenses alone, and many don't.14 The NSA reached a similar conclusion in its May 2026 design guidance. It noted that the specification leaves key security properties to implementers, and that gaps in token passthrough and session lifecycle handling allow insecure deployments.45

Academic work suggests the design itself raises the risk. A January 2026 arXiv analysis identified three protocol-level weaknesses:

• servers declare their own capabilities, and nothing verifies those claims
• sampling requests carry no origin authentication, so a server can inject prompts that look like user input
• trust carries over implicitly between servers in multi-server setups

Across 847 attack scenarios, the authors found that MCP raised attack success rates by 23 to 41 percent compared with equivalent integrations that did not use MCP.2 Success rates climbed as more servers were connected, reaching 78.3 percent with five servers. Adding a defensive instruction to the system prompt cut cross-server attacks only from 61.3 to 47.2 percent.1 The point is that asking the model to behave does not replace enforcement at the protocol level.

More capable models do not solve this either. The MCPTox benchmark measured attack success rates of up to 72.8 percent across 20 agents and 45 real servers, and the stronger models were more vulnerable.12 Security vendor ClawSecure says every one of 14 models it tested failed to reliably block malicious instructions. ClawSecure sells a product, though, and its platform-layer claims have not been independently replicated.11

Where the numbers diverge

Anyone trying to size the problem should be careful with the statistics. One estimate holds that nearly 7,000 MCP servers were exposed to the internet by early 2026, about half with no authentication.10 A separate BlueRock Security scan of more than 7,000 servers found 41 percent lacked authentication and 36.7 percent were vulnerable to SSRF.14 OX Security's figures are often summarized as about 7,000 publicly reachable servers, plus an estimate that over 200,000 could be compromised through an SDK design choice involving STDIO command execution.8 Those figures measure different things. The 7,000 counts servers reachable from the internet. The 200,000 is a model of potential exposure.

CVE counts vary for the same reason. One mid-year tally gave 14 assigned CVEs and more than 30 RCE issues sharing a root cause.8 Another count put the number of CVEs filed in January and February alone above 30.14 Even the Python SDK disclosure is listed under an inconsistent 2024-era CVE identifier in one threat-intelligence writeup.20 That suggests the tracking infrastructure is struggling to keep up. The overall direction is consistent across all of it, even where the exact figures disagree.

The servers are also the supply chain

The risk is not limited to buggy code. A malicious server can poison a model through tool descriptions the user never sees, a technique Invariant Labs disclosed in April 2025.18 CyberArk later showed that injected instructions can also hide in parameter names, default values, enum options and error messages.8 The NSA described a WhatsApp case in which a malicious server behaved normally at installation and switched to hostile instructions after its second use.4 That "rug pull" pattern played out for real with the postmark-mcp package, which published fifteen clean releases before an update quietly blind-copied (BCC) every agent-sent email to an attacker.12

A useful counterpoint, and its limits

Not every analyst sees this as a crisis for every team. One argument holds that much of the published threat model assumes servers come from outside sources. Servers that are written, reviewed, containerized and given credentials in-house remove most supply-chain risk.19 Even that view accepts three remaining problems: prompt injection through any data a server pulls in, OAuth scopes that grow too broad, and gaps in audit logging.19 The Cloud Security Alliance offers a similar corrective. It found that the most damaging incidents to date, including the GitHub MCP injection and Asana's cross-tenant exposure, came from basic failures such as overly broad tokens and access-control mistakes, not exotic exploits.10

That, in my view, is the right way to read October. Writing MCP servers in-house helps, but it does not remove the risk. Mohiuddin's targets were large, capable engineering organizations, and they still shipped the same SSRF bug.14

What changes now

The market is already responding. Radware has launched MCP-specific protection aimed at server discovery, tool enumeration, authentication attacks and AI-driven tool flooding.13 Splunk-focused analysis points to MCP-aware gateways, such as Google's Agent Gateway, as a way to enforce policy at the protocol layer.11 The protocol's own evolution brings new risks too. Akamai's Du'An Lightfoot notes that removing session IDs in the new specification moves risk onto client-held state and long-running task tickets, which become both theft targets and a denial-of-service lever.15

The practical baseline for teams running MCP today is clear from the coverage:

• Treat every MCP server as an untrusted endpoint and require independent authorization for tool calls.11
• Resolve and validate the destination of every URL a caller supplies, so redirects and rebinding can't reach internal addresses.14
• Scope credentials narrowly; the Supabase demonstration showed a single over-privileged role turning a support ticket into a data leak.18
• Patch the October disclosures, and rotate any client secrets exposed through the Python SDK flaw.17

MCP's big draw is that it lets agents connect to anything quickly, and with no security floor in the specification, that same convenience is what creates the risk. One estimate puts installs at 97 million, with a registry nearing 2,000 entries.12 Until the specification sets mandatory security requirements, defense will depend on each deployment. That is the arrangement that produced this month's run of disclosures.