A critical authentication bypass vulnerability in nginx-ui’s Model Context Protocol integration is being actively exploited in the wild, according to Recorded Future’s Insikt Group and BleepingComputer. CVE-2026-33032, which scores a 9.8 on the CVSS scale, allows any network attacker to invoke all 12 of nginx-ui’s MCP tools without authentication, including the ability to rewrite Nginx configuration files and trigger automatic reloads. Full server takeover requires two HTTP requests and zero credentials.

The vulnerability, codenamed MCPwn by the researchers at Pluto Security who discovered it, was patched on March 15, 2026 in nginx-ui version 2.3.4. The fix added 27 characters of code: a single missing middleware reference. But the exploit details and proof-of-concept emerged at the end of March, and active exploitation followed. Recorded Future assigned it a Risk Score of 94 out of 100, ranking it alongside critical vulnerabilities in Cisco, Microsoft, and Citrix products.

MCPwn is the first high-profile, actively exploited vulnerability targeting MCP infrastructure in production. For every team adding MCP support to their applications, it is a concrete case study in what happens when a protocol designed for capability gets deployed without containment.

What nginx-ui Does and Why It Matters

nginx-ui is an open-source web-based management interface for the Nginx web server. Instead of SSH-ing into boxes and editing configuration files by hand, administrators use a GUI to manage configs, SSL certificates, server status, and restarts. The project has over 11,000 stars on GitHub and more than 430,000 Docker pulls, according to Pluto Security’s analysis.

The project recently added MCP support, enabling AI assistants to manage Nginx configurations through natural language. Ask your AI assistant to “add a reverse proxy for my new API” and it creates the Nginx configuration directly. That capability requires exposing the application’s most sensitive operations through new HTTP endpoints.

Shodan scans by Pluto Security identified approximately 2,600 publicly exposed nginx-ui instances across more than 50 countries, concentrated on Alibaba Cloud, Oracle, Tencent, and DigitalOcean. The majority run on port 9000, the default nginx-ui backend port. Each exposed instance sitting in front of production traffic, APIs, and internal services was a potential MCPwn target.

The Vulnerability: Two Endpoints, One Missing Middleware Call

nginx-ui uses the SSE (Server-Sent Events) transport from the mcp-go library, which splits MCP communication across two HTTP endpoints. GET /mcp opens a persistent SSE stream for receiving responses. POST /mcp_message receives JSON-RPC tool invocations, handling every config write, every Nginx restart, and every file read.

The vulnerability is in the router code, as disclosed in nginx-ui’s security advisory:

The /mcp endpoint requires both IP whitelisting and authentication (AuthRequired() middleware). The /mcp_message endpoint requires only IP whitelisting. Both endpoints route to the exact same handler. The endpoint where every destructive operation happens skips authentication entirely.

The IP whitelist, the only remaining protection on /mcp_message, has a fatal default: an empty whitelist is treated as “allow all.” Every fresh installation permits all IPs through. As Security Affairs reported, two security mechanisms fail together, leaving any host on the network free to invoke any MCP tool.

The Attack: Network Access to Full Takeover in Seconds

According to Pluto Security researcher Yotam Perkal, who discovered and reported the flaw, exploitation requires exactly two HTTP requests:

  1. A GET /mcp request to establish an SSE session and obtain a session ID.
  2. A POST /mcp_message?sessionId=xxx request to invoke any MCP tool. No JWT. No cookies. No authentication headers of any kind.

From that single unauthenticated POST request, an attacker gains access to 12 MCP tools, seven of which are destructive. nginx_config_add creates new configuration files and automatically reloads Nginx. nginx_config_modify rewrites any existing configuration. restart_nginx restarts the entire process. Five read-only tools handle reconnaissance: reading any config file, enumerating all configurations, and viewing change history.

Pluto Security’s proof-of-concept, which they demonstrated from a separate machine on the network (not localhost, not the same container), completed the full attack chain: enumerating all 12 tools, exfiltrating the Nginx configuration, and injecting a new server block that Nginx immediately began serving.

The attack surface from there is comprehensive. An attacker can intercept all traffic by rewriting server blocks to proxy through a malicious endpoint. They can harvest administrator credentials by injecting log directives that capture Authorization headers. They can steal JWT secrets from nginx-ui’s settings API and forge permanent admin tokens. They can map the entire backend infrastructure by reading every configuration file. And they can kill the service entirely by pushing an invalid configuration and triggering a reload.

The Fix: 27 Characters

The patch in version 2.3.4, released one day after Pluto Security’s responsible disclosure, added , middleware.AuthRequired() to the /mcp_message endpoint. The same middleware that /mcp already had. One line of code. Twenty-seven characters.

The maintainers also added a regression test in commit 413dc63 that explicitly verifies both MCP endpoints return 403 when accessed without authentication, a test that would have caught the original oversight. BleepingComputer noted that the latest secure version is now 2.3.6, released last week with additional hardening.

The contrast between the attack’s impact and the fix’s simplicity is the architectural lesson. This was not a sophisticated cryptographic weakness or a novel exploitation technique. It was a missing function call on an endpoint that should have been protected from day one.

MCPwn in Context: The MCP Security Reckoning

MCPwn does not exist in isolation. It is the second critical MCP vulnerability that Pluto Security has disclosed in April 2026, and the broader MCP ecosystem is showing systemic security problems.

MCPwnfluence (CVE-2026-27825 and CVE-2026-27826): Pluto Security’s first MCP security disclosure targeted mcp-atlassian, the most widely used Atlassian MCP server. Two vulnerabilities, an SSRF and a path traversal, could be chained for full unauthenticated remote code execution from the local network. The MCP server’s HTTP transport defaulted to binding on 0.0.0.0 with zero authentication. Anyone who could reach the port could invoke any of its 40+ tools. Both CVEs were patched in mcp-atlassian >= 0.17.0.

Ecosystem-wide audit findings: A comprehensive analysis published in April 2026 found that 43% of public MCP servers are vulnerable to command execution. BlueRock Security reported 36.7% of over 7,000 servers are vulnerable to SSRF. Trend Micro identified 492 MCP servers exposed to the internet with zero authentication. Astrix Security found that 53% of servers use static credentials. CoSAI’s audit scored 17 MCP servers an average of 34 out of 100 on security. More than 30 CVEs were filed against MCP servers in a 60-day period in early 2026.

Even Anthropic’s own Git MCP server had three CVEs disclosed in January 2026, including path traversal and argument injection exploitable via prompt injection.

The pattern is consistent. MCP was designed for capability, not containment. When developers bolt MCP onto existing applications, the MCP endpoints inherit the application’s full capabilities but not its security controls. As Perkal told The Hacker News: “When you bolt MCP onto an existing application, the MCP endpoints inherit the application’s full capabilities but not necessarily its security controls. The result is a backdoor that bypasses every authentication mechanism the application was carefully built with.”

The Architectural Problem: MCP’s Missing Security Model

MCPwn exposes a design assumption baked into how most MCP integrations are built. The MCP specification defines a transport layer (SSE, stdio, streamable HTTP) and a tool invocation protocol (JSON-RPC). It does not define an authentication or authorization model. Authentication is left to the integrating application.

This creates a predictable failure mode. When a development team adds MCP support to an existing application, they must manually ensure that every MCP endpoint inherits the application’s existing security controls. If any endpoint is missed, the result is what nginx-ui’s router code demonstrated: an unauthenticated backdoor with full administrative capabilities, sitting alongside endpoints that require authentication.

The problem compounds at scale. Each MCP server integration is a new surface that must be independently secured. The mcp-go library, the mcp-atlassian library, and nginx-ui’s custom integration all failed in different ways, but the root cause was the same: MCP endpoints that were deployed without the authentication controls that the rest of the application enforced.

Cloudflare’s Agents Week (April 13-15) introduced MCP governance architecture through Cloudflare Mesh, which provides private networking and authorization controls for agent-to-agent communication. Broadcom’s Tanzu Platform Agent Foundations, announced at the AI in Finance Summit on April 15, takes a deny-by-default service binding model where agent capabilities must be explicitly whitelisted. Both architectures address the problem MCPwn exploited, but neither existed when nginx-ui shipped its MCP integration.

What to Do Now

If you run nginx-ui: Update to version 2.3.6 immediately, per BleepingComputer’s recommendation. If you cannot update immediately, add middleware.AuthRequired() to the /mcp_message endpoint as a workaround, or change the IP allowlisting default behavior from allow-all to deny-all.

If you run mcp-atlassian: Update to version 0.17.0 or later, which adds safe path validation and SSRF protections.

If you are adding MCP support to any application: MCPwn’s lesson is specific and actionable. Every MCP endpoint must carry the same authentication and authorization middleware as the application’s existing endpoints. The protocol will not enforce this for you. Default-open configurations (empty allowlists treated as “allow all,” servers binding on 0.0.0.0) must be replaced with default-deny. And regression tests should explicitly verify that MCP endpoints return 403 without authentication, the test that would have prevented MCPwn.

If you are evaluating MCP servers from the ecosystem: The April 2026 audit data shows that nearly half of public MCP servers have command execution vulnerabilities. Treat any third-party MCP server as untrusted infrastructure until you have reviewed its authentication model, network binding defaults, and tool permission scope.

The Pattern That Keeps Repeating

MCPwn’s 27-character fix is both reassuring and alarming. Reassuring because the vulnerability was straightforward to close. Alarming because it was straightforward to introduce. A single developer on a single commit omitted a single middleware reference, and the result was a CVSS 9.8 that Recorded Future ranked among the 31 most dangerous vulnerabilities exploited in March 2026.

The Model Context Protocol is growing fast. Hundreds of new MCP servers appear every week, wrapping critical infrastructure with varying degrees of security rigor. Every one of them is a potential MCPwn until its developers prove otherwise. The protocol’s power, giving AI agents direct access to production systems, is exactly what makes the authentication gap so dangerous. The tools that MCP exposes are not sandboxed experiments. They restart servers, rewrite configurations, and read sensitive files. When the endpoint protecting those tools is missing a 27-character middleware call, the gap between “AI-powered convenience” and “complete infrastructure compromise” is two HTTP requests.