MCPwn: Wie die MCP-Integration nginx-ui in eine Remote-Übernahme verwandelte

SSL Reverse Proxy with Nginx, Let's Encrypt, and CrowdSec: Production Guide

How to deploy a production-grade reverse proxy with automatic SSL certificate management, WAF/IPS protection via CrowdSec, and proper security hardening.

Am 30. März 2026 veröffentlichte das NVD die CVE-2026-33032, eine Schwachstelle mit einem CVSS-Score von 9,8 und einem Codenamen, der bereits alles über ihre Bedeutung aussagt. Yotam Perkal, ein Forscher bei Pluto Security, nannte sie MCPwn. Die Lücke ermöglicht die unauthentifizierte Remote-Übernahme jeder nginx-ui-Instanz, bei der die Model Context Protocol-Integration aktiviert ist. Keine Anmeldedaten, keine Benutzerinteraktion, keine besonderen Bedingungen. Nur zwei HTTP-Requests und der Angreifer besitzt den nginx-Service.

Die Schwachstelle

nginx-ui ist ein Open-Source-Webinterface zur Verwaltung von nginx-Servern. In neueren Versionen fügte das Projekt MCP-Support hinzu und stellte zwei HTTP-Endpunkte für die Interaktion mit KI-Tools bereit: /mcp und /mcp_message.

Das Problem ist eine Inkonsistenz bei der Authentifizierung zwischen den beiden. Der /mcp-Endpunkt erzwingt ordnungsgemäß sowohl das IP-Whitelisting als auch die AuthRequired()-Middleware. Der /mcp_message-Endpunkt führt lediglich die IP-Whitelist-Prüfung aus. Und hier liegt das kritische Detail: Die Standard-IP-Whitelist ist leer, was die Middleware als „alle zulassen“ interpretiert.

Der betroffene Code in mcp/router.go macht dies deutlich sichtbar:

r.Any("/mcp", middleware.IPWhiteList(), middleware.AuthRequired(), ...)
r.Any("/mcp_message", middleware.IPWhiteList(), ...)
```text

Beide Routen führen über denselben `mcp.ServeHTTP()`-Handler, der alle MCP-Tool-Aufrufe verarbeitet. Der `/mcp`-Endpunkt verlangt eine Authentifizierung. `/mcp_message` tut dies nicht. Bei einer leeren Whitelist bedeutet das: null Sicherheit am zweiten Endpunkt.

## Der Exploit

Perkal demonstrierte, dass der vollständige Angriff in Sekunden mit nur zwei Requests abgeschlossen ist.

Zuerst sendet der Angreifer einen HTTP GET an `/mcp`, um eine Sitzung zu etablieren und eine Session-ID zu erhalten. Zweitens sendet er einen HTTP POST an `/mcp_message` unter Verwendung dieser Session-ID, um ein beliebiges MCP-Tool aufzurufen. Keine Authentifizierungs-Header, keine Token, keine Cookies.

Die von nginx-ui bereitgestellten MCP-Tools beinhalten die Fähigkeit, den nginx-Prozess neu zu starten, Konfigurationen neu zu laden, neue Konfigurationsdateien zu erstellen, bestehende zu ändern oder diese vollständig zu löschen. Ein Angreifer kann Server-Blöcke umschreiben, um den Traffic über seine eigene Infrastruktur zu proxien und so Anmeldedaten und Session-Token abzufangen. Er kann den Dienst auch einfach abschalten. Die Tools entsprechen direkt der vollständigen Kontrolle über den nginx-Service, und jedes einzelne ist ohne Authentifizierung über `/mcp_message` zugänglich.

## Der Umfang

Shodan-Daten zeigen etwa 2.689 nginx-ui-Instanzen, die im öffentlichen Internet exponiert sind, wobei der Großteil in China, den Vereinigten Staaten, Indonesien, Deutschland und Hongkong liegt. Die CVE wurde am 30. März 2026 veröffentlicht, und der wöchentliche Threat Report von Recorded Future führte sie diese Woche unter den 31 am häufigsten ausgenutzten Schwachstellen für März auf. CISA und VulnCheck haben beide eine aktive Ausnutzung in der freien Wildbahn bestätigt.

Der Fix wurde in der nginx-ui-Version 2.3.4 ausgeliefert, die am 15. März 2026 veröffentlicht wurde – zwei Wochen bevor die CVE öffentlich bekannt wurde. Dieser Zeitplan bedeutet, dass bereits ein Patch existierte, bevor die Schwachstelle weit verbreitet war, aber die Lücke zwischen dem Fix und der tatsächlichen Implementierung auf diesen 2.689 exponierten Instanzen hat Angreifern ein erhebliches Zeitfenster geboten.

Für Organisationen, die nicht sofort upgraden können, empfehlen die nginx-ui-Maintainer zwei Workarounds: das Hinzufügen von `middleware.AuthRequired()` zur `/mcp_message`-Route oder die Änderung des Standardverhaltens der IP-Whitelist von „allow all“ auf „deny all“.

## Warum MCP das Problem ist

Perkal formulierte das Kernproblem prägnant: „Wenn man MCP an eine bestehende Anwendung anbindet, erben die MCP-Endpunkte die vollen Funktionen der Anwendung, aber nicht notwendigerweise deren Sicherheitskontrollen. Das Ergebnis ist eine Backdoor, die jeden Authentifizierungsmechanismus umgeht, mit dem die Anwendung sorgfältig aufgebaut wurde.“

MCP wurde als Protokoll konzipiert, damit KI-Modelle Tools aufrufen können. Es wurde nicht als Remote-Management-Protokoll entwickelt. Das Sicherheitsmodell geht davon aus, dass der MCP-Client ein vertrauenswürdiger KI-Assistent ist, der im Namen eines authentifizierten Benutzers agiert. Wenn man MCP-Endpunkte direkt im Netzwerk exponiert, bricht diese Annahme zusammen. Das Protokoll verfügt über keine integrierte Authentifizierungsschicht. Es gibt keine Session-Validierung über das hinaus, was die Host-Anwendung bereitstellt. Und im Fall von nginx-ui hat die Host-Anwendung vergessen, für den gefährlichsten Endpunkt überhaupt eine solche bereitzustellen.

Dies ist keine subtile Race Condition oder ein komplexer Logikfehler. Es ist ein simpler Authentifizierungs-Bypass, der daraus resultierte, dass eine KI-Tool-Schnittstelle so behandelt wurde, als sei sie nur eine weitere API-Route.

## Verbindung zu „Comment and Control“

Die MCPwn-Offenlegung erfolgt parallel zu einem verwandten Muster von KI-Integrationsschwachstellen. Anfang dieses Monats veröffentlichte der Forscher Aonan Guan „Comment and Control“ und demonstrierte, wie KI-Agenten in GitHub Actions über Claude Code, Gemini CLI und GitHub Copilot durch Prompt-Injection in GitHub-Daten wie PR-Titeln und Issue-Kommentaren gekapert werden konnten. Diese Forschung zeigte, wie KI-Agenten, denen mächtige Tools und Produktions-Secrets in derselben Runtime zur Verfügung gestellt werden, die nicht vertrauenswürdige Eingaben verarbeitet, in Kanäle zur Exfiltration von Anmeldedaten verwandelt werden können.

MCPwn und Comment and Control teilen dasselbe Grundmuster: LLM-orientierte Endpunkte oder KI-Tool-Integrationen, die mit unzureichenden Authentifizierungsgrenzen bereitgestellt wurden. Bei Comment and Control ist die Injektionsfläche GitHub-Daten, die von einem KI-Agenten verarbeitet werden. Bei MCPwn ist die Injektionsfläche ein unauthentifizierter HTTP-Endpunkt, der zufällig ein KI-Protokoll bedient. Der Mechanismus unterscheidet sich, aber das Ergebnis ist identisch: Ein Angreifer umgeht jede Sicherheitskontrolle, die die Anwendung eigentlich erzwingen sollte.

## Weitreichendere Auswirkungen

nginx-ui ist kein Einzelfall. Beim Atlassian MCP-Server, `mcp-atlassian`, wurden zwei verkettete Schwachstellen gefunden, CVE-2026-27825 (CVSS 9.1) und CVE-2026-27826 (CVSS 8.2), die gemeinsam als MCPwnfluence bezeichnet werden. Diese Fehler ermöglichten es jedem Angreifer im selben lokalen Netzwerk, eine Remote-Code-Execution zu erreichen. Akademische Forschung zur MCP-Sicherheit, einschließlich auf arXiv veröffentlichter Arbeiten zu Tool-Poisoning, Shadowing und Rug-Pull-Angriffen, hat wiederholt gezeigt, dass das Vertrauensmodell des Protokolls fundamental schwach ist.

Das Muster ist klar: Jeder MCP-Endpunkt, der ohne bewusste Authentifizierung und Netzwerksegmentierung in einem Netzwerk exponiert wird, ist ein potenzieller vollständiger Systemkompromiss. Das Protokoll schützt Sie nicht. Ihr Application-Wrapper muss es tun, und wie nginx-ui gezeigt hat, ist dieser Wrapper leicht falsch zu konfigurieren.

## Mitigation

Wenn Sie nginx-ui betreiben, aktualisieren Sie sofort auf Version 2.3.4 oder neuer. Wenn Sie nicht aktualisieren können, deaktivieren Sie MCP vollständig oder beschränken Sie den Netzwerkzugriff auf die Management-Schnittstelle auf Firewall-Ebene. Gehen Sie nicht davon aus, dass eine leere IP-Whitelist „deny all“ bedeutet, denn in nginx-ui bedeutet sie das Gegenteil.

Über nginx-ui hinaus ist dies ein Weckruf für jedes Team, das MCP in Produktionssysteme integriert. Auditieren Sie heute jeden MCP-Endpunkt in Ihrer Infrastruktur. Prüfen Sie, ob die Authentifizierung auf allen Routen erzwungen wird, nicht nur auf den offensichtlichen. Verifizieren Sie, dass Standardkonfigurationen nicht stillschweigend den Zugriff für die ganze Welt gewähren. Und denken Sie daran, dass MCP für die Nutzung von KI-Tools in einem vertrauenswürdigen Kontext entwickelt wurde, nicht als allgemeines Remote-Management-Protokoll. Behandeln Sie es dementsprechend.

NVD-Eintrag: <https://nvd.nist.gov/vuln/detail/CVE-2026-33032>