Now in early access, book a 30-minute demo →
← Back to blog AdvisoryCritical

nginx-ui Unauthenticated MCP Message Endpoint Server Takeover - CVE-2026-33032

MCP Server Security·Critical·CVE-2026-33032 (GHSA-h6c2-x2m2-mwhf)·
Affected nginx-ui versions 2.3.5 and below (fixed in 2.3.4 per finder; actively exploited)

nginx-ui MCP authentication bypass is tracked as CVE-2026-33032 (GHSA-h6c2-x2m2-mwhf), a critical authentication bypass in nginx-ui carrying a CVSS score of 9.8 and exploited in the wild. The official CVE record lists nginx-ui versions 2.3.5 and below as affected; the finder reports the fix landed in nginx-ui 2.3.4. It matters to anyone running MCP servers on managed endpoints because a privileged MCP route ships with no authentication, handing any network attacker the full tool set of an nginx control plane. This advisory sits under the MCP Server Security pillar guide and covers what to check across your fleet and how Anomity governs the tool-call decision at the hook.

What happened

nginx-ui is a web management panel for nginx that also exposes an MCP server, letting an AI agent drive nginx through MCP tool calls over two routes. The /mcp endpoint correctly applies middleware.AuthRequired(), so it demands a valid session before any tool runs. The sibling /mcp_message endpoint applies only an IP-whitelist check and no authentication call.

The default IP whitelist is empty, and the middleware treats an empty whitelist as allow-all rather than deny-all. So any network attacker who can reach the port can post MCP messages to /mcp_message and invoke all MCP tools without authenticating - including restarting nginx and creating, modifying, or deleting configuration files with automatic reloads, achieving complete server takeover. It is a textbook missing-middleware-call mistake: the auth wrapper exists and is applied to /mcp, but was never added to its sibling.

Recorded Future reported in-the-wild exploitation of CVE-2026-33032 (its report was published April 13, 2026; honeypot data placed exploitation activity earlier, within days of the March 28 advisory and public PoC), and subsequent reporting tied CVE-2026-33032 into a chain with the information-leak issue CVE-2026-27944. The fix in nginx-ui 2.3.4 was a single line adding the missing authentication check to /mcp_message. A privileged route that bypasses the auth its sibling enforces is the same unauthenticated-MCP failure class covered in the sibling advisory on MCP STDIO RCE that is dangerous by design.

FieldValue
IdentifierCVE-2026-33032 (GHSA-h6c2-x2m2-mwhf)
SeverityCritical (CVSS 9.8)
Affectednginx-ui 2.3.5 and below (per CVE record)
VectorUnauthenticated MCP tool invocation via /mcp_message; empty IP whitelist = allow-all
Fixed innginx-ui 2.3.4 (single-line auth check on /mcp_message)
ExploitationIn the wild (Recorded Future; report published April 13, 2026, with activity observed within days of the March 28 advisory); chained with CVE-2026-27944

Why this is an agentic-endpoint risk

An MCP server is one of the eight AI artifact types Anomity inventories on every managed endpoint, and nginx-ui is one that controls production infrastructure. CVE-2026-33032 turns it into an unauthenticated remote control for nginx: an attacker who reaches /mcp_message can rewrite configuration files and reload nginx without any credential - the agentic-endpoint failure mode in its cleanest form, an AI artifact exposing privileged actions to anyone who can speak its protocol.

The empty-whitelist detail makes it worse than a typical missing-auth bug. There is no insider step and no stolen credential; the attack surface is a reachable port, and the control meant to gate it silently inverts to allow-all at its default. Network and EDR controls see nginx reloading its own configuration - exactly what nginx-ui is supposed to make nginx do - so malicious tool calls blend into normal control-plane activity. The decision that mattered, whether this MCP message may invoke this tool, happened inside nginx-ui's routing, below perimeter tooling - the layer Anomity makes visible through fleet inventory, and the boundary it governs with the allow/deny/log decision on the tool call itself.

How Anomity surfaces and governs it

Anomity starts with inventory. It enumerates the eight AI artifact types on every managed endpoint - AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs - and classifies each one. An nginx-ui install acting as an MCP server shows up with its version and exposed tools, so a fleet-wide query for nginx-ui at 2.3.5 or below returns the exposed endpoints directly.

On agents that expose a hook - for example a Claude Code PreToolUse hook - Anomity returns allow/deny/log on each tool call before it runs. The governing question is the tool-call decision, not which route delivered it: when an MCP client is about to invoke an nginx configuration write or a service restart, the hook evaluates whether that tool, in that context, is permitted, and can deny privileged actions outside policy before anything executes. Because the decision sits at the hook rather than in per-route middleware, the missing AuthRequired() on /mcp_message gets no different result on a governed endpoint - an unapproved tool call is denied regardless of which route carried it. This is the runtime governance layer in action.

Every decision, and every artifact added, changed, or removed, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. Anomity collects metadata only - server names, versions, exposed tools, decisions - with on-endpoint secret redaction, and it is SOC 2 Type II. It complements, not replaces, your Network, EDR, DLP, and GRC tooling: those see the host and the network; Anomity sees the AI artifact layer and the tool-call decision. That record is what the outcomes view and your auditors query when they ask which endpoints ran a vulnerable nginx-ui and what those MCP tools did.

You can't govern what you can't see - and a privileged route that forgot its auth call is exactly what blends into normal control-plane traffic. Govern the tool call, not the route it arrived on.Anomity Threat Research

What to check across your fleet

  • Inventory every nginx-ui instance and confirm the version; the CVE record lists 2.3.5 and below as affected by CVE-2026-33032 - upgrade to a fixed release (the finder reports the fix in 2.3.4).
  • Treat any nginx-ui at 2.3.5 or below as actively targeted; Recorded Future reported in-the-wild exploitation from around April 13, 2026.
  • Confirm the /mcp_message route enforces authentication, not just an IP whitelist, and that no privileged route relies on a default-empty whitelist the middleware reads as allow-all.
  • Scope the chained information-leak issue CVE-2026-27944 on the same change window, since reporting tied the two together.
  • Enumerate all MCP servers that control infrastructure (web panels, reverse proxies, service managers) and review which tools they expose to unauthenticated callers; restrict network reachability to management ports.
  • Confirm enforcement runs where agents expose a hook (e.g. Claude Code PreToolUse) so the tool-call decision is evaluated before the tool runs, and query the 90-day audit trail for prior nginx-ui configuration writes and restarts to scope pre-patch exposure.

CVE-2026-33032 illustrates the cluster's core lesson: a privileged MCP route that skips the auth its sibling enforces hands an attacker the entire tool set, and an empty default whitelist quietly becomes allow-all. For the full pattern across MCP servers - transports, auth bypasses, and missing middleware - read the parent guide on MCP Server Security and see the AI security framework report. When you are ready to inventory your fleet and govern the tool call at the hook, request early access.

Frequently asked questions

What is CVE-2026-33032 in nginx-ui?

CVE-2026-33032 is a critical authentication bypass in nginx-ui, scored CVSS 9.8 and exploited in the wild. The /mcp endpoint correctly applies middleware.AuthRequired(), but the sibling /mcp_message endpoint only applies IP whitelisting, and the default whitelist is empty - which the middleware treats as allow-all. Any network attacker can therefore invoke every MCP tool without authenticating, including restarting nginx and creating, modifying, or deleting configuration files with automatic reloads, achieving complete server takeover. The official CVE record lists nginx-ui versions 2.3.5 and below as affected; the finder reports the fix landed in 2.3.4.

How does the /mcp_message bypass work?

nginx-ui exposes two MCP routes. The /mcp route is wrapped in middleware.AuthRequired(), so it demands a valid session. The sibling /mcp_message route was wired with only an IP-whitelist check and no authentication call. The whitelist ships empty by default, and the middleware interprets an empty list as allow-all rather than deny-all. That single missing-middleware-call mistake on a privileged route means an unauthenticated attacker who can reach the port can post MCP messages and drive every tool the host exposes, including configuration writes that nginx reloads automatically.

Which nginx-ui versions are affected and where is the fix?

The official CVE record for CVE-2026-33032 lists nginx-ui versions 2.3.5 and below as affected, and the finder reports the corrective change shipped in nginx-ui 2.3.4. The fix was a single line adding the missing authentication check to /mcp_message, so the route now enforces the same AuthRequired() barrier as /mcp. Upgrade every nginx-ui instance, confirm the /mcp_message route requires authentication, and never rely on an empty IP whitelist as a control. Recorded Future reported in-the-wild exploitation (report published April 13, 2026; activity observed within days of the March 28 advisory and PoC).

How was CVE-2026-33032 chained with CVE-2026-27944?

Subsequent reporting tied CVE-2026-33032 into a chain with the information-leak issue CVE-2026-27944. The leak issue helps an attacker gather details about a target nginx-ui deployment, and the unauthenticated /mcp_message takeover then converts that reconnaissance into full control of the server and its nginx configuration. The pairing is why the activity rose to in-the-wild exploitation rather than staying theoretical: one issue informs the attack, the other executes it. Treat any nginx-ui at version 2.3.3 or below (the NVD CPE range lists up to 2.3.5; the finder reports the fix in 2.3.4) as exposed to both and patch on the same change window - upgrading to 2.3.4 or later (latest is 2.3.6).

Ask AI about Anomity
ChatGPT Claude Perplexity Google AI Grok