How a missing 27-character code fix left thousands of web servers open to unauthenticated takeover

The Context

nginx-ui is an open-source web management interface for nginx, the web server software that handles a significant share of internet traffic worldwide. Where nginx itself is configured through text files, nginx-ui provides a graphical dashboard that lets administrators create, edit, and reload those configuration files through a browser. It has accumulated over 11,000 GitHub stars and 430,000 Docker pulls, and it is widely deployed as the management layer for API gateways, reverse proxies, and load balancers across technology, finance, healthcare, and government organizations.

In late 2025, nginx-ui added support for the Model Context Protocol (MCP), a standard that lets AI agents interact with software tools programmatically. The intent was to allow AI assistants to manage nginx configurations on behalf of administrators. The implementation gave those AI agents access to 12 privileged operations, including writing configuration files, triggering server reloads, and restarting nginx entirely. What it did not do was apply the same authentication requirements that protected every other part of the application.

The Attack, Phase by Phase

Phase 1: The Backup Exfiltration (CVE-2026-27944)

The attacker starts with a single unauthenticated HTTP request to the /api/backup endpoint. No login, no token, no prior knowledge of the target required.

The server responds with two things simultaneously: a full encrypted ZIP archive of the system's state, and the AES-256 encryption key and initialization vector needed to open it, both printed in plaintext in the X-Backup-Security HTTP response header. The attacker decrypts the archive on the spot.

Inside: user credential hashes, session tokens, SSL private keys, nginx configuration files, application secrets, and a value called node_secret, which is the key to the MCP session system.

This vulnerability existed because the developer who built the backup feature applied authentication middleware to the restore endpoint (which writes data back) but not to the backup endpoint (which reads everything out). The asymmetry was never caught.

Phase 2: Session Establishment via node_secret

With node_secret in hand, the attacker sends a GET request to /mcp?node_secret=VALUE. This endpoint does enforce authentication, and it accepts node_secret as valid proof of identity. The server returns a sessionId for the MCP session stream.

That sessionId is the only remaining artifact the attacker needs.

Phase 3: Unauthenticated Command Execution (CVE-2026-33032)

Here is where the missing 27 characters matter. The attacker POSTs a JSON-RPC payload to /mcp_message?sessionId=VALUE. This endpoint, unlike /mcp, has no authentication middleware. The default IP allowlist is empty, which the code interprets as "allow all." The request reaches the privileged MCP handler directly.

The attacker can now invoke any of the 12 exposed MCP tools. The most immediately destructive is nginx_config_add, which writes arbitrary content to nginx's configuration directory and triggers an automatic reload in a single call. The new configuration is live the moment the call returns.

Phase 4: Post-Exploitation and Persistence

With write access to nginx configuration and automatic reload capability, the attacker's options are extensive. They can inject a custom log format directive to capture authorization headers from every request nginx proxies, effectively harvesting credentials from all downstream services. They can rewrite upstream proxy targets to redirect traffic to attacker-controlled infrastructure. They can forge administrator tokens using the JwtSecret extracted from the backup in Phase 1.

Persistence is automatic: injected configuration files are loaded on every nginx restart, so the attacker's changes survive reboots. The attacker can also remove all server blocks to take nginx offline entirely, or quietly read existing configuration files to map the internal network topology.

What Made This Possible

1. Authentication was applied per-endpoint, not per-feature. When MCP was added to nginx-ui, the developer applied authentication to the session-opening endpoint (/mcp) but not to the command-receiving endpoint (/mcp_message). The two endpoints are functionally one feature, but they were registered separately in the router, and only one got the security check.

2. The fail-open default guaranteed exposure at scale. The IP allowlist that was supposed to restrict MCP access defaults to an empty list. The code interprets an empty list as "allow all." This means the secure configuration requires explicit action from the administrator, while the insecure configuration ships out of the box.

3. The backup endpoint handed attackers the keys to bypass the one check that did exist. Even if an attacker could not exploit CVE-2026-33032 alone, CVE-2026-27944 provided node_secret for free, collapsing the only remaining authentication barrier.

New integration layers inherit capabilities without inheriting security controls. That gap is the vulnerability.

What Should Have Stopped This

Every defense that would have reduced the blast radius here shares one trait: it does not depend on the MCP layer's own integrity to function.

• Network isolation for management interfaces. If nginx-ui's port 9000 is not reachable from the public internet, the unauthenticated backup and MCP endpoints cannot be reached either. Management dashboards should sit on internal networks or behind a VPN, not on public-facing infrastructure.
• Authentication applied at the router level, not the endpoint level. A global middleware rule requiring authentication for all routes under /mcp would have caught the missing call on /mcp_message. Endpoint-by-endpoint security is fragile because it requires every developer to remember every rule on every new route.
• Secrets rotation as a response primitive. The node_secret and JwtSecret values extracted from the backup are long-lived. Organizations that rotate application secrets regularly limit how long an extracted secret remains useful to an attacker.
• Backup endpoint access controls. Any endpoint that returns a full system backup should require authentication at minimum, and ideally should not be exposed over the same network interface as the application itself.

The Takeaway

MCPwn is not primarily a story about nginx-ui. It is a story about what happens when a new integration standard arrives and developers treat it as a feature to add rather than an attack surface to audit. The MCP endpoints inherited nginx-ui's full operational power, including the ability to rewrite server configurations and redirect internet traffic, but they were never subjected to the authentication review that the rest of the application had already passed.

