MCPwn (CVE-2026-33032): One Missing Auth Check Turned nginx-ui's MCP Endpoint Into Unauthenticated RCE

The most expensive bugs are often the smallest. CVE-2026-33032, codenamed MCPwn by Pluto Security researcher Yotam Perkal, is a CVSS 9.8 authentication-bypass in nginx-ui — the popular web management UI for nginx — that hands an unauthenticated network attacker full control of the server. The root cause is a single missing function call. nginx-ui added Model Context Protocol (MCP) support and split the protocol across two HTTP endpoints. One of them shipped with the authentication middleware. The other did not.

This is the confused-deputy problem in its purest form. The MCP message endpoint is a deputy holding the full privileges of nginx-ui — it can write configuration files and restart the server — and it carries out instructions from anyone who can reach it over the network, because nobody told it to check who was asking. The fix, once the maintainers understood it, was roughly 27 characters of added code plus a regression test. The patch shipped in version 2.3.4, and the maintainers turned it around fast. But the window mattered: Recorded Future listed CVE-2026-33032 among the vulnerabilities actively exploited by threat actors, and Shodan showed roughly 2,689 exposed instances when the issue broke.

For security teams, MCPwn is a clean teaching case for an emerging failure mode: protocol integrations bolted onto existing admin tools inherit the tool's full privileges, but not always its authentication. As MCP support lands in more infrastructure software through 2026, this exact mistake — one route guarded, a sibling route forgotten — is going to recur. This post breaks down the mechanics, the detection signals, and the structural reason it happened.

TL;DR

• CVE-2026-33032 (MCPwn) is a CVSS 9.8 authentication bypass in nginx-ui's MCP integration, found by Yotam Perkal of Pluto Security.
• nginx-ui splits MCP across two routes. /mcp carries IP allowlisting plus the AuthRequired() auth middleware. /mcp_message — the route that actually invokes tools, writes config, and restarts the server — shipped with only IP allowlisting, and the default allowlist is empty, which the middleware treats as allow-all.
• An attacker opens an SSE stream to /mcp to get a fresh sessionID without credentials, then POSTs to /mcp_message to invoke any MCP tool — still unauthenticated. That means config write + server restart = RCE.
• Actively exploited in the wild (listed by Recorded Future); ~2,689 exposed instances on Shodan, concentrated in China, the U.S., Indonesia, Germany, and Hong Kong.
• Patched in nginx-ui 2.3.4 — a ~27-character fix plus a regression test.
• Monday morning: upgrade to 2.3.4+, take nginx-ui off the public internet, rotate node_secret / encryption keys, and audit config files for tampering.

What happened

nginx-ui recently added support for the Model Context Protocol so that AI agents could manage nginx configuration through tool calls. The implementation routes MCP traffic across two HTTP endpoints: /mcp for establishing the connection and /mcp_message for processing every subsequent tool invocation, including the operations that write configuration files and restart the server.

The /mcp endpoint was wired up correctly: it sits behind both IP allowlisting and the AuthRequired() authentication middleware. The /mcp_message endpoint was not. When the route was registered, the call that attaches the auth middleware was omitted, so /mcp_message enforces only IP allowlisting. And the default IP allowlist is empty — which the middleware interprets not as "deny all" but as "allow all." The net effect: the endpoint that does all the dangerous work is reachable, unauthenticated, by anyone on the network.

Pluto Security disclosed the flaw, the maintainers patched it in version 2.3.4, and the fix is famously small. As Pluto's writeup frames it: one missing function call on the route registration was enough to turn the MCP interface into an unauthenticated RCE gateway. Recorded Future subsequently listed CVE-2026-33032 among vulnerabilities being actively exploited by threat actors, and Shodan data put exposed instances at roughly 2,689 worldwide.

How the attack works

The exploitation path is two HTTP requests and requires no credentials.

Step 1 — Get a session. The attacker opens a Server-Sent Events (SSE) stream to /mcp. Despite the auth middleware on this route, the connection-establishment flow returns a fresh sessionID to the client. (Where authentication material is needed for the protocol handshake, a related flaw, CVE-2026-27944, exposes encryption keys via the /api/backup endpoint, allowing extraction of the node_secret parameter — but the core MCPwn bug does not depend on holding a credential.)

Step 2 — Invoke any tool. With the sessionID in hand, the attacker POSTs to /mcp_message to invoke any registered MCP tool. Because this route never checks authentication, the call succeeds. The registered tools include writing nginx configuration and restarting nginx-ui, so the attacker can write a malicious config and trigger an automatic reload, or modify config files and restart the service. That is full server takeover.

# Illustrative two-step flow (NOT functional exploit code).
# Step 1: open SSE stream, receive a sessionID with no credential.
GET /mcp HTTP/1.1
Host: target.example
Accept: text/event-stream

# server responds with an event carrying: sessionID=<fresh-id>

# Step 2: invoke a privileged MCP tool on the UNAUTHENTICATED route.
POST /mcp_message?sessionID=<fresh-id> HTTP/1.1
Host: target.example
Content-Type: application/json

{ "method": "tools/call",
  "params": { "name": "<config-write-or-restart-tool>", "arguments": { } } }

The elegance of the bug — from an attacker's view — is that nothing here is malformed. Both requests are exactly what a legitimate MCP client sends. The server happily processes them because the only gate that would have stopped step 2 was never installed on that route.

Detection

• Unauthenticated POSTs to /mcp_message. The cleanest signal is any request to /mcp_message that did not carry valid authentication, especially one that invokes a config-write or restart tool. If your access logs capture the route and auth state, alert on the combination.
• SSE to /mcp followed by /mcp_message from the same source without an auth event in between. Correlate the session establishment and the tool invocation; a session that never authenticated but reached /mcp_message is the exploit signature.
• Unexpected nginx config changes and reloads. File-integrity monitoring on nginx config files plus alerting on config-reload events not tied to a known change process will catch the payload even if you missed the request.
• /api/backup access from unexpected sources. Probes against the backup endpoint (CVE-2026-27944) to lift node_secret are a useful early indicator of an actor working the chain.
• Exposure check. Search your public ranges for nginx-ui. Any internet-reachable instance below 2.3.4 should be treated as presumed-targeted given confirmed active exploitation. Cross-reference Shodan if you have it.

What to do Monday morning

1. Upgrade to nginx-ui 2.3.4 or later. This is the fix. Do it first.
2. Take nginx-ui off the public internet. A server-management UI does not belong on a public IP. Put it behind a VPN or identity-aware proxy and confirm with an external scan. Do not rely on the IP allowlist alone — the empty default is exactly what bit everyone.
3. Set an explicit, non-empty IP allowlist even after patching, so a future regression cannot fail open the same way.
4. Rotate node_secret and encryption keys. If /api/backup was reachable (CVE-2026-27944), assume the key was extractable and rotate.
5. Audit nginx config and the nginx-ui database for tampering. Look for unexpected server blocks, proxy directives, or config reloads dated before the upgrade. Active exploitation means a backdoored config is a realistic outcome on exposed instances.
6. Review who could reach /mcp_message historically. If your logs do not distinguish authenticated from unauthenticated MCP calls, fix that logging so the next bug is detectable.

Why this keeps happening

MCPwn is a confused-deputy bug, and confused-deputy bugs cluster wherever a privileged component executes instructions on behalf of a less-privileged or unauthenticated caller. nginx-ui's MCP tools are the deputy: they hold the application's full authority to write config and restart services. The protocol layer was supposed to verify the caller's identity before letting the deputy act. On one of two routes, it did not.

The deeper pattern is that MCP support is being retrofitted onto existing admin tools, and the retrofit doesn't always inherit the tool's security model. A team that has spent years getting authentication right on its main API can split a new feature across two routes and forget to attach the middleware to one of them — especially when the protocol's transport model spreads a single logical operation across multiple HTTP endpoints. The empty-allowlist-means-allow-all default compounds it: a fail-open default plus a missing auth call equals an open door. As more infrastructure software ships MCP endpoints through 2026, every one of those integrations is a new deputy that needs its own complete authorization story, not a partial one copied from the route next door.

The structural fix

The honest framing: an upstream auth bug like this can only be prevented by the upstream maintainer, and nginx-ui fixed it fast. What a defender controls is exposure and dwell time. Treating every MCP endpoint as a privileged surface — inventoried, scoped, and monitored — is what shrinks the blast radius when an integration ships fail-open. MCP server governance gives you an inventory of which MCP servers exist and which tools they expose, so a config-write/restart-capable surface on a public IP shows up as a finding rather than a surprise. MCP server security and capability scoping push toward the principle MCPwn violated: a tool that can restart a server should require explicit, authenticated authorization on every invocation, and no route should reach it without one. None of this patches nginx-ui for you, but it shortens the time between "an MCP endpoint failed open" and "we noticed."

What we know we don't know

• Scope of successful compromise. Active exploitation is confirmed (Recorded Future), and ~2,689 instances were exposed, but the number actually compromised, and any victim names, were not public at disclosure.
• node_secret chaining in the wild. Whether attackers routinely chained CVE-2026-27944 to lift keys, or simply abused the unauthenticated /mcp_message route directly, is not fully documented publicly.
• Patch-version dates. Reporting cites both March 15, 2026 and disclosure timing around mid-April for the 2.3.4 fix and advisory; treat the precise release date as approximate. The actionable fact — upgrade to 2.3.4+ — is unambiguous.

References

• The Hacker News — Actively Exploited nginx-ui Flaw (CVE-2026-33032) Enables Full Nginx Server Takeover: https://thehackernews.com/2026/04/critical-nginx-ui-vulnerability-cve.html
• Pluto Security — MCP Bug in Nginx: Critical CVSS 9.8 Security Vulnerability (MCPwn): https://pluto.security/blog/mcp-bug-nginx-security-vulnerability-cvss-9-8/
• Rapid7 — ETR: CVE-2026-33032 Nginx UI Missing MCP Authentication: https://www.rapid7.com/blog/post/etr-cve-2026-33032-nginx-ui-missing-mcp-authentication/
• SentinelOne Vulnerability Database — CVE-2026-33032: https://www.sentinelone.com/vulnerability-database/cve-2026-33032/
• Security Affairs — CVE-2026-33032: severe nginx-ui bug grants unauthenticated server access: https://securityaffairs.com/190841/hacking/cve-2026-33032-severe-nginx-ui-bug-grants-unauthenticated-server-access.html
• PoC / write-up — keraattin/CVE-2026-33032 (GitHub): https://github.com/keraattin/CVE-2026-33032

Internal Safeguard resources:

• MCP Server governance
• MCP server security
• Capability scoping
• Govern AI agents
• Policy enforcement
• Incident response