The 2026 MCP CVE Wave: MCPwn, MCPoison, and the First MCP Bug on a Known-Exploited List

For most of 2025, the security conversation around the Model Context Protocol was theoretical. Researchers described tool poisoning, confused-deputy attacks, and supply-chain risk as things that could happen if MCP adoption kept accelerating. By the middle of 2026, that framing is obsolete. Three vulnerabilities — one on each side of the MCP connection and one at the trust boundary between them — have moved MCP from “emerging attack surface” to “actively exploited attack surface that appears on the same lists that drive enterprise emergency-patching cycles.”

This post walks through the three CVEs that define the 2026 MCP wave, what each one actually exploits, and why the most important pattern is not any single bug but the architectural gap all three share.

CVE-2026-33032 “MCPwn”: Two Requests, Zero Credentials, Full Server Takeover

The most consequential of the three is CVE-2026-33032, codenamed “MCPwn.” It is a CVSS 9.8 authentication bypass in nginx-ui, an open-source management interface for Nginx that exposes an MCP integration so that operators can drive configuration tools — edit server blocks, reload, run backups — through JSON-RPC.

The bug is almost embarrassingly small. nginx-ui registers two MCP HTTP endpoints. The /mcp endpoint is correctly guarded with an AuthRequired() middleware call. The paired /mcp_message endpoint — which is the one that actually receives tool invocations — was registered without that middleware. A single missing function call left the entire tool-invocation surface unauthenticated.

The exploit is two HTTP requests:

1. POST /mcp returns an SSE stream and a fresh session ID. No authentication required.
2. POST /mcp_message with that session ID invokes any of the twelve registered MCP tools, including the one that rewrites the Nginx configuration and triggers an auto-reload. No authentication required.

From there an attacker can redirect traffic, read TLS private keys off disk, stop or restart Nginx, or implant a persistent backdoor. Shodan data showed roughly 2,689 internet-exposed nginx-ui instances at disclosure, concentrated in China, the United States, Indonesia, Germany, and Hong Kong. The fix shipped in nginx-ui v2.3.4 and is, fittingly, the single missing line: middleware.AuthRequired() added to the /mcp_message handler. Anyone who ran a vulnerable version should also rotate the node secret, admin password hashes, and any TLS keys the process could read.

What makes MCPwn a milestone is not the severity score. It is that CVE-2026-33032 became the first MCP-specific CVE to land on a Known Exploited Vulnerabilities (KEV) list — the catalog that tells security operations teams “stop what you are doing and patch this now.” Recorded Future tracked it among the high-impact CVEs actively exploited in the wild. MCP vulnerabilities are no longer a research curiosity; they are on the same operational footing as the Exchange and Confluence bugs that defined prior patching emergencies.

CVE-2025-6514: The Client Side Was Vulnerable Too

If MCPwn proved the server side of an MCP connection could be taken over, CVE-2025-6514 proved the same about the client side — and it fires even earlier in the connection lifecycle.

mcp-remote is a widely used npm package that acts as a local bridge, letting desktop MCP clients such as Claude Desktop and Cursor connect to remote MCP servers over HTTPS and handle the OAuth flow on their behalf. JFrog’s security researchers found a CVSS 9.6 OS command injection in it. When mcp-remote performs OAuth discovery against a remote server, it reads the authorization_endpoint value from the server’s discovery response and passes it — unsanitized — into a shell command used to open the user’s browser.

A malicious server simply returns a crafted endpoint value containing shell metacharacters. On macOS and Linux the injection rides the open call; on Windows it rides start semantics. The result is arbitrary command execution on the client machine — and crucially, it happens during the OAuth handshake, before any MCP session is established and before any tool is ever invoked. Merely connecting to a hostile server is enough.

The package had been downloaded more than 437,000 times, and the affected versions (0.0.5 through 0.1.15) were in use at organizations integrating Cloudflare, Hugging Face, and Auth0 MCP servers. The fix is in v0.1.16. JFrog characterized it as the first confirmed full system compromise achieved through MCP infrastructure.

The structural lesson is broader than one package: any component that processes server-supplied OAuth metadata must treat that metadata as untrusted input before it reaches a system call. The MCP spec’s ongoing OAuth hardening work — including stricter issuer (iss) validation per RFC 9207 — is a direct response to exactly this class of metadata-injection attack.

CVE-2025-54136 “MCPoison”: Trust Granted Once, Never Re-Checked

The third CVE attacks neither endpoint directly. It attacks the assumption that a tool you approved yesterday is the same tool today.

CVE-2025-54136, named “MCPoison” by Check Point Research, is a rug-pull tool-poisoning vulnerability in the Cursor IDE (CVSS 7.2). The attack chain reads like a social-engineering screenplay:

1. An attacker contributes a benign .cursor/rules/mcp.json to a shared repository.
2. A developer reviews the harmless MCP configuration and approves it.
3. The attacker later swaps the registered server definition for a malicious payload.
4. Cursor never re-validates a previously approved configuration.
5. Every subsequent launch silently runs attacker-controlled commands with full ambient authority.

The root cause is trust-at-registration-time with no re-validation at invocation-time. Once approved, always trusted — regardless of what the definition now says or whether its content hash has changed. Its companion bug, CVE-2025-54135 (“CurXecute”), is the same structural flaw in the same IDE. Both were patched in Cursor v1.3. Together they put IDE-based tool poisoning on the map as a systematic class rather than a one-off.

The Pattern Underneath the Three Bugs

It is tempting to read these as three unrelated bugs in three unrelated products. They are not. Lined up, they describe a single weakness that recurs at every layer of an MCP deployment:

CVE	Layer	Root cause
MCPwn (CVE-2026-33032)	Server endpoint	Authentication applied inconsistently across MCP routes
mcp-remote RCE (CVE-2025-6514)	Client proxy	Untrusted server metadata reaches a system call
MCPoison (CVE-2025-54136)	Registration boundary	Trust granted once and never re-validated

The common thread is that MCP integrations are repeatedly bolted onto existing software, and the security controls that the surrounding application takes for granted — consistent authentication, input sanitization, re-validation of changed configuration — are not automatically inherited by the MCP surface. The protocol is, in the NSA’s own words from its May 2026 guidance, “flexible and underspecified, with security left as an afterthought for implementers.” Each implementer rediscovers the same gaps.

That is why the durable defense is architectural rather than a sequence of patches. Patching nginx-ui closes MCPwn; it does nothing for the next application that forgets an auth check. The pattern that addresses all three classes at once is an admission-control gateway sitting between clients and MCP servers, enforcing three properties that none of the three vulnerable components enforced on their own:

• Authenticated-by-default dispatch. No tool call reaches any server on an unauthenticated path, because authentication is the architectural default rather than an optional middleware that a route can omit. This is the property nginx-ui lacked.
• Admission before connection. A newly added server cannot receive any request — not even an OAuth discovery request — until an operator has reviewed and approved it. This is the property that neutralizes the mcp-remote class: the malicious authorization_endpoint is never fetched, because the connection is never initiated against an unapproved server.
• Re-validation on change. A server’s definition is hash-bound at approval, and any drift returns it to a pending state requiring re-approval. This is the property Cursor lacked, and the one that turns MCPoison from a silent compromise into a blocked change.

Open-source, self-hosted gateways such as MCPProxy implement this “quarantine-first” admission model precisely because the failure mode is so consistent across the ecosystem. The point is not which gateway you choose; it is that a gateway enforcing admission control, authenticated dispatch, and re-validation converts three different CVE classes into three blocked operations — without depending on every upstream MCP server, client proxy, and IDE getting its own security exactly right.

What to Take Away

The 2026 CVE wave is a turning point in how MCP security should be reasoned about. Three facts are now established by real, exploited bugs rather than by speculation: an MCP server endpoint can be taken over with zero credentials, an MCP client proxy can be compromised before a single tool runs, and an approved tool can quietly become a malicious one. MCP vulnerabilities have reached the Known-Exploited lists that drive enterprise patching.

For anyone running MCP in production, the practical response is to stop treating each CVE as an isolated patch and start treating the connection between agents and tools as a boundary that needs its own enforcement layer. Patch the known bugs, certainly. But the bugs will keep coming, in roughly the same shapes, from the long tail of MCP integrations still being written. The boundary is what you can actually defend.