Nginx UI is a web user interface for the Nginx web server

CVE-2026-33032 is an authentication bypass in nginx-ui's MCP transport. In vulnerable builds, /mcp enforces both IP allowlisting and AuthRequired() middleware, but /mcp_message only checks the IP allowlist; with the default empty allowlist behaving as allow-all, a remote attacker can invoke privileged MCP tools without credentials. The NVD record says versions through 2.3.5 are affected, but Pluto's source-level analysis says the last truly vulnerable version is 2.3.3 and the fix landed in 2.3.4 on 2026-03-15.

The vendor's 9.8/CRITICAL rating is technically understandable because this is unauthenticated network access to config write/reload primitives on a front-door infrastructure component. In enterprise reality, though, the decisive friction is exposure population: nginx-ui is an admin plane, not a mass-deployed end-user service, and most mature shops should not have it broadly internet-exposed. That keeps this out of top-tier emergency-for-everyone territory, but public PoC, active exploitation reporting, and the ability to hijack traffic keep it firmly HIGH.

Why this verdict

• Downgrade for exposure reality: this requires a reachable nginx-ui management interface, which implies a narrower target population than generic public web apps.
• Still high because auth is absent: for exposed targets the attacker needs no credentials, no user interaction, and minimal exploit development thanks to public write-ups and PoC details.
• Blast radius is operationally ugly: control of nginx config and reload behavior can mean traffic interception, token capture, outage, or persistent proxy manipulation on production edge systems.

Why not higher?

I am not calling this CRITICAL because the attack path starts with a very nontrivial assumption: the organization's nginx-ui admin surface is reachable to the attacker. In mature enterprises that should be VPN-only, internal-only, or otherwise segmented, which means the vendor CVSS overstates how many of your 10,000 hosts are actually exposed to unauthenticated initial access.

Why not lower?

I am not dropping this to MEDIUM because there is no meaningful exploit friction after reachability. The bug is cleanly unauthenticated, exploitation has been publicly documented, active exploitation has been reported, and the impact lands on a traffic-handling control plane rather than a low-value auxiliary service.

1. Block external reachability — Put nginx-ui behind VPN, bastion, or strict source-IP ACLs within hours because active exploitation has been reported. This is the highest-value control: it attacks the main friction point that determines whether the bug is internet-initial-access or merely post-compromise.
2. Disable MCP if unused — If your admins are not actively using AI/MCP workflows, turn off the MCP surface within hours. The vulnerable path is the MCP transport itself, so removing that feature collapses this CVE's exploit chain.
3. Set a real IP allowlist — Do not leave the default empty allowlist in place; populate it with known admin jump hosts or management subnets within hours. Even on vulnerable builds, a tight allowlist sharply reduces attacker reachability.
4. Hunt for config abuse — Review access logs, nginx reload events, and file changes under conf.d/, sites-available/, and sites-enabled/ within hours for evidence of malicious MCP tool use. This matters because the post-exploitation outcome is often config tampering rather than a noisy shell.
5. Prioritize exposed instances first — Internet-facing or DMZ nginx-ui nodes should be isolated and remediated before internal-only lab systems. The real severity multiplier here is exposure plus the importance of the nginx tier being managed.

Run this on the target host or from a trusted admin box that can reach the local nginx-ui service. Invoke it as bash check-cve-2026-33032.sh http://127.0.0.1:9000; no root is required unless you also need to read a protected local config to determine the port.

#!/usr/bin/env bash
# check-cve-2026-33032.sh
# Runtime behavior check for CVE-2026-33032 in nginx-ui.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / could not determine

set -u

BASE_URL="${1:-http://127.0.0.1:9000}"
TMP_HEADERS_1="$(mktemp)"
TMP_HEADERS_2="$(mktemp)"
trap 'rm -f "$TMP_HEADERS_1" "$TMP_HEADERS_2"' EXIT

curl_code() {
  local method="$1"
  local url="$2"
  local headers_file="$3"
  local body="${4:-}"

  if [[ "$method" == "GET" ]]; then
    curl -k -sS -o /dev/null -D "$headers_file" -w '%{http_code}' \
      --max-time 10 "$url" 2>/dev/null || echo "000"
  else
    curl -k -sS -o /dev/null -D "$headers_file" -w '%{http_code}' \
      --max-time 10 -X "$method" \
      -H 'Content-Type: application/json' \
      --data "$body" "$url" 2>/dev/null || echo "000"
  fi
}

MCP_CODE="$(curl_code GET "$BASE_URL/mcp" "$TMP_HEADERS_1")"
MSG_CODE="$(curl_code POST "$BASE_URL/mcp_message" "$TMP_HEADERS_2" '{}')"

# Patched behavior documented by regression test: both unauthenticated endpoints return 403.
if [[ "$MCP_CODE" == "403" && "$MSG_CODE" == "403" ]]; then
  echo "PATCHED"
  exit 0
fi

# Vulnerable signature: /mcp blocks unauthenticated access, but /mcp_message does not.
# On vulnerable systems /mcp_message commonly returns something other than 403
# (for example 200/400/404 depending on session handling), which is enough to show
# the missing authentication middleware.
if [[ "$MCP_CODE" == "403" && "$MSG_CODE" != "403" && "$MSG_CODE" != "000" ]]; then
  echo "VULNERABLE"
  exit 1
fi

# If the service is unreachable or behavior is inconsistent, do not guess.
echo "UNKNOWN"
exit 2

Sources

1. GitHub Security Advisory GHSA-h6c2-x2m2-mwhf
2. NVD CVE-2026-33032
3. Pluto Security technical analysis
4. Fix commit 413dc63
5. Rapid7 ETR on CVE-2026-33032
6. Deepwatch advisory on active exploitation
7. Nginx UI MCP documentation
8. Nginx UI server configuration documentation