The Nginx Management Interface Problem: Two Actively Exploited CVEs Enable Full Server Takeover

What Is Happening

Nginx powers roughly a third of all websites on the internet. The server itself is not the problem. The problem is what organizations add on top of it.

Nginx-ui is an open-source web-based management interface for nginx, widely adopted because it makes configuration and monitoring accessible without touching the command line. As of April 2026, two critical vulnerabilities in nginx-ui are being actively exploited in the wild. Tracked as CVE-2026-33032 (CVSS 9.8) and CVE-2026-27944 (CVSS 9.8), they can be chained together to achieve complete unauthenticated server takeover: an attacker who reaches your nginx-ui interface needs no credentials, no session, and no prior access to extract your SSL private keys, administrator credentials, and nginx configuration, then execute arbitrary commands on the server.

Threat intelligence data shows approximately 2,600 nginx-ui instances are directly exposed to the internet. Active exploitation was confirmed by VulnCheck and Recorded Future's Insikt Group on the same day the vulnerability was published to the National Vulnerability Database. This is not theoretical. Attacks are occurring now against unpatched instances.

The broader pattern is worth noting: nginx itself has a strong security track record. Attackers are not going after the web server. They are going after the management tooling organizations layer on top of it, because that tooling is frequently misconfigured, rarely patched on the same schedule as the underlying server, and often exposed to networks it should not be reachable from.

Affected Versions

Both patches are included in v2.3.4. Updating to v2.3.4 or later resolves both vulnerabilities. Check your installed version with ./nginx-ui --version or via the web interface under Settings.

Note: these vulnerabilities affect nginx-ui specifically, not nginx itself. Nginx server versions are not affected.

What Being on an Affected Version Means

CVE-2026-33032 exploits a fail-open logic flaw in nginx-ui's IP whitelist middleware. When the whitelist is unconfigured (the default state on a fresh install), the middleware interprets the empty list as "allow all" and bypasses authentication entirely for the MCP endpoint. An attacker sends a GET request to /mcp to establish a session, then POST requests to /mcp_message to execute commands against the nginx service without any credentials.

CVE-2026-27944 makes this worse. The /api/backup endpoint is accessible without authentication and returns a full system backup. The response header X-Backup-Security discloses the encryption key needed to decrypt that backup. The backup contains user credentials, session tokens, SSL private keys, and nginx configurations including a value called node_secret that authenticates the MCP interface.

Chained together: an attacker downloads the backup, extracts node_secret, uses it to authenticate the MCP interface, and issues commands through /mcp_message. The result is full unauthenticated remote code execution on the nginx server with the ability to modify configurations, intercept traffic, and harvest credentials from every site the server hosts.

For any organization running nginx-ui on a perimeter or internet-facing server, the practical impact is complete compromise of the web layer: every site configuration, every SSL certificate, every virtual host, and every connection flowing through that server.

Mitigation Steps

1. Update nginx-ui to v2.3.4 immediately. This is the only complete fix. Download from the official nginx-ui GitHub repository (https://github.com/0xJacky/nginx-ui/releases). If you are running nginx-ui via Docker, update the image tag to uozi/nginx-ui:v2.3.4 or later and redeploy.
2. If immediate patching is not possible, restrict access at the network level. nginx-ui's management interface should never be exposed to the internet. Place it behind a VPN or restrict access to specific internal IP addresses using firewall rules. Block all external access to nginx-ui's default port (typically 9000 or 80/443 depending on configuration).
3. Rotate all credentials and keys if your instance was exposed. If nginx-ui was accessible from the internet prior to patching, assume the backup was downloaded. Rotate: administrator passwords, SSL/TLS certificates for all hosted sites, any API keys or credentials stored in nginx configurations, and session tokens. The backup contains everything needed to impersonate your server.
4. Audit your nginx-ui access logs for exploitation indicators. Look for unauthenticated GET requests to /mcp, POST requests to /mcp_message, and GET requests to /api/backup from external IP addresses. Any such requests from untrusted sources should be treated as confirmed compromise.
5. Verify your IP whitelist is configured. Even on patched versions, configure the IP whitelist in nginx-ui settings to restrict management access to known trusted addresses. An empty whitelist (the default) is the condition that enabled CVE-2026-33032. Explicitly defining allowed IPs adds defense in depth.

If you are not running nginx-ui, these vulnerabilities do not affect you. If you are uncertain whether nginx-ui is installed in your environment, check for processes listening on port 9000 or look for the nginx-ui binary in /usr/local/bin/ or wherever your team may have placed it.