PERMISSION/PROTOCOL
Back to incident tracker

2026-04-01

CriticalPrimary

nginx-ui MCPwn: Empty IP Whitelist Treated as Allow-All Grants Zero-Credential Access to All 12 MCP Tools on 2,600+ Exposed Instances (CVE-2026-33032, CVSS 9.8)

nginx-ui's /mcp_message endpoint used IP whitelisting where default empty whitelist was treated as allow-all. Zero-credential access to all 12 privileged MCP tools. 2,600+ exposed instances. PoC published; actively exploited. CVSS 9.8.

nginx-uiTool execution / MCPAuthentication bypass: default insecure configuration grants unauthenticated MCP access2,600+ internet-exposed nginx-ui instances / all 12 MCP tools

What happened

Attackers sent unauthenticated requests to the /mcp_message endpoint on internet-exposed nginx-ui instances. With no credentials required (empty whitelist = allow-all), all 12 privileged MCP tools were accessible. Active exploitation confirmed with PoC published.

Why it matters

2,600+ nginx-ui instances exposed all 12 privileged MCP tools to unauthenticated internet access. Attackers could execute any MCP tool with zero credentials — webserver configuration changes, file operations, and system commands depending on configured MCP tool capabilities.

Missing authorization check

MCP endpoints must default to deny-all. Empty or missing access control lists must be interpreted as deny-all, not allow-all. Authentication should be required by default for any MCP tool endpoint regardless of whitelist configuration.

Would PP block it?

If MCP tool execution required PP receipts, unauthenticated attackers could not obtain valid receipts and would be blocked from tool execution. The underlying empty-whitelist-means-allow-all bug requires a code fix to the nginx-ui access control logic.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-04-01

    CVE-2026-33032 published: nginx-ui empty IP whitelist treated as allow-all, granting zero-credential access to all 12 MCP tools. 2,600+ exposed instances. CVSS 9.8.

  2. 2026-04-01

    PoC published. Active exploitation in the wild confirmed.

Technical breakdown

  • nginx-ui's /mcp_message endpoint checked if the requesting IP was in the configured whitelist.
  • When the whitelist was empty (default configuration), the check evaluated to allow-all rather than deny-all.
  • All 12 privileged MCP tools were exposed without any authentication requirement when the default was in effect.
  • 2,600+ internet-exposed instances with default configuration provided a large unauthenticated attack surface.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Runtime Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
MCP tool call execution, authentication enforcement
Still needs
Default-deny access control; authentication required before MCP endpoint access
Receipt required for
Any MCP tool invocation, /mcp_message endpoint access

PP's Runtime Gate would require receipts for MCP tool execution. Unauthenticated tool calls without valid receipts would be blocked. PP does not fix the underlying authentication bypass — that requires the application to enforce auth before tools are invoked.

Start small

Put the relevant gate at this action boundary.

This incident maps to Runtime Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop