Od komentarza do przejęcia serwera: jak działała luka XSS w WordPressie

Komentarze pod wpisami wydają się najmniej groźną częścią strony. Ktoś zostawia kilka zdań, Ty je zatwierdzasz albo usuwasz. Luka odkryta przez badacza Rafiego Muhammada pokazuje, że nawet tak prosty element może stać się drogą do przejęcia całego serwera. Podatność otrzymała numer CVE-2026-93485 i została załatana w WordPressie 7.1.1.

W skrócie: nieuwierzytelniony użytkownik mógł dodać komentarz, który po wyświetleniu zawierał aktywny kod JavaScript. Gdy stronę z takim komentarzem otworzył zalogowany administrator, skrypt mógł w jego imieniu wgrać na serwer złośliwą wtyczkę. Poniżej wyjaśniamy, jak do tego dochodziło, bez wchodzenia w szczegóły, które przydałyby się tylko atakującym.

Dwa etapy: czyszczenie i formatowanie

WordPress pozwala na kilka znaczników HTML w komentarzach. Lista jest krótka: linki, skróty, cytaty blockquote i q z atrybutem cite, przekreślenia i fragmenty kodu. Wszystko inne usuwa mechanizm o nazwie KSES w chwili zapisywania komentarza.

Problem nie leżał w samym KSES, tylko w tym, co dzieje się później. Podczas wyświetlania komentarz przechodzi przez łańcuch filtrów formatujących, między innymi wpautop(), który zamienia znaki nowej linii na akapity, oraz wptexturize(), który poprawia typografię. Każdy z tych filtrów przepisuje HTML. Luka powstała dokładnie na styku tych dwóch etapów: komentarz bezpieczny po czyszczeniu stawał się niebezpieczny po formatowaniu.

Jak niewinny cytat zamieniał się w skrypt

Mechanizm był łańcuchem kilku drobnych zachowań, z których żadne osobno nie wyglądało groźnie:

1. KSES przepuszczał znak nowej linii wewnątrz atrybutu cite w elemencie blockquote, bo nie był on na liście znaków kodowanych na nowo.
2. Funkcja wpautop() zastępowała każdą nową linię wewnątrz znacznika tymczasowym komentarzem HTML, który zawiera znak „>”.
3. Następnie wyrażenie regularne, które miało przestawić akapit i cytat, zatrzymywało się na pierwszym napotkanym „>”. W efekcie znacznik akapitu lądował w środku wartości atrybutu.
4. W motywach blokowych z blokiem Latest Comments dochodziła funkcja wptexturize(), która uznawała ten wstawiony akapit za granicę znacznika i inaczej traktowała cudzysłowy przed nim i w elemencie code.

Suma tych przekształceń pozwalała przesunąć tekst kontrolowany przez atakującego z treści komentarza do pozycji atrybutu HTML. A atrybutem może być obsługa zdarzenia, czyli kod JavaScript uruchamiany przez przeglądarkę. Dzięki atrybutom autofocus i onfocus skrypt mógł wystartować sam, bez żadnego kliknięcia. W niektórych konfiguracjach wystarczało otworzyć stronę z komentarzem.

Od XSS do RCE, czyli dlaczego administrator jest celem

XSS, czyli wstrzyknięcie skryptu, działa w przeglądarce osoby, która ogląda stronę, i w ramach jej sesji. Jeśli tą osobą jest zwykły czytelnik, szkody są ograniczone. Jeśli to zalogowany administrator, skrypt ma te same uprawnienia co on.

Badacz pokazał, że taki skrypt może po cichu otworzyć w tle formularz instalacji wtyczek, odczytać z niego token zabezpieczający przed atakami CSRF i wysłać na serwer archiwum ZIP z wtyczką zawierającą prostą powłokę PHP. Nie potrzeba do tego edytora plików ani FTP. Wtyczki nie trzeba nawet aktywować: plik leży już na dysku, więc atakujący może go wywołać zwykłym adresem i wykonywać na serwerze dowolne polecenia. To właśnie przejście od XSS do RCE, czyli zdalnego wykonania kodu.

Moderacja pomaga, ale nie wystarcza

Zwykle komentarz musi zostać zatwierdzony, zanim zobaczą go inni. To ogranicza ryzyko, ale go nie usuwa. Część stron publikuje komentarze bez moderacji, a na innych jednorazowe zatwierdzenie autora pozwala mu potem dodawać kolejne wpisy bez czekania. Poza tym administrator zwykle ogląda komentarze właśnie po to, żeby je zatwierdzić.

Jak zabezpieczyć komentarze i panel

Podstawą jest aktualizacja do WordPressa 7.1.1 lub nowszego. Warto też włączyć automatyczne aktualizacje WordPressa i używanych wtyczek. Poza tym kilka zasad zmniejsza skutki podobnych luk w przyszłości:

• Wyłącz komentarze tam, gdzie nikt ich nie używa. Firmowa strona usługowa często w ogóle ich nie potrzebuje, a i tak ma je włączone, bo tak ustawił motyw.
• Wymagaj ręcznego zatwierdzania każdego komentarza, a nie tylko pierwszego od danego autora.
• Oddziel konto administratora od codziennej pracy. Do pisania wpisów i moderacji wystarczy konto o niższej roli, na przykład redaktora, które nie może instalować wtyczek.
• Zablokuj instalację wtyczek z panelu, jeśli zmiany na stronie i tak wprowadza agencja. W WordPressie służy do tego stała DISALLOW_FILE_MODS w pliku konfiguracyjnym, przy czym blokuje ona także aktualizacje z panelu, więc trzeba wtedy zadbać o nie inną drogą.
• Wylogowuj się z panelu, gdy przeglądasz stronę jak zwykły użytkownik.
• Przejrzyj listę wtyczek i sprawdź, czy nie pojawiła się tam pozycja, której nikt nie instalował.

Co z tego wynika dla właściciela strony

Ta luka dobrze pokazuje, że bezpieczeństwo strony to nie tylko silne hasło. Liczą się też role użytkowników, wyłączone niepotrzebne funkcje i tempo aktualizacji. Jak opisał Sekurak, kluczowe zalecenie jest proste: zaktualizować się pilnie i rozważyć automatyczne aktualizacje.

Jeśli na stronie są komentarze, formularze albo konta klientów, przetwarzasz dane osobowe. Przejęcie serwera oznacza wtedy także ryzyko ich wycieku, a w konsekwencji obowiązki wynikające z RODO. Kwadrans poświęcony dziś na przegląd ustawień komentarzy i ról to znacznie mniej niż koszt sprzątania po włamaniu.

Źródło: Sekurak

WordPressXSSkomentarzebezpieczeństwo stron