The MCP CVE Wave Didn’t Crest — It Broke Wider: A Second SDK, the Vendors’ Own Servers, and the First Exploited-in-the-Wild Bug

In July 2026 we documented the first wave of Model Context Protocol CVEs — more than a dozen in ten days, three in the official MCP Python SDK — and argued it had stopped being a run of coincidences and become a category. Six weeks later, that argument is no longer arguable. The wave did not crest. It broke wider.

A second official SDK — this time for Ruby — shipped the exact same class of bugs the Python SDK did. The platform vendors building the ecosystem — GitHub, AWS, Apify, n8n — landed MCP flaws in their own servers. Langflow became the first vulnerability in this ecosystem to be added to CISA’s Known Exploited Vulnerabilities catalog, confirmed under active attack. And a genuinely new class of AI-native bug appeared: prompt injection that lands not in a shell, but in your database query language.

A second official SDK, the same three bugs

If the July wave had a headline, it was that the reference MCP Python SDK — the code most servers are built on — shipped missing Origin validation (CVE-2026-59950, the DNS-rebinding bug) and unverified session handling (CVE-2026-52869). The most telling development since is that the official MCP Ruby SDK now has the exact analogues.

• CVE-2026-63118 — the Ruby Streamable-HTTP transport validates content-type and headers on every request but never checks Host or Origin, the same DNS-rebinding gap as the Python SDK’s CVE-2026-59950.
• CVE-2026-67431 — “SSE Session Poisoning”: missing session-ownership validation lets an attacker execute tools using a stolen session ID, the Ruby echo of the Python SDK’s unverified-principal bug.
• CVE-2026-67432 / -63119 / -67430 — a cluster of unbounded-allocation denial-of-service flaws (JSON-RPC body, stdio line buffer, session retention) in the same transport.

When two independent official SDKs, in two different languages, ship the same authentication and origin-validation gaps, it is no longer an implementation slip. It is a design-level assumption — “a trusted local caller” — baked into the protocol’s reference code and inherited by everything built on top.

The vendors building the ecosystem shipped it too

It would be easier to dismiss the July wave as hobby projects if the companies defining the AI-agent platform were not in the same list. They are.

• CVE-2026-47427 — GitHub’s own MCP Server: an unauthenticated client can crash it with a nil-pointer dereference in the completions handler (DoS).
• CVE-2026-16584 — the AWS API MCP Server loads its deny/gate security policy once at startup; if that data fails to load (a network blip at boot), it fails open and enforces nothing.
• CVE-2026-50143 — Apify’s MCP server leaks its Apify API token through path-authority injection (unvalidated concatenation of a trusted base URL with an attacker-controlled path).
• CVE-2026-59207 — n8n’s AI-Agents MCP connector bypasses the “Allowed HTTP Request Domains” allow-list, turning a guardrail into an SSRF primitive.

These are not exotic memory-corruption bugs. They are authentication, origin checks, allow-lists, and fail-closed defaults — the security basics — skipped because MCP still gets treated as a developer convenience rather than the privileged, credential-holding production service it actually is.

The theoretical became real: Langflow, exploited in the wild

The July wave was, mercifully, mostly disclosure ahead of exploitation. That window has closed. Langflow — a popular visual builder for AI workflows — carries CVE-2026-0770, an “inclusion of untrusted functionality” flaw that yields remote code execution, and it has been added to CISA’s KEV catalog as actively exploited. A companion flaw, CVE-2026-55255, is an authorization bypass that lets one user reach another user’s flows. An internet-reachable Langflow instance is now a live target, not a hypothetical.

“You cannot put an AI agent inside your trust boundary and leave its front door open to the internet — and now that door ships open by default, from a dozen vendors at once.”

A new class arrives: prompt injection into your query language

The most forward-looking entry in this wave is Langroid’s CVE-2026-55615. Its Neo4jChatAgent takes a natural-language request, has the model generate a Cypher graph query, and executes that query without validation. An attacker who can influence the prompt can influence the generated query — prompt-to-Cypher injection, the direct descendant of prompt-to-SQL. It is a reminder that AI tooling does not only inherit old vulnerability classes; it invents new ones, where the untrusted input is the model’s own output.

The root causes have not moved

Strip the product names away and the second wave repeats the first, almost line for line:

• Missing Origin / Host validation — the DNS-rebinding class, now in a second official SDK.
• Missing session or principal verification — unauthenticated tool invocation, whether by design default or stolen session.
• SSRF through unvalidated URLs — the recurring primitive for reaching internal networks and leaking secrets.
• Token and secret leakage — servers that hold API keys and hand them to attacker-controlled destinations.
• Fail-open defaults — bind-to-all-interfaces, oauth-disabled, policy-not-loaded: insecure unless someone remembers to lock it down.

Why your scanners still walk past all of it

A classic vulnerability scanner fingerprints known products and CVEs on known ports. An MCP server is JSON-RPC over HTTP or SSE, often on a nonstandard port, with no banner and no version string — it does not announce itself. Detecting one means speaking the protocol: completing the MCP initialize handshake and reading the posture back, read-only, without ever invoking a tool. That is why attack-surface discovery has to be protocol-aware to catch any of this, and why the count of exposed AI infrastructure keeps rising while traditional scans stay quiet.

CATAAM’s attack surface management fingerprints exposed MCP servers directly — completing the handshake, checking for unauthenticated capability disclosure and missing Origin validation, and raising each as a finding mapped to your controls. For the credentials these servers hold, Prompt Guard keeps secrets from crossing into the model context in the first place.

What it means for the frameworks you already passed

Every flaw in this wave undoes a control you were certified against — logical access (SOC 2 CC6.1) and boundary protection (CC6.6) most directly, and, because these are AI systems making decisions on your behalf, the governance and impact-assessment expectations of ISO/IEC 42001. We read one such advisory line-by-line through the frameworks in The Tool Nobody Reviewed. The July wave made that a pattern; the second wave makes it the default posture of an entire tooling ecosystem — one you almost certainly already have somewhere on your network.

Frequently asked questions

What is the MCP CVE wave?

Beginning in July 2026, security researchers disclosed dozens of vulnerabilities in Model Context Protocol (MCP) servers — the middleware that lets an AI model call real tools. The flaws share a small set of root causes: servers designed for localhost, exposed to the network without authentication, Origin validation, or fail-closed defaults. The wave has since widened to a second official SDK (Ruby), the platform vendors’ own servers (GitHub, AWS, Apify, n8n), and the first actively-exploited case (Langflow).

Is any MCP or AI-tooling vulnerability being actively exploited?

Yes. Langflow’s CVE-2026-0770 (an “inclusion of untrusted functionality” flaw leading to remote code execution) has been added to CISA’s Known Exploited Vulnerabilities catalog as exploited in the wild, alongside an authorization-bypass flaw, CVE-2026-55255. Any internet-reachable Langflow instance in an affected version should be treated as an emergency.

What is CVE-2026-0770 in Langflow?

CVE-2026-0770 is a critical vulnerability in Langflow, a visual builder for AI/LLM workflows, classified as inclusion of functionality from an untrusted control sphere and resulting in remote code execution. It is on CISA’s KEV list as actively exploited. It should be patched immediately and the instance treated as potentially compromised if it was internet-reachable before patching.

Why do so many MCP servers have the same vulnerabilities?

Because the flaws are design-level, not one-off bugs. MCP was built for a local model talking to local tools over loopback, so its reference implementations assumed a trusted local caller. When two independent official SDKs (Python and Ruby) ship the same missing Origin validation and unverified-session bugs, it confirms the assumption — not the code — is the problem, and every server built on those SDKs inherits it.

How do I find exposed MCP servers and AI tooling on my network?

Traditional scanners miss them because MCP is JSON-RPC over HTTP or SSE with no banner, often on nonstandard ports. Detection must be protocol-aware: complete the MCP initialize handshake to confirm a real server, then check whether it answers tools/list without authentication and whether it accepts a foreign Origin — read-only, never invoking a tool. Continuous external attack-surface discovery that speaks the protocol will surface these as findings mapped to your compliance controls.

What is prompt-to-Cypher or prompt-to-SQL injection?

It is an AI-native injection class where a language model turns a natural-language request into a database query (Cypher for graph databases, SQL for relational ones) and the application executes that query without validation. An attacker who influences the prompt influences the generated query. Langroid’s CVE-2026-55615 is a prompt-to-Cypher example; the defense is to treat model-generated queries as untrusted input — parameterize, sandbox, and constrain them like any other user input.