CVE-2026-67394 w Plesk: klient z shellem może przejąć roota serwera

CVE-2026-67394 to krytyczna lokalna eskalacja uprawnień w Plesk for Linux. Klient lub reseller mający dostęp do powłoki — albo prawo do zmiany własnego ustawienia dostępu shell — może przez OS command injection uzyskać kontrolę root nad serwerem. Luka obejmuje Plesk Obsidian 18.0.34–18.0.79.8 oraz 18.0.80–18.0.80.4. Poprawki znajdują się odpowiednio w 18.0.79.9 i 18.0.80.5.

Plesk for Windows nie jest objęty tym CVE. Rekord opublikowany dziś w NVD ma CVSS 4.0: 9,0 (Critical). Vendor zaktualizował własny komunikat 27 sierpnia, dlatego operatorzy, którzy reagują na advisory producenta, mogli wdrożyć poprawkę wcześniej. Dzisiejsza publikacja ułatwia jednak automatyczne wykrycie luki w skanerach i procesach podatności.

To nie jest nieuwierzytelnione RCE z internetu. Atakujący potrzebuje pozycji klienta lub resellera i dostępu shell bądź możliwości jego włączenia. W środowisku hostingu współdzielonego taki warunek nie jest egzotyczny: dostęp powłokowy bywa elementem planu usługowego, narzędziem wdrożeniowym lub opcją, którą tenant może sam zmienić. Przekroczenie granicy z konta tenantowego do roota niszczy podstawowe założenie izolacji całego serwera.

Dlaczego lokalna luka jest krytyczna w panelu hostingowym

Panel taki jak Plesk zarządza wieloma domenami, procesami PHP, bazami, certyfikatami, DNS, pocztą i backupami. Klient otrzymuje kontrolowany fragment tej powierzchni. System operacyjny oraz mechanizmy panelu mają pilnować, aby jedna subskrypcja nie mogła zmieniać plików innej i aby reseller nie przejmował infrastruktury operatora.

Root jest poza tym modelem. Po eskalacji napastnik może czytać konfiguracje i sekrety wszystkich tenantów, modyfikować binaria i usługi, wyłączyć monitoring, przejąć backupy oraz ukryć trwałość poza katalogiem własnej domeny. Nawet jeżeli poszczególne aplikacje stosują kontenery lub osobne pule PHP, root na hoście może zwykle obserwować ich pliki, procesy i ruch.

Właśnie dlatego wymóg lokalnego konta nie czyni luki „małą”. W hostingu wielodostępnym klient jest częścią modelu zagrożeń, nie zaufanym administratorem. Skradzione konto SFTP/SSH, nadużycie konta testowego albo celowo wykupiona najtańsza usługa mogą zapewnić wymagany punkt startowy.

Co dokładnie potwierdzają źródła

NVD klasyfikuje problem jako lokalną eskalację przez OS command injection. Plesk podaje, że dotyczy on klienta lub resellera z dostępem shell albo uprawnieniem do zmiany własnego shell access. Producent nie publikuje w komunikacie szczegółowej sekwencji wykorzystania, co jest rozsądne przy luce prowadzącej do roota.

Operator nie powinien dopowiadać, że zagrożone jest tylko interaktywne SSH. W Plesk „shell access” jest ustawieniem hostingu, które może wpływać na sposób uruchamiania konta i dostępne mechanizmy. Należy sprawdzić zarówno aktywne sesje, jak i plany usługowe, wyjątki resellerów oraz możliwość samodzielnej zmiany ustawienia.

Producent stwierdza też jasno: jeśli shell jest wymagany, nie ma pełnej mitygacji zastępującej aktualizację. Gdy nie jest potrzebny, można go tymczasowo ustawić na Forbidden i odebrać klientowi lub resellerowi prawo do zmiany tej opcji. To bariera warunkowa, nie patch.

Inwentaryzacja: więcej niż numer w panelu

Ustal wersję na każdym zarządzanym hoście, również węzłach mniej widocznych: starym środowisku migracyjnym, serwerze testowym, maszynie awaryjnej i obrazie używanym do szybkiego odtworzenia. Klaster narzędzi zarządzających nie gwarantuje, że wszystkie hosty otrzymały ten sam microupdate.

Następnie wyeksportuj mapę:

klientów i resellerów z aktywnym shell access;
kont, które mogą zmienić własny rodzaj powłoki;
planów usługowych dziedziczących tę możliwość;
kont systemowych, UID, katalogów domowych i ostatnich logowań;
wyjątków utworzonych ręcznie poza standardowym planem;
integracji automatyzujących provisioning przez API.

Wersja poprawiona powinna być co najmniej 18.0.79.9 dla utrzymywanej gałęzi 18.0.79 albo 18.0.80.5 dla 18.0.80. Najlepszym celem jest najnowszy wspierany microupdate zaakceptowany przez operatora, ponieważ późniejsze wydanie może zawierać kolejne poprawki.

Plan aktualizacji bez utraty dowodów

Przed zmianą zachowaj podstawowy materiał dochodzeniowy: logi uwierzytelnienia, dzienniki Plesk, historię zmian usług, auditd/EDR, listę procesów, połączeń i kont oraz snapshot metadanych plików. Nie opóźniaj patcha na wiele dni w imię idealnej akwizycji, ale nie niszcz całego kontekstu przez automatyczne czyszczenie logów.

Wdrożenie powinno objąć kolejno:

odcięcie lub ograniczenie kont shell, które nie mają uzasadnionej potrzeby;
aktualizację Plesk do poprawionej lub nowszej wersji;
potwierdzenie wersji z hosta, nie wyłącznie centralnego dashboardu;
test logowania, hostingu, poczty, DNS, backupu i jobów po zmianie;
ponowne zestawienie listy kont, które nadal mają shell;
hunting za aktywnością sprzed aktualizacji.

W środowisku z wieloma serwerami wprowadź falami, lecz czas między falami powinien być krótki. Host pozostawiony na końcu jest nadal łatwym celem dla osoby mającej legalne konto tenantowe.

Mitygacja awaryjna

Jeśli aktualizacja nie może wejść natychmiast, Plesk zaleca ustawienie shell access na Forbidden dla subskrypcji i resellerów, którzy go nie wymagają, oraz zmianę service planu tak, aby nie mogli samodzielnie włączyć tej funkcji. Sprawdź efekty dziedziczenia: zmiana planu bez synchronizacji istniejącej subskrypcji może nie zmienić bieżącego stanu.

Nie zastępuj tej kontroli blokadą portu 22 na publicznym firewallu. Użytkownik może korzystać z innej ścieżki lokalnej, konsoli panelu, jobu albo mechanizmu dostarczonego przez hosting. Warunkiem CVE jest dostęp shell w modelu Plesk, a nie konkretny adres źródłowy SSH.

Nie wystarczy także odebranie powłoki jednemu podejrzanemu kontu. Trzeba objąć całą populację kont i prawo do zmiany ustawienia. Jeśli shell jest częścią usługi, vendor nie wskazuje pełnego workaroundu — priorytetem pozostaje microupdate.

Jak szukać śladów eskalacji

Szukaj sesji klientów i resellerów poprzedzających procesy uruchomione jako root, nieoczekiwanych zmian UID/GID, plików SUID, modyfikacji sudoers, unitów systemd, cronów roota, kluczy SSH oraz bibliotek ładowanych przez usługi. Skoreluj logi panelu z auth.log/journal, auditd i telemetryką EDR.

Ważne są także zmiany poza klasycznymi miejscami persistence: konfiguracje serwera WWW, wrappery PHP, zadania backupu, repozytoria pakietów i skrypty hooków Plesk. Napastnik z rootem może zmienić logi lokalne, dlatego porównuj z kopiami przesyłanymi zdalnie i danymi z hypervisora lub chmury.

Jeżeli istnieje wiarygodny łańcuch tenant → root, nie próbuj „wyczyścić” hosta w miejscu jako jedynej reakcji. Odtwórz go z zaufanego obrazu, przywróć zweryfikowane dane i obróć sekrety wszystkich tenantów, do których root miał dostęp. Zbadaj też backupy i obrazy utworzone po podejrzanym czasie.

Ograniczanie blast radius panelu

Patch usuwa konkretny błąd, lecz nie zmienia faktu, że panel hostingowy jest control plane’em o bardzo szerokich uprawnieniach. Oddzielaj klientów o wyższym ryzyku, ograniczaj liczbę tenantów na host, centralizuj logi poza serwerem i rozdzielaj sekrety backupu od poświadczeń panelu.

Konta klientów powinny używać MFA tam, gdzie to możliwe, a shell — osobnych kluczy, krótkiego cyklu życia i alertowania. Dostęp resellerów wymaga przeglądu podobnego do kont uprzywilejowanych. Rozważ osobne pule lub hosty dla usług wymagających powłoki, jeżeli reszta oferty może działać bez niej.

Bezpieczna walidacja poprawki

Nie odtwarzaj command injection na produkcji. Potwierdź wersję pliku i pakietów, status microupdate oraz zachowanie panelu po restarcie usług. Na izolowanym klonie można zweryfikować, że zwykły klient zachowuje potrzebne funkcje shell, lecz nie potrafi zmienić ustawień poza swoim zakresem. Test nie musi zdobywać roota, aby udowodnić poprawną wersję i egzekwowanie uprawnień.

Po aktualizacji monitoruj błędy procesu i skargi tenantów, ale nie wycofuj poprawki automatycznie przy pierwszej niezgodności. Najpierw ustal, czy problem wynika z cache, niezsynchronizowanego planu czy konkretnego rozszerzenia.

Fakty źródłowe i wnioski Breachroad

Zakres wersji, warunek shell access, brak wpływu na Windows, wersje naprawcze i mitygacja przez Forbidden pochodzą z advisory Plesk oraz NVD. Model zagrożeń hostingu wielodostępnego, plan huntingu i zalecenia odbudowy są wnioskami Breachroad. Źródła nie informują o potwierdzonej aktywnej eksploatacji CVE-2026-67394.

Źródła pierwotne

Eskalacja tenanta do roota jest testem całego modelu wielodostępności, nie tylko jednego polecenia. Na szkoleniach z cyberbezpieczeństwa uczymy zespoły łączyć podatność z tożsamością, konfiguracją i blast radius. Niezależny audyt bezpieczeństwa IT może sprawdzić control plane, konta, logowanie i procedurę odbudowy hostingu.