This is the same class of failure as the Stryker Intune wipe: a privileged management tool weaponized against the organization it was built to protect. In that case, attackers used legitimate device management credentials to issue wipe commands. Here, attackers used a legitimate session mechanism (node_secret) to issue configuration commands. The shared failure: the management plane trusted its own authentication artifacts without verifying that those artifacts were obtained legitimately.

The researcher who found this vulnerability put it precisely: "When you bolt MCP onto an existing application, the MCP endpoints inherit the application's full capabilities but not necessarily its security controls." That sentence will remain true for every application that adds MCP support without a dedicated security review of the new endpoints.

Pattern to remember: Every new integration layer creates a new authentication perimeter, and that perimeter will be insecure wherever capability and security are treated as separate concerns.

What changed: AI agent interfaces can now serve as a fully unauthenticated entry point into management tools, bypassing authentication controls that were never extended to cover the new protocol endpoints.

The Technical Mechanism

CVE-2026-33032 is a missing authentication middleware call in nginx-ui's MCP router (mcp/router.go, lines 9-17). The nginx-ui MCP integration uses the SSE transport from the mcp-go library, which splits communication across two HTTP endpoints:

• GET /mcp: Opens a persistent SSE stream and returns a sessionId. This route correctly chains middleware.IPWhiteList() and middleware.AuthRequired().
• POST /mcp_message: Receives JSON-RPC tool invocations and executes all privileged operations. This route applies only middleware.IPWhiteList().

The default IP whitelist is an empty list. The middleware interprets an empty list as "allow all." The result: any network-adjacent attacker can POST JSON-RPC payloads to /mcp_message with no credentials and invoke all 12 exposed MCP tools. The fix was adding middleware.AuthRequired() to the /mcp_message route registration.

CWE classification for CVE-2026-33032: CWE-306 (Missing Authentication for Critical Function).

CVE-2026-27944 is a separate flaw in the backup router. The GET /backup route is registered without any authentication middleware, while the POST /restore endpoint correctly uses middleware. When an attacker sends an unauthenticated GET to /api/backup, the server returns a full encrypted ZIP archive (nginx-ui.zip) and simultaneously exposes the AES-256 encryption key and initialization vector in plaintext in the X-Backup-Security HTTP response header. The archive contains database.db (user credentials and session tokens), app.ini (application secrets including node_secret and JwtSecret), SSL private keys, and nginx configuration files.

CWE classification for CVE-2026-27944: CWE-306 (Missing Authentication for Critical Function) and CWE-311 (Missing Encryption of Sensitive Data).

The full zero-credential chain: unauthenticated GET to /api/backup yields node_secret from the decrypted archive, which authenticates a GET to /mcp and returns a sessionId, which is then used to POST arbitrary JSON-RPC tool invocations to /mcp_message with no further authentication check.

CVE and Advisories

• CVE-2026-33032: Missing authentication on /mcp_message endpoint. Affects nginx-ui versions through v2.3.5. Fixed in v2.3.4 (March 15, 2026); Rapid7 recommends v2.3.6 due to remediation version confusion in the official CVE record. GitHub Security Advisory: GHSA-h6c2-x2m2-mwhf.
• CVE-2026-27944: Unauthenticated backup download with AES-256 key disclosure. CVSS 9.8. Fixed in v2.3.3 (March 5, 2026). GitHub Advisory: GHSA-g9w5-qffc-6762.
• VulnCheck added CVE-2026-33032 to its Known Exploited Vulnerabilities (KEV) catalog on April 13, 2026.
• Cyber Security Agency of Singapore issued public alert AL-2026-039 on April 17, 2026.

MITRE ATT&CK Mapping

Indicators of Compromise

Detection is complicated by the nature of the attack. Unauthenticated requests to /api/backup and /mcp_message are structurally identical to legitimate requests in terms of HTTP method and path. Defenders should look for:

• Unauthenticated HTTP GET requests to /api/backup in nginx-ui access logs, particularly from external IP ranges.
• HTTP POST requests to /mcp_message from IP addresses not in the expected administrator range.
• Unexpected modifications to files in nginx's conf.d/ or sites-enabled/ directories, particularly files with unfamiliar names or timestamps outside maintenance windows.
• New log_format directives in nginx configuration that reference $http_authorization or other credential-bearing headers.
• Changes to proxy_pass upstream targets pointing to external or unfamiliar IP addresses.
• Recorded Future's Insikt Group created Nuclei templates for CVE-2026-27944 in March 2026, enabling automated scanning for the backup endpoint exposure.

Because the attack writes to configuration files and triggers reloads, forensic evidence may be overwritten by subsequent legitimate configuration changes. Log retention for nginx-ui access logs and file integrity monitoring on nginx configuration directories are the most reliable detection primitives.

Attribution

Unattributed as of April 22, 2026. Recorded Future's Insikt Group confirmed active exploitation in March 2026 but published no specific threat actor attribution. Rescana reporting indicates attackers are using automated scripts to identify and compromise vulnerable endpoints, consistent with opportunistic mass-exploitation rather than targeted activity. No ransomware group, APT cluster, or named threat actor has been publicly linked to exploitation of CVE-2026-33032.

Primary Sources