CVE-2026-33032 Exploit & Vulnerability Analysis

1. Vulnerability Background

What is this vulnerability?

• CVE-2026-33032 is an authentication/authorization bypass in Nginx UI’s MCP (Model Context Protocol) integration.
• The component exposes two HTTP endpoints: /mcp and /mcp_message.
• /mcp was protected by both IP whitelisting and AuthRequired() middleware.
• /mcp_message was only protected by IP whitelisting.

Why is it critical/important?

• The default IP whitelist is empty, and the whitelist middleware treats an empty list as “allow all”.
• This means a remote attacker can call /mcp_message without authentication on default installations.
• The MCP endpoint can invoke administrative operations such as restarting nginx, creating/modifying/deleting configuration files, and triggering config reloads.
• This results in complete nginx service takeover and arbitrary configuration manipulation.

What systems/versions are affected?

• Nginx UI versions 2.3.5 and prior.
• Any deployment using the default MCP configuration or with an empty whitelist.
• Network-exposed installations are especially at risk.

2. Technical Details

Root cause analysis

• The root cause is inconsistent middleware protection between two related MCP endpoints.
• In mcp/router.go, /mcp_message was registered with only middleware.IPWhiteList().
• The AuthRequired() middleware was omitted, unlike /mcp.
• The IP whitelist middleware has a design flaw: an empty whitelist is treated as permitting all addresses rather than denying all.

Attack vector and exploitation conditions

• An attacker needs only network access to the nginx-ui instance.
• If the default ACL is in use, /mcp_message is reachable without credentials.
• The attacker sends HTTP requests to /mcp_message with MCP payloads.
• Because the handler forwards directly to mcp.ServeHTTP, any MCP tool can be invoked.

Security implications

• Unauthorized administrative access to nginx UI.
• Ability to restart nginx or trigger config reloads.
• Ability to create, modify, or delete nginx configuration files.
• Potential for persistent compromise, service disruption, and further lateral movement.
• The vulnerability is effectively a complete takeover of the managed nginx service.

3. Patch Analysis

What code changes were made?

• mcp/router.go
  • Old registration: r.Any("/mcp_message", middleware.IPWhiteList(), func(c *gin.Context) { mcp.ServeHTTP(c) })
  • Fixed registration: r.Any("/mcp_message", middleware.IPWhiteList(), middleware.AuthRequired(), func(c *gin.Context) { mcp.ServeHTTP(c) })
• mcp/router_test.go
  • Added regression coverage that sets settings.AuthSettings.IPWhiteList = nil.
  • Verifies POST requests to both /mcp and /mcp_message return HTTP 403 with {"message":"Authorization failed"}.
• mcp/config/config_add.go
  • Replaced direct path construction and directory check with config.ResolveConfPath.
  • Both base directory and target file name are resolved before writing.

How do these changes fix the vulnerability?

• Adding middleware.AuthRequired() to /mcp_message enforces authentication on the previously unprotected endpoint.
• The regression test ensures this behavior is preserved even when the IP whitelist is nil/empty.
• The config path resolution change reduces the risk of path traversal or directory escape when writing configuration files.

Security improvements introduced

• Consistent authorization policy across MCP endpoints.
• Regression coverage for authentication enforcement under empty whitelist conditions.
• Stronger path resolution in config write operations.
• Reduced likelihood of an attacker bypassing controls via malformed file paths.

4. Proof of Concept (PoC) Guide

Prerequisites for exploitation

• Nginx UI version 2.3.5 or earlier.
• Network access to the nginx-ui service.
• Default or empty IP whitelist configuration.
• No additional external access controls protecting /mcp_message.

Step-by-step exploitation approach

1. Identify the nginx-ui base URL.
2. Send an unauthenticated HTTP request to /mcp_message.
3. Observe the response and behavior.
4. If exploitation is intended, send a valid MCP payload to trigger an administrative action, such as reload or config write.

Example detection request:

• curl -i http://<host>/mcp_message

Expected behavior vs exploited behavior

• Expected behavior after patch:
  • /mcp_message returns HTTP 403 or equivalent authorization failure without valid auth.
  • /mcp and /mcp_message both enforce authentication.
• Exploited behavior on vulnerable installations:
  • /mcp_message accepts requests without credentials.
  • An attacker can invoke MCP functionality directly.

How to verify the vulnerability exists

• Confirm /mcp requires auth by sending an unauthenticated request and seeing a 403 or auth challenge.
• Confirm /mcp_message does not require auth by sending an unauthenticated request and receiving a successful response or different behavior.
• A stronger verification is to trigger a harmless MCP action and observe whether it succeeds without authentication.
• Reviewing source code or configuration for r.Any("/mcp_message", middleware.IPWhiteList(), ...) is a direct confirmation.

5. Recommendations

Mitigation strategies

• Apply the patch or upgrade to a fixed version as soon as available.
• If patching is not immediately possible:
  • Block access to /mcp_message at the network edge.
  • Restrict access to nginx-ui to trusted hosts only.
  • Configure a non-empty IP whitelist and validate it behaves as deny-by-default.
  • Disable or isolate MCP integration if not required.

Detection methods

• Monitor web server logs for requests to /mcp_message.
• Look for unexpected POST/PUT/DELETE activity against MCP endpoints.
• Alert on successful access to /mcp_message without authentication.
• Compare responses for /mcp and /mcp_message; a discrepancy is suspicious.

Best practices to prevent similar issues

• Enforce consistent middleware and authorization chains across all related endpoints.
• Treat empty whitelists as deny-by-default, not allow-all.
• Add regression tests for authentication behavior, especially in default or edge-case configurations.
• Use canonical path resolution for file system operations to prevent traversal or directory escape.
• Conduct code reviews focused on middleware ordering and security policy enforcement.