CVE-2026-33032: Nginxui Nginx UI Auth Bypass Vulnerability

CVE-2026-33032 Overview

Nginx UI is a web user interface for the Nginx web server. A critical authentication bypass vulnerability exists in versions 2.3.5 and prior where the nginx-ui MCP (Model Context Protocol) integration exposes two HTTP endpoints: /mcp and /mcp_message. While the /mcp endpoint requires both IP whitelisting and authentication via the AuthRequired() middleware, the /mcp_message endpoint only applies IP whitelisting - and critically, the default IP whitelist is empty, which the middleware treats as "allow all". This architectural flaw allows any network attacker to invoke all MCP tools without authentication.

Critical Impact

Complete Nginx service takeover is possible - attackers can restart nginx, create/modify/delete nginx configuration files, and trigger automatic config reloads without any authentication.

Affected Products

• Nginx UI versions 2.3.5 and prior
• nginxui nginx_ui (all versions up to and including 2.3.5)

Discovery Timeline

• 2026-03-30 - CVE CVE-2026-33032 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-33032

Vulnerability Analysis

This vulnerability represents a classic Missing Authentication for Critical Function (CWE-306) flaw in the Nginx UI application. The MCP integration was designed to provide programmatic control over the Nginx web server through HTTP endpoints, but a security oversight during implementation resulted in inconsistent authentication enforcement across these endpoints.

The architectural disparity between the two MCP endpoints creates a significant security gap. The /mcp endpoint correctly implements defense-in-depth by requiring both IP whitelist validation and user authentication through the AuthRequired() middleware. However, the /mcp_message endpoint was implemented with only the IP whitelisting check, bypassing the authentication requirement entirely.

The impact is amplified by the default configuration where the IP whitelist is empty. The middleware logic interprets an empty whitelist as permissive rather than restrictive, effectively granting access to all IP addresses. This design choice, combined with the missing authentication on /mcp_message, means that any network-accessible attacker can interact with the MCP functionality.

Root Cause

The root cause is an inconsistent application of security middleware across the MCP endpoints. The /mcp_message endpoint was not wrapped with the AuthRequired() middleware that protects the /mcp endpoint. Additionally, the IP whitelist implementation uses a permissive default (empty list = allow all) rather than a secure default (empty list = deny all), violating the principle of secure defaults.

Attack Vector

The attack vector is network-based with no authentication required. An attacker can directly access the /mcp_message endpoint from any IP address when the default configuration is in place. Through this endpoint, the attacker can invoke MCP tools that provide administrative control over the Nginx server, including:

• Restarting the Nginx service
• Creating new configuration files
• Modifying existing configuration files
• Deleting configuration files
• Triggering automatic configuration reloads

This level of control enables complete compromise of the Nginx web server, potentially leading to traffic interception, service disruption, or using the server as a pivot point for further attacks.

The vulnerability is exploited by sending HTTP requests directly to the /mcp_message endpoint without any authentication headers or tokens. Since the endpoint lacks authentication middleware and the default IP whitelist allows all connections, these requests are processed with full administrative privileges. Attackers can manipulate Nginx configurations to redirect traffic, inject malicious content, or disable security controls. See the GitHub Security Advisory for complete technical details.

Detection Methods for CVE-2026-33032

Indicators of Compromise

• Unexpected HTTP requests to the /mcp_message endpoint from external or unauthorized IP addresses
• Unauthorized modifications to Nginx configuration files without corresponding administrator activity
• Unexplained Nginx service restarts or configuration reloads in system logs
• New or altered server blocks, upstream definitions, or location directives in Nginx configurations

Detection Strategies

• Monitor web server access logs for requests to /mcp and /mcp_message endpoints, especially from non-administrative IP ranges
• Implement file integrity monitoring on Nginx configuration directories to detect unauthorized changes
• Set up alerts for Nginx service restarts that do not correlate with scheduled maintenance windows
• Deploy network intrusion detection rules to identify MCP protocol traffic patterns from untrusted sources

Monitoring Recommendations

• Enable verbose access logging for the Nginx UI application and retain logs for forensic analysis
• Configure centralized log collection for both Nginx UI and the underlying Nginx server
• Establish baseline metrics for configuration file changes and service restarts to identify anomalies
• Implement real-time alerting for any access to MCP endpoints from IP addresses not in an explicitly defined allowlist

How to Mitigate CVE-2026-33032

Immediate Actions Required

• Configure an explicit IP whitelist in the Nginx UI settings to restrict MCP endpoint access to known administrative IP addresses only
• Place the Nginx UI behind a reverse proxy or VPN that enforces authentication before requests reach the application
• Disable MCP functionality entirely if not required for your deployment
• Review recent Nginx configuration changes and service restarts for signs of unauthorized access

Patch Information

At time of publication, there are no publicly available patches for this vulnerability. Organizations should monitor the Nginx UI GitHub Security Advisory for updates on remediation.

Workarounds

• Restrict network access to the Nginx UI application using firewall rules to limit exposure to trusted networks only
• Configure a non-empty IP whitelist with only explicitly trusted administrative IP addresses
• Deploy the Nginx UI behind an authenticating reverse proxy such as OAuth2 Proxy or similar authentication gateway
• Consider running Nginx UI in a segmented network zone with strict ingress/egress controls

# Example: Restrict access to Nginx UI using iptables
# Replace 10.0.0.0/24 with your administrative network range
iptables -A INPUT -p tcp --dport 9000 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 9000 -j DROP