Jak można było zmieniać konfigurację przez endpoint MCP – podatność w Nginx UI

Badacze z Pluto Security odkryli krytyczną podatność (9,8 w skali CVSS), która pozwalała modyfikować konfigurację nginx na serwerze korzystającym z Nginx UI. Otrzymała ona numer CVE-2026-33032.

Nginx UI to narzędzie do zarządzania serwerem i monitorowaniem jego stanu za pomocą panelu webowego. Repozytorium na GitHub ma prawie 11 tys. gwiazdek, a kontener Dockera został pobrany ponad 430 tysięcy razy.

TLDR:

• Badacze z Pluto Security ujawnili podatność (CVE-2026-33032) w Nginx UI (CVSS 9.8).

• Endpoint /mcp_message nie miał pełnego uwierzytelniania, a whitelista IP była domyślnie pusta i dopuszczała wszystkie adresy.
• Atakujący mógł zmieniać konfigurację nginx, restartować usługę i odczytywać pliki konfiguracyjne.
• Problem naprawiono w wersji 2.3.4. Administratorzy powinni zaktualizować instancje i ograniczyć ich dostępność.

Jak przystało na 2026 rok, oczywiście mamy tu do dyspozycji integrację z AI. I to właśnie ona okazała się w tym przypadku zdradliwa. Aby systemy agentowe i inne narzędzia mogły łączyć się z Nginx UI i wykonywać operacje, wystawiane są endpointy MCP (Model Context Protocol).

Mowa o dwóch:

• GET /mcp – otwiera połączenie SSE (Server-Sent Events). Tutaj zwrócona będzie odpowiedź np. z wynikiem wykonanej operacji. Ten endpoint przydziela również ID sesji.
• POST /mcp_message – tutaj wysyłane są faktyczne żądania.

Badacze sprawdzili kod odpowiedzialny za routing tych endpointów:

Zapewne wprawni czytelnicy już przynajmniej jedną ręką złapali się za głowę.

Endpoint /mcp korzysta z dwóch middlewares – IPWhiteList() i AuthRequired(). Z kolei /mcp_message wykorzystuje tylko IPWhiteList(). Oba prowadzą do tego samego handlera, ale dla /mcp_message pomijane jest uwierzytelnianie. 

Mogłoby się wydawać, że to nie aż taki poważny problem, skoro weryfikowany jest adres IP. Nazwa middleware sugeruje, że dopuszczane są jedynie zatwierdzone przez administratora adresy (whitelista), ale to nie do końca prawda.

Faktycznie weryfikacja IP działa w mechanizmie whitelist, ale domyślnie lista jest pusta. A gdy jest pusta – choć teoretycznie żadne żądanie nie powinno być dopuszczone – przyjmowane są wszystkie żądania.

Pusta whitelista działa w tym przypadku jak pusta blacklista. Jeśli administrator danego serwera jej nie skonfigurował, dowolny atakujący mógłby uzyskać dostęp do narzędzi Nginx UI w ramach MCP.

Mowa o 12 narzędziach, spośród których 7 może modyfikować konfigurację nginx:

• nginx_config_add – tworzy pliki konfiguracyjne + automatycznie przeładowuje nginx,
• nginx_config_modify – modyfikuje dowolną istniejącą konfigurację,
• nginx_config_enable – włącza/wyłącza strony,
• nginx_config_rename – zmienia nazwy plików konfiguracyjnych,
• nginx_config_mkdir – tworzy katalogi,
• reload_nginx – przeładowuje konfigurację,
• restart_nginx – restartuje proces,

a także 5 narzędzi tylko do odczytu:

• nginx_config_get – odczytuje dowolny plik konfiguracyjny,
• nginx_config_list – wyświetla wszystkie konfiguracje,
• nginx_config_base_path – wskazuje ścieżkę katalogu konfiguracyjnego,
• nginx_config_history – zwraca historię zmian konfiguracji,
• nginx_status – zwraca status serwera.

Utworzenie sesji do komunikacji przez SSE wymagało posiadania prawidłowego tokenu node_secret, którym uwierzytelniane było żądanie do /mcp. W opublikowanym Security Advisory wskazano, że możliwe jest wykonanie złośliwego żądania do /mcp_message bez parametru sessionId. Taka możliwość oznaczałaby, że modyfikacja konfiguracji nginx była wykonalna bez standardowego uwierzytelnienia.

W artykule Pluto Security pokazywane są jednak dwa żądania – najpierw do /mcp w celu utworzenia sesji (tu wymagane jest uwierzytelnienie), a dopiero następnie do /mcp_message.

Faktem jest jednak, że identyfikator SSE (sessionId) – nawet jeśli poprawnie weryfikowany – nie powinien zastępować mechanizmu uwierzytelniania, zwłaszcza dla tak wrażliwych endpointów.

Patrząc na dostępne narzędzia, z poziomu MCP w Nginx UI możliwe byłoby m.in.:

• przechwytywanie całego ruchu do serwera przez atakującego,
• wykradnięcie nagłówków (np. Authorization) przez zmianę konfiguracji logów,
• odczytywanie wszystkich plików konfiguracyjnych nginx,
• wyłączenie stron działających na serwerze (efekt: Denial of Service).

Badacze w ramach Proof of Concept wykorzystali narzędzie nginx_config_add, dzięki czemu serwer natychmiast zaczął serwować dowolne treści:

Podatność została załatana w wersji v2.3.4 (wydanej dzień po zgłoszeniu badaczy). Poprawka polegała na dopisaniu dodatkowego middleware do endpointu /mcp_message. Dodatkowo pokryto ten obszar testem regresyjnym.

Użytkownikom Nginx UI zalecamy aktualizację do najnowszej wersji oraz skonfigurowanie whitelisty IP, ograniczając dostęp tylko dla zaufanych hostów. Warto też przejrzeć logi i konfigurację pod kątem nieoczekiwanej aktywności/zmian.

Tego typu narzędzia zazwyczaj nie muszą być dostępne publicznie z Internetu. Warto schować je za VPN-em, a ewentualne konieczne endpointy wystawić przez reverse proxy z dodatkowym (niezależnym od samej aplikacji) uwierzytelnieniem (np. HTTP Basic Auth). W przypadku tej podatności, mogłoby to zapobiec atakowi, ponieważ atakujący nie miałby dostępu do endpointów MCP.

Programistom przypominamy, że endpointy MCP należy zabezpieczać tak samo jak API – zapewniając dla każdego z nich poprawne uwierzytelnienie i autoryzację. Warto także pokryć ten obszar testami. Jeśli weryfikujemy dostęp na zasadzie whitelisty, powinna ona być whitelistą – jeśli nic na niej nie ma, to znaczy że nikt nie ma dostępu do zasobu.

Źródło: pluto.security

~Tymoteusz Jóźwiak