Two HTTP Requests to Full Nginx Takeover
CVE-2026-33032 is a CVSS 9.8 auth bypass in nginx-ui. One unprotected MCP endpoint lets attackers rewrite nginx configs and take over the server.
Everyone is adding MCP support to their tools right now. Model Context Protocol, the open standard that lets AI assistants interact with software, is showing up in code editors, database clients, deployment platforms, and infrastructure managers. nginx-ui, a popular web dashboard for managing Nginx servers, shipped MCP integration in February so users could configure their web server through AI.
They forgot to put authentication on one of the two MCP endpoints.
What Is nginx-ui?
nginx-ui is a browser-based dashboard for managing Nginx, the web server that handles roughly a third of all internet traffic. Instead of editing config files over SSH, you get a web interface with real-time stats, Let’s Encrypt certificate management, and a visual configuration editor. It is written in Go and Vue, shipped as a single binary, and has over 10,000 stars on GitHub. Small teams and solo developers use it because managing Nginx through a terminal is tedious.
The Vulnerability
CVE-2026-33032 is an authentication bypass with a CVSS score of 9.8. Pluto Security discovered it and gave it the name MCPwn.
nginx-ui’s MCP integration exposes two HTTP endpoints:
/mcprequires both IP whitelisting and authentication through theAuthRequired()middleware/mcp_messagerequires only IP whitelisting
The critical mistake: the default IP whitelist is empty. When the whitelist is empty, the middleware interprets it as “allow all.”
That means /mcp_message is accessible to anyone on the internet by default. No password, no token, no session cookie. Nothing between the attacker and 12 MCP tools that can read, write, and delete nginx configuration files, trigger config reloads, and restart the service entirely.
One endpoint got proper auth. The other one did not. That gap is the whole vulnerability.
How the Attack Works
Exploitation takes two HTTP requests.
Request 1: The attacker opens a Server-Sent Events (SSE) connection to /mcp. The server responds with a sessionID.
Request 2: Using that sessionID, the attacker sends a POST to /mcp_message containing an MCP tool invocation. For example, a call to write a new nginx configuration file that sets up a reverse proxy pointing to the attacker’s server.
After the config write, nginx-ui automatically reloads the Nginx process. The attacker’s configuration is live.
No brute forcing. No privilege escalation. No chaining multiple bugs together. Two requests, a few seconds, and the web server belongs to someone else.
What an Attacker Gets
With write access to nginx configuration and automatic reloads, an attacker can do more than just deface a website.
Intercept all traffic. Inject a proxy_pass directive that routes incoming requests through an attacker-controlled server before forwarding them to the real backend. Every HTTP request, response header, session cookie, and API key passes through the attacker’s proxy. Users see nothing unusual.
Harvest credentials. Add an access_log directive that records full request bodies. Login forms, authentication tokens, payment data. All written to a log file the attacker retrieves later.
Maintain persistent access. Create an additional server block that acts as a backdoor. Even if the admin patches nginx-ui, the injected config survives until someone manually reviews every server block and spots the one that does not belong.
Kill the service. Write an intentionally broken configuration and reload. Nginx refuses to start. For a business running its application behind that Nginx instance, that means downtime until someone figures out what happened.
Map the internal network. Read existing configuration files to find upstream server addresses, internal hostnames, and backend ports. Information that is invisible from the outside but invaluable for lateral movement.
Active Exploitation
This is not a theoretical risk. Recorded Future listed CVE-2026-33032 among 31 vulnerabilities actively exploited by threat actors in March 2026, a month before most organizations even knew it existed.
Shodan currently indexes 2,689 nginx-ui instances exposed to the public internet. The highest concentrations are in China, the United States, Indonesia, Germany, and Hong Kong. How many are running a vulnerable version is unknown, but any instance on a version older than 2.3.4 with MCP support enabled is a target.
The patch landed in nginx-ui version 2.3.4 on March 15, 2026. If you have not updated since then, you are running vulnerable code.
Are You Affected?
Check your version:
nginx-ui -vIf it is below 2.3.4, update immediately.
If updating is not possible right now, block external access to /mcp and /mcp_message at your firewall or upstream reverse proxy. These endpoints should never be reachable from the public internet. That is true regardless of your nginx-ui version.
More broadly: if you run any web management panel (nginx-ui, Portainer, phpMyAdmin, Grafana, Jenkins), verify that it is not reachable from outside your network. Management interfaces are consistently the highest-value targets because they provide direct access to infrastructure. FortiClient EMS got owned through its management API for the same reason. The pattern keeps repeating.
If you want to see what is actually visible on your public IP, Sentinel scans all 65,535 ports and reports every exposed service it finds, including management panels you may have forgotten about. Free, no account required, results in 30 minutes.
How to Tell If You Were Compromised
If you have been running a vulnerable version, check for signs of tampering before you update.
Review your nginx configs. Look for server blocks you did not create. Pay special attention to proxy_pass directives pointing to unfamiliar addresses and access_log directives writing to unexpected paths.
grep -r "proxy_pass" /etc/nginx/ | grep -v "# "
grep -r "access_log" /etc/nginx/ | grep -v "# "Check access logs for MCP endpoint hits. Any request to /mcp or /mcp_message from an external IP is suspicious.
grep -E "/mcp(_message)?" /var/log/nginx/access.logReview nginx reload history. Frequent, unexplained config reloads may indicate automated exploitation.
If you find anything unexpected, assume the attacker had full read/write access to your nginx configuration. Audit every server block, rotate any credentials that were transmitted through the server, and review upstream connections for signs of traffic interception.
The Pattern Here
nginx-ui’s developers did the security work on /mcp. They added AuthRequired() middleware. Then they created /mcp_message with weaker protections and a default configuration that effectively disables them. Probably a mistake during development that slipped through review.
This is going to keep happening. MCP integration is appearing in tools across the infrastructure stack. Each integration adds new endpoints with access to operations that can modify production systems. When those endpoints ship with permissive defaults (empty whitelists that mean “allow all,” disabled authentication, localhost only restrictions that do not account for containerized environments), the result is the same: unauthenticated access to your infrastructure through a door you did not know existed.
Before you enable MCP support on anything that touches production:
- Verify authentication on every new endpoint, not just the primary one
- Read the default configuration and understand what “empty” or “unset” values mean
- Test from outside your network and confirm the endpoints are not reachable
The vulnerability in nginx-ui was not MCP itself. MCP is fine. The vulnerability was assuming that if the main endpoint is secure, the secondary one is too. That assumption cost 2,689 server operators their infrastructure.
Patch now. Audit later. In that order.
Sentinel scans your public infrastructure for exposed services, open ports, and known vulnerabilities. If you want to know what attackers can see before they find it, run a free scan. No account, no credit card. Report delivered in 30 minutes.