Two days ago, a CVSS 9.8 vulnerability in nginx-ui — an open-source web management interface for Nginx — went public. It's being actively exploited in the wild. The attack takes two HTTP requests and about four seconds. The result is complete Nginx server takeover.
The vulnerability is CVE-2026-33032, and the researcher who found it gave it a name that says everything: MCPwn.
The root cause isn't a buffer overflow. It isn't a SQL injection. It's an MCP endpoint that skipped authentication.
What happened
nginx-ui added MCP (Model Context Protocol) integration to let AI agents manage Nginx servers. They exposed two endpoints:
/mcp— requires authentication and IP whitelisting/mcp_message— requires only IP whitelisting
The problem: the default IP whitelist is empty. And the middleware interprets an empty whitelist as "allow all."
So an attacker sends a GET to /mcp to establish a session (using credentials stolen from a separate vulnerability in the backup endpoint), then a POST to /mcp_message with that session ID. No authentication headers. No tokens. Two requests, full control.
The MCP tools exposed through this endpoint can restart Nginx, create and modify configuration files, and trigger config reloads. An attacker with this access can intercept all traffic passing through the server, harvest administrator credentials, and pivot into the network.
There are roughly 2,600 instances exposed on the public internet.
The pattern, not the bug
The same week, two more MCP vulnerabilities dropped — CVE-2026-27825 and CVE-2026-27826 in the Atlassian MCP server. Unauthenticated remote code execution from the local network. The researchers called it MCPwnfluence.
This isn't a coincidence. It's a pattern.
MCP gives AI agents the ability to invoke tools. Those tools inherit the application's full capabilities. But when developers add MCP endpoints to existing applications, the security controls that protect the application's normal interfaces don't automatically extend to the MCP surface.
The researcher who found MCPwn put it plainly: 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.
This is the core problem Hermetic was built to solve.
How Hermetic prevents every step of this attack
The MCPwn attack chain has five steps. Here's how Hermetic's architecture blocks each one.
Step 1: Unauthenticated MCP access. nginx-ui's /mcp_message endpoint allows unauthenticated requests by default. Hermetic requires binary attestation on every connection. The daemon reads /proc/pid/exe of the connecting process, computes its SHA-256 hash, and verifies it against a known-good binary hash. There is no "allow all" default.
Step 2: Session token reuse from a different process. nginx-ui's session ID works from any process on any machine. Hermetic's session tokens are PID-bound. A token stolen from one process is rejected when used from a different PID. Additionally, every message carries SCM_CREDENTIALS — kernel-verified sender identity on every message, not just the first.
Step 3: MCP tools with excessive privileges. nginx-ui's MCP tools can restart the server and rewrite configs. Hermetic's six MCP tools cannot modify the daemon or its configuration. They broker API requests — the agent says "call this API" and gets back the response. The agent never controls the daemon.
Step 4: Credential theft via backup endpoint. nginx-ui's backup endpoint leaks encryption keys without auth. Hermetic's vault is encrypted with AES-256-GCM using a key derived from the user's passphrase via Argon2id. There is no backup endpoint. There is no API that exposes encryption keys.
Step 5: Network-accessible attack surface. nginx-ui's MCP endpoints are HTTP on the network — Shodan finds 2,600+ instances. Hermetic's daemon listens exclusively on a Unix Domain Socket. It has no network presence. You cannot find Hermetic on Shodan because it doesn't exist on the network.
The table
| Attack step | nginx-ui | Hermetic |
|---|---|---|
| Unauthenticated MCP access | Default: allow all | Binary attestation on every connection |
| Session token reuse | Session ID works from any process | PID-bound tokens + per-message SCM_CREDENTIALS |
| Excessive MCP privileges | Restart server, modify configs | Read-only + brokered API calls only |
| Credential theft | Backup endpoint leaks keys | Argon2id vault, no backup API, no shared secrets |
| Network exposure | HTTP on all interfaces | Unix Domain Socket only, zero network presence |
Why this keeps happening
The MCP specification defines a protocol for AI agents to invoke tools. It does not define a security boundary. Authentication, authorization, credential isolation, and process identity verification are left as implementation details.
Most implementations treat these as afterthoughts. nginx-ui added IP whitelisting. The Atlassian MCP server relied on localhost binding. Both were bypassed.
The problem isn't that these teams are careless. The problem is that MCP makes it easy to give agents power and hard to verify who's asking. The protocol has no built-in concept of "prove you are who you claim to be before I execute this tool."
Hermetic exists because we believe credential security for AI agents requires a dedicated architectural layer, not a middleware flag on an existing application. The daemon is the security boundary. The agent never crosses it.
What to do
If you run nginx-ui: update to version 2.3.4 immediately. If you can't update, add middleware.AuthRequired() to the /mcp_message endpoint.
If you're building MCP integrations: ask yourself what happens if your MCP endpoint's authentication is bypassed. If the answer is "full application takeover," your MCP surface needs its own security boundary — not inherited middleware from the rest of your application.
If you're an AI agent developer shipping credentials to your agents: consider whether those credentials should be in agent memory at all. Hermetic's model — where the daemon holds credentials and the agent sees only responses — eliminates the entire class of attacks where a compromised MCP endpoint leads to credential theft.
The agent doesn't need your API key. It needs the API response.