Den Kern des Problems bildet laut Pluto Security der MCP-Endpunkt für Nachrichten unter der URL /mcp_message, der Anfragen zur Befehlsausführung verarbeitete und dabei keinerlei Authentifizierung vornahm. Wer diesen Endpunkt erreichen konnte, war damit in der Lage, beliebige administrative Befehle abzusetzen und die Verwaltungsfunktionen von nginx-ui ohne gültige Zugangsdaten direkt zu steuern.
Nach Angaben der nginx-ui-Entwickler kann jeder Angreifer im Netzwerk auf diese Weise „alle MCP-Werkzeuge ohne Authentifizierung aufrufen, darunter NGINX neu starten, Konfigurationsdateien anlegen, ändern oder löschen sowie automatische Neuladevorgänge auslösen — und damit die vollständige Übernahme des NGINX-Dienstes erreichen".
Im MCP-Ablauf verbindet sich ein Client zunächst mit dem Endpunkt /mcp, um eine Sitzung aufzubauen und eine Sitzungs-ID zu erhalten, die anschließend für Befehle über den separaten Endpunkt /mcp_message genutzt wird. Der Sitzungsaufbau über /mcp verlangte eine Authentifizierung mittels eines sogenannten node_secret. Doch auch dieser Schutz war schwach umgesetzt: Bei dem Geheimnis handelte es sich laut Yotam Perkal, Director of Security Research bei Pluto, um einen statischen UUID, der beim ersten Start erzeugt und im Klartext als gemeinsames Geheimnis statt als nutzerspezifische Zugangsinformation gespeichert wurde. In der Praxis bot die Authentifizierung damit kaum Sicherheitsgewinn.
Das node_secret zu beschaffen war zudem oft trivial, so Perkal, da eine weitere Schwachstelle in nginx-ui (CVE-2026-27944) Backups mit der Datei app.ini und Entschlüsselungsschlüsseln offenlegte. War das node_secret erst einmal erbeutet, ließ sich eine MCP-Sitzung aufbauen und anschließend jeder Befehl über /mcp_message ohne weitere Authentifizierung absetzen — was die volle Kontrolle über die von nginx-ui verwaltete NGINX-Umgebung bedeutete.
Hinzu kommt, dass eine IP-Whitelist für den Endpunkt standardmäßig leer ist und damit Verbindungen von jeder beliebigen IP-Adresse zulässt. Das ermöglicht Angriffe aus der Ferne. „Wir haben über Shodan mehr als 2.600 öffentlich erreichbare nginx-ui-Instanzen identifiziert, alle über den Standardport 9000 erreichbar", sagt Perkal. Bei allen Instanzen vor Version 2.3.3 sei die gesamte Angriffskette — unauthentifizierter Download des Backups plus MCP-Übernahme — ohne jegliche Zugangsdaten und ohne Netzwerknähe möglich gewesen. Für Systeme, die bereits auf 2.3.3 aktualisiert wurden — die Version, die die frühere Lücke CVE-2026-27944 schloss —, sei für einen Angriff dagegen in der Regel ein vorheriger Zugang zum lokalen Netzwerk nötig.
Die Folgen wiegen schwer, weil NGINX typischerweise als Reverse-Proxy vor Produktivdiensten steht. „Wer dessen Konfiguration kompromittiert, kompromittiert alles dahinter", sagt Perkal. Im schlimmsten Fall könne ein Angreifer Server-Blöcke so umschreiben, dass der gesamte Verkehr über einen von ihm kontrollierten Endpunkt läuft, und so jede Anfrage, Antwort und Zugangsinformation im Transit abgreifen. Ebenso lasse sich eine ungültige Konfiguration einspielen und ein Neuladen auslösen, das NGINX samt aller dahinterliegenden Anwendungen und APIs lahmlegt. Auch eine vollständige Erkundung der Architektur werde möglich — bis hin zu Backend-Topologie, Upstream-Servern, Pfaden zu TLS-Zertifikaten und internen Dienstadressen.
Perkal ordnet den Fall in eine Reihe neuer Risiken ein, die entstehen, wenn Organisationen bestehende Anwendungen um MCP-Unterstützung erweitern. „Wenn man MCP zu einer bestehenden Anwendung hinzufügt, legt man deren mächtigste Operationen über neue HTTP-Endpunkte offen", sagt er. Die Kernanwendung verfüge womöglich über jahrelang erprobte Authentifizierung, doch die MCP-Endpunkte seien neu — und leicht zu übersehen. Besonders heikel sei der von MCP genutzte HTTP-Streaming-Mechanismus, weil er die Kommunikation auf zwei Endpunkte aufteile: „Entwickler schützen intuitiv den ‚Verbindungs’-Endpunkt, aber nicht den ‚Nachrichten’-Endpunkt", an dem die eigentlich zerstörerischen Operationen stattfinden.