MCPwn: How MCP Integration Turned nginx-ui Into a Remote Takeover
~6 min read
DevOpsSecuritymcpnginxsecurityvulnerabilitycveai-integrationattack-surface
Save products you love by clicking the heart icon.
We use privacy-friendly analytics (Plausible + Umami) to understand how visitors use this site. No analytics are loaded without your consent. Privacy Policy
Comprehensive technical analysis of the Miasma (Shai-Hulud) self-replicating supply-chain worm: Phantom Gyp binding.gyp execution, AI coding agent persistence hooks, 73 Microsoft repositories compromised, 448+ artifacts across npm/PyPI, credential harvesting scope, and defensive countermeasures.
Production patterns for managing secrets in GitOps workflows: Sealed Secrets, External Secrets Operator, SOPS, and HashiCorp Vault integration with ArgoCD.
On 30 March 2026, the NVD published CVE-2026-33032, a vulnerability carrying a CVSS 9.8 score and a codename that tells you everything about why it matters. Yotam Perkal, a researcher at Pluto Security, dubbed it MCPwn. The flaw allows unauthenticated remote takeover of any nginx-ui instance with the Model Context Protocol integration enabled. No credentials, no user interaction, no special conditions. Just two HTTP requests and the attacker owns the nginx service.
nginx-ui is an open-source web interface for managing nginx servers. In recent versions, the project added MCP support, exposing two HTTP endpoints for AI tool interaction: /mcp and /mcp_message.
The problem is an authentication mismatch between the two. The /mcp endpoint properly enforces both IP whitelisting and the AuthRequired() middleware. The /mcp_message endpoint only runs the IP whitelist check. And here is the critical detail: the default IP whitelist is empty, which the middleware interprets as "allow all."
The vulnerable code in mcp/router.go makes this plainly visible:
r.Any("/mcp", middleware.IPWhiteList(), middleware.AuthRequired(), ...)
r.Any("/mcp_message", middleware.IPWhiteList(), ...)
```text
Both routes funnel through the same `mcp.ServeHTTP()` handler, which processes all MCP tool invocations. The `/mcp` endpoint demands authentication. `/mcp_message` does not. With an empty whitelist, that means zero security on the second endpoint.
## The Exploit
Perkal demonstrated that the full attack completes in seconds with just two requests.
First, the attacker sends an HTTP GET to `/mcp` to establish a session and obtain a session ID. Second, they send an HTTP POST to `/mcp_message` carrying that session ID to invoke any MCP tool. No authentication headers, no tokens, no cookies.
The MCP tools exposed by nginx-ui include the ability to restart the nginx process, reload configurations, create new config files, modify existing ones, and delete them entirely. An attacker can rewrite server blocks to proxy traffic through their own infrastructure, intercepting credentials and session tokens. They can also simply shut the service down. The tools map directly to full nginx service control, and every single one is accessible without authentication through `/mcp_message`.
## The Scope
Shodan data shows roughly 2,689 nginx-ui instances exposed to the public internet, with the bulk located in China, the United States, Indonesia, Germany, and Hong Kong. The CVE was published on 30 March 2026, and Recorded Future's weekly threat report this week listed it among the 31 most-exploited vulnerabilities for March. CISA and VulnCheck have both confirmed active exploitation in the wild.
The fix shipped in nginx-ui version 2.3.4, released on 15 March 2026, two weeks before the CVE went public. That timeline means a patch existed before widespread disclosure, but the gap between the fix and actual deployment across those 2,689 exposed instances has given attackers a substantial window.
For organisations unable to upgrade immediately, the nginx-ui maintainers recommend two workarounds: adding `middleware.AuthRequired()` to the `/mcp_message` route, or changing the default IP whitelist behaviour from "allow all" to "deny all."
## Why MCP Is the Problem
Perkal framed the core issue succinctly. "When you bolt MCP onto an existing application, the MCP endpoints inherit the application's full capabilities but not necessarily its security controls. The result is a backdoor that bypasses every authentication mechanism the application was carefully built with."
MCP was designed as a protocol for AI models to invoke tools. It was not designed as a remote management protocol. The security model assumes the MCP client is a trusted AI assistant operating on behalf of an authenticated user. When you expose MCP endpoints directly to the network, that assumption collapses. The protocol has no built-in authentication layer. It has no session validation beyond what the hosting application provides. And in nginx-ui's case, the hosting application forgot to provide any at all for the most dangerous endpoint.
This is not a subtle race condition or a complex logic bug. It is a straightforward authentication bypass that arose from treating an AI tool interface as if it were just another API route.
## Connection to Comment and Control
The MCPwn disclosure lands alongside a related pattern of AI integration vulnerabilities. Earlier this month, researcher Aonan Guan published "Comment and Control," demonstrating how AI agents in GitHub Actions across Claude Code, Gemini CLI, and GitHub Copilot could be hijacked through prompt injection in GitHub data like PR titles and issue comments. That research showed how AI agents given powerful tools and production secrets in the same runtime that processes untrusted input can be turned into credential exfiltration channels.
MCPwn and Comment and Control share the same root pattern: LLM-facing endpoints or AI tool integrations deployed with insufficient authentication boundaries. In Comment and Control, the injection surface is GitHub data processed by an AI agent. In MCPwn, the injection surface is an unauthenticated HTTP endpoint that happens to serve an AI protocol. The mechanism differs, but the outcome is identical. An attacker bypasses every security control the application was supposed to enforce.
## Broader Implications
nginx-ui is not an isolated case. The Atlassian MCP server, `mcp-atlassian`, was found to carry two chained vulnerabilities, CVE-2026-27825 (CVSS 9.1) and CVE-2026-27826 (CVSS 8.2), collectively dubbed MCPwnfluence. Those flaws allowed any attacker on the same local network to achieve remote code execution. Academic research on MCP security, including work published on arXiv examining tool poisoning, shadowing, and rug pull attacks, has repeatedly shown that the protocol's trust model is fundamentally thin.
The pattern is clear. Any MCP endpoint exposed to a network, without deliberate authentication and network segmentation, is a potential full system compromise. The protocol does not protect you. Your application wrapper has to, and as nginx-ui showed, that wrapper is easy to get wrong.
## Mitigation
If you run nginx-ui, upgrade to version 2.3.4 or later immediately. If you cannot upgrade, either disable MCP entirely or restrict network access to the management interface at the firewall level. Do not assume that an empty IP whitelist means "deny all," because in nginx-ui it means the opposite.
Beyond nginx-ui, this is a wake-up call for every team integrating MCP into production systems. Audit every MCP endpoint in your infrastructure today. Check whether authentication is enforced on all routes, not just the obvious ones. Verify that default configurations do not silently grant access to the world. And remember that MCP was built for AI tool use within a trusted context, not as a general-purpose remote management protocol. Treat it accordingly.
NVD entry: <https://nvd.nist.gov/vuln/detail/CVE-2026-33032>