Nginx-UI MCPwn (CVE-2026-33032): Full Server Takeover With One Unauthenticated Request

Want to learn ethical hacking? I built a complete course. Have a look!
Learn penetration testing, web exploitation, network security, and the hacker mindset:
→ Master ethical hacking hands-on
Hacking is not a hobby but a way of life!
A critical vulnerability in nginx-ui has been actively exploited since March 2026, and it gives any attacker on the network full control over the nginx server behind it without a single credential. CVE-2026-33032 scores 9.8 on the CVSS scale, sits inside an AI integration that was added to the tool in late 2025, and the entire root cause turned out to be 27 characters of missing code. Recorded Future assigned it a risk score of 94 out of 100. The researchers who found it named it MCPwn. 😏
nginx-ui is a web-based management dashboard for nginx servers. Instead of editing configuration files through the command line, administrators get a graphical interface, real-time monitoring, and a control panel to manage everything from one place. It is widely used: more than 11,000 stars on GitHub and 430,000 Docker pulls. Most of those installations sit behind firewalls and are never directly exposed to the internet. But Shodan still found 2,689 instances reachable from the outside, running on cloud providers including Alibaba Cloud, Oracle, and Tencent, most of them on port 9000 by default.
nginx powers about a third of all the websites on the internet, and nginx-ui is the management layer sitting in front of that. Getting into nginx-ui means everything the server handles becomes accessible.
In late 2025, the nginx-ui developers added support for something called MCP, which stands for Model Context Protocol. MCP is the standard that connects AI models to external tools and data sources. The idea was to let AI agents interact with nginx configurations directly, manage the server, restart services, reload configs, all through a standardized interface. Two HTTP endpoints were created for this: /mcp and /mcp_message. The /mcp endpoint handles connection setup and has both IP whitelisting and authentication. The /mcp_message endpoint handles every actual tool command, config writes, server restarts, all of it, and it shipped without the authentication check.
The default IP whitelist in nginx-ui is empty. The middleware responsible for checking that whitelist treats an empty list as allow all, so /mcp_message, the endpoint that can do everything, was completely open to anyone on the network without any bypass or reverse engineering needed.
But it gets worse, because there is a second CVE that most coverage is not connecting properly.
CVE-2026-27944 is a separate critical vulnerability in nginx-ui, also scoring 9.8. The /api/backup endpoint, which generates and downloads a full system backup, requires no authentication at all. Any unauthenticated attacker can call it and receive a complete archive containing user credentials, session tokens, SSL private keys, and the full nginx configuration. The backup is AES-256 encrypted, which sounds secure until the next part: the server sends the decryption key and initialization vector directly in the HTTP response header, in a field called X-Backup-Security. The encryption is there but the key travels with the data to whoever requests it, making the encryption completely pointless.
Inside that backup is a value called node_secret, which is the query parameter used to authenticate the MCP interface. Combine both vulnerabilities and the full chain looks like this: send one unauthenticated GET request to /api/backup, receive the backup and the decryption key in the same response, decrypt the archive, extract node_secret, use it to establish an SSE connection that returns a sessionID, then use that sessionID to send commands through /mcp_message without any further authentication required. A GitHub repository already exists that automates the entire chain from start to finish, downloading the backup, decrypting it, extracting secrets, and creating a rogue administrator account with full dashboard access. That SSE connection step is also worth knowing for log analysis, because it is exactly what to look for when checking whether a server has already been targeted.
The CVE was published on March 30, 2026, and that same day Recorded Future and VulnCheck confirmed that active exploitation was already happening, meaning attackers were inside before any of the technical details were public. Pluto Security researcher Yotam Perkal held back the full breakdown until this week, April 15-16, 2026, which is also when the working PoC dropped publicly. VulnCheck added CVE-2026-33032 to their Known Exploited Vulnerabilities list, and Recorded Future’s Insikt Group included it as one of 31 high-impact vulnerabilities actively exploited in March 2026.
Once an attacker is through, the 12 MCP tools available without authentication include rewriting nginx configuration files, triggering automatic config reloads, restarting the service, and intercepting all traffic passing through the server. Pulling administrator credentials out of the configuration takes no effort at all, and maintaining persistent access through a modified config is just as simple. The server keeps running, handling traffic, looking completely normal, while everything passing through it is visible to whoever got in.
The patch released in version 2.3.4 on March 15, one day after responsible disclosure, adds exactly one function call to the /mcp_message endpoint: middleware.AuthRequired(). Twenty-seven characters added to the codebase, plus a regression test to make sure the same oversight cannot happen again in the same place. That is the entire difference between a server that is vulnerable and one that is not.
This is not an isolated mistake. It is the second MCP vulnerability Pluto Security has disclosed in recent weeks. Before this, there was MCPwnfluence, an SSRF-to-remote-code-execution chain in the Atlassian MCP server. And nginx itself is already a popular target this year: in February 2026, attackers were actively exploiting CVE-2025-55182, known as React2Shell, a vulnerability in React Server Components that was specifically used to target nginx servers. MCPwn is not the first attack aimed at this infrastructure in 2026, it is the latest in a pattern. Trend Micro found 492 MCP servers on the internet with no client authentication and no traffic encryption. Researchers who analyzed more than 7,000 MCP server deployments found 36.7% of them were vulnerable to server-side request forgery. MCP support is being added to tools at speed because the feature is useful and the demand is there, but the security review is not keeping up. When those access points ship without authentication, they do not inherit the security controls of the application they were bolted onto. They inherit all the capabilities while the controls get left behind.
If nginx-ui is running anywhere in the environment, here is how to check and what to do.
The default port is 9000. Log into the machine and run:
| |
or check the Docker container version directly. Version 2.3.3 or older is vulnerable, version 2.3.4 has the fix. Worth knowing: some version trackers online show incorrect information. SentinelOne’s vulnerability database for example lists versions 2.3.5 and prior as affected, which is wrong. The actual last vulnerable version is 2.3.3 and 2.3.4 contains the fix. Always verify against the official release on GitHub rather than trusting a third-party tracker.
A quick test for CVE-2026-27944: try accessing http://yourserver:9000/api/backup without logging in. If the server responds with a file download, the backup endpoint has no authentication and the instance is unpatched.
What to do right now:
→ Update nginx-ui to version 2.3.4 immediately. This is the safest single update: CVE-2026-27944 was already patched in 2.3.3, but CVE-2026-33032 required 2.3.4. Running 2.3.4 covers both.
→ If patching is not immediately possible, the manual workaround is to add
middleware.AuthRequired()to the/mcp_messageendpoint directly in the code, or disable MCP entirely in the nginx-ui settings.→ As an interim network-level measure, add explicit IP whitelisting to restrict
/mcp_messageto trusted hosts only and change the default whitelist behavior from allow-all to deny-all.→ Lock
/api/backupbehind firewall rules or authentication middleware if a full update cannot be applied yet.→ Review access logs for unusual configuration changes, unexpected config reloads, SSE connections to the
/mcpendpoint, or traffic to/mcp_messagethat does not originate from known admin sources.→ If the instance was exposed and running an unpatched version, treat all credentials stored in the configuration, including SSL private keys, as compromised and rotate them.
Understanding how attackers move from a single unauthenticated endpoint to full system control is exactly what I cover in my ethical hacking course, including exploitation techniques, privilege escalation, lateral movement, and the full attack chain from first foothold to complete compromise.
Hacking is not a hobby but a way of life.
Sources: CVE-2026-33032 - NVD · CVE-2026-27944 - NVD · GitHub Advisory CVE-2026-33032 (GHSA-h6c2-x2m2-mwhf) · GitHub Advisory CVE-2026-27944 (GHSA-g9w5-qffc-6762) · Pluto Security - MCPwnfluence
→ Stay updated!
Get the latest posts in your inbox every week. Ethical hacking, security news, tutorials, and everything that catches my attention. If that sounds useful, drop your email below.