CVE-2026-33032: The nginx-ui MCP Vulnerability That Hands Attackers Full Server Control

Someone decided to add Model Context Protocol support to nginx-ui, a web-based Nginx management tool. Then they exposed two HTTP API endpoints for that MCP integration. Then they forgot to put authentication on one of them. The one that controls everything.

CVE-2026-33032. CVSS score: 9.8. Codenamed MCPwn by Pluto Security. Actively exploited. About 2,689 instances exposed to the public internet right now.

This one is infuriating in the specific way that only configuration logic failures can be, because the authentication code exists. It is right there in the codebase. Someone just did not apply it to the endpoint that matters.

What nginx-ui Is

nginx-ui is an open-source, web-based management tool for Nginx -- the web server and reverse proxy that runs a significant portion of the internet's infrastructure. You install nginx-ui, point it at your Nginx instance, and you get a browser-based interface for managing server configurations, reloading settings, monitoring traffic, and running administrative tasks without touching a terminal.

It is popular in self-hosted and homelab environments, on VPS deployments, and in smaller operations that want a GUI layer over their Nginx setup. The Shodan data shows 2,689 publicly reachable instances, concentrated in China, the U.S., Indonesia, Germany, and Hong Kong.

The MCP integration was added to let nginx-ui participate in Model Context Protocol workflows -- the standard that Anthropic developed for connecting AI assistants to external tools and systems. nginx-ui exposes MCP endpoints so AI agents can query and control Nginx configurations through a standardized protocol. In theory, this lets you build automated workflows where an AI assistant monitors and adjusts your server configuration based on traffic patterns or health checks.

In practice, it created a backdoor.

The Vulnerability, Explained

nginx-ui's MCP integration exposes two endpoints:

• /mcp -- handles session establishment, requires both IP whitelisting and authentication via the AuthRequired() middleware
• /mcp_message -- handles actual MCP tool invocations, requires only IP whitelisting
  The critical detail: the default IP whitelist is empty. The middleware that implements IP whitelisting treats an empty whitelist as "allow all."

So /mcp_message -- the endpoint that executes commands -- is wide open to any network attacker by default. The authentication gate only covers /mcp, not the endpoint that actually does things.

An attacker with network access to your nginx-ui instance can invoke MCP tools directly through /mcp_message without any credentials. Those tools include restarting Nginx, creating, modifying, and deleting Nginx configuration files, and triggering automatic config reloads.

Full server takeover. No authentication required.

The Two-Request Attack Chain

Researcher Yotam Perkal at Pluto Security identified and documented the attack path. The chain works as follows:

Step 1: The attacker needs a session ID to talk to /mcp_message. Getting one from /mcp requires authentication. But nginx-ui versions prior to 2.3.3 carry a separate vulnerability, CVE-2026-27944 (CVSS 9.8), which exposes the encryption keys needed to decrypt system backups without authentication via the /api/backup endpoint.

An unauthenticated attacker hits /api/backup, downloads a full system backup, and extracts the contents. Inside that backup: user credentials, SSL private keys, Nginx configurations, and a query parameter called node_secret -- the authentication token for the MCP interface.

Step 2: The attacker passes node_secret to /mcp in an HTTP GET request. This yields a session ID.

Step 3: The attacker sends an HTTP POST to /mcp_message using that session ID. From this point, they can invoke any MCP tool without further authentication.

That is the chain: one backup download, one session establishment, then unlimited command execution. Pluto Security describes full takeover in seconds via two requests.

With /mcp_message access, an attacker can rewrite Nginx configs to route all traffic through an attacker-controlled server, intercept HTTPS traffic by injecting malicious certificate handling, harvest administrator credentials from the management interface, and restart the server with the modified configuration to activate changes immediately.

What This Means for Traffic Interception

The last item in that list deserves more attention. Nginx sits in front of your applications. Traffic flowing through it includes authentication headers, session tokens, API keys, and user data depending on your setup. An attacker who controls the Nginx configuration controls what gets logged, what gets forwarded, and what gets inspected.

Rewriting a proxy configuration to route traffic through an attacker's server is not a complex operation. It takes one config file change and a server reload -- both of which /mcp_message can execute directly. This is not theoretical. The MCP tools were designed specifically to perform these operations.

Where MCP Security Goes Wrong

Yotam Perkal put it clearly: "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."

This is the failure pattern that shows up every time a new integration layer gets added to an existing system. The core application spent years building authentication flows, permission checks, and rate limiting. The MCP layer arrives, plugs into the same underlying functions, and the developers apply security controls inconsistently because the integration was built quickly or the threat model was not revisited.

nginx-ui had authentication. /mcp required it. /mcp_message did not. This is not a cryptographic failure or a memory safety issue. An engineer wrote middleware that checked credentials, then did not apply it to the command execution endpoint. Given that MCP integrations are appearing across dozens of applications right now, expect this pattern to keep showing up.

The same week this disclosure landed, researchers found two vulnerabilities in the Atlassian MCP server (CVE-2026-27825 and CVE-2026-27826, collectively called MCPwnfluence) that chain together to achieve remote code execution from the local network without authentication. The MCP security problem is not a single vendor issue.

The Recorded Future Context

Recorded Future's March 2026 CVE landscape report listed CVE-2026-33032 among 31 vulnerabilities actively exploited by threat actors in March 2026. The exploit disclosure came from responsible coordinated disclosure -- the nginx-ui maintainers published the advisory and released the fix in version 2.3.4 on March 15, 2026.

The problem: patch adoption is not instant. Shodan shows 2,689 exposed instances. Some percentage of those remain on pre-2.3.4 versions. Attackers are scanning for them.

What You Need to Do

If you run nginx-ui:

Update to version 2.3.4 immediately. The release is available on GitHub. This is the only fix that addresses the root cause.

If you cannot update immediately, two mitigations reduce exposure:

1. Add middleware.AuthRequired() to the /mcp_message endpoint in the codebase to force authentication on command execution
2. Change the IP allowlisting default behavior from "allow-all" to "deny-all," and explicitly whitelist only trusted IP ranges
   Disabling MCP functionality entirely is a valid interim measure if you do not use it. The MCP integration is optional for basic nginx-ui functionality.

If you run Nginx without nginx-ui:

This vulnerability does not affect the Nginx server itself. CVE-2026-33032 exists only in nginx-ui, the management interface. Core Nginx is unaffected.

For teams running other applications with MCP integrations:

Audit your MCP endpoint authentication now. Map every /mcp and /mcp_message style endpoint in your stack. Verify that authentication middleware applies to command execution endpoints, not just session establishment. Do not assume that because your core application has auth, the MCP layer inherits it correctly.

The Broader Pattern Worth Watching

MCP is growing fast. Almost every major AI tool and platform added MCP support in 2025 and early 2026. Each of those integrations is a new attack surface bolted onto an existing application. The security community is only beginning to audit these integrations systematically.

CVE-2026-33032 and MCPwnfluence landed in the same week. Both are CVSS 9.x. Both involve unauthenticated access to command execution through MCP endpoints. Both exist because developers trusted that the surrounding application's security controls would cover the new integration layer.

They did not.

Patch your nginx-ui instances. Then audit everything else that has an MCP endpoint exposed to your network.