Krótko: co się stało 

W rdzeniu WordPressa znaleziono lukę stored XSS (CVE-2026-93485), którą może wykorzystać osoba niezalogowana. Wystarczy odpowiednio spreparowany komentarz. Jeśli stronę z takim komentarzem otworzy zalogowany administrator, kod w jego przeglądarce może zainstalować na serwerze złośliwą wtyczkę, co oznacza zdalne wykonanie kodu (RCE). 

Lukę zgłosił badacz Rafie Muhammad przez program bug bounty WordPressa. Poprawkę wydano 17 września 2026 w wersji 7.1.1, a szczegóły opublikowano 21 września. 

Kogo dotyczy problem 

Strony na motywach blokowych, które renderują komentarze przez szablony blokowe.  

Niektóre motywy klasyczne, które wywołują wptexturize() na treści, np. Twenty Twenty-One.  

Każda instalacja poniżej wersji z poprawką dla swojej gałęzi. Łatkę przeniesiono do wszystkich wspieranych gałęzi do 4.7.36 włącznie, więc "mam 6.x" nie znaczy "jestem bezpieczny". Trzeba sprawdzić numer wydania z poprawką dla swojej linii.  

Dlaczego do błędu doszło 

WordPress oczyszcza komentarz przy zapisie (mechanizm KSES), a formatuje go dopiero przy wyświetlaniu (filtry comment_text). Podatność leży między tymi etapami. Dozwolony przez KSES znak nowej linii w atrybucie cite elementu blockquote sprawia, że kolejne filtry formatujące (wpautop(), a potem wptexturize()) przerabiają niegroźny kod na taki, w którym tekst z komentarza staje się atrybutem HTML z obsługą zdarzenia. Źródłem błędu była zbyt prosta reguła wyrażenia regularnego w wpautop(). Poprawka to zmiana jednej linii, która uwzględnia cudzysłowy w atrybutach. 

Dlatego sama sanityzacja przy zapisie nie wystarczyła. To dobry przykład klasy błędów, w których każdy filtr z osobna jest poprawny, a razem tworzą lukę. 

Czy moderacja komentarzy mnie chroni? 

Nie zawsze. Domyślnie WordPress nie wstrzymuje każdego komentarza, a dla nowych autorów działa osobne ustawienie "autor komentarza musi mieć wcześniej zatwierdzony komentarz". Badacz opisał co najmniej trzy sposoby obejścia moderacji: 

1. Domyślny komentator. Instalator tworzy zatwierdzony komentarz od "A WordPress Commenter". Komentarz wysłany pod tą samą nazwą i adresem e-mail jest zatwierdzany automatycznie.  

2. Wyłączone ustawienie wymagania wcześniej zatwierdzonego komentarza w Ustawieniach → Dyskusja.  

3. Komentarz oczekujący na zatwierdzenie nadal wyświetla się osobie, która ma cookie komentatora, czyli samemu autorowi ataku, przez link podglądu. To ścieżka mniej groźna, ale pokazuje, że moderacja nie jest barierą bezpieczeństwa.  

Co zrobić teraz 

1. Zaktualizuj WordPressa do 7.1.1 lub najnowszego wydania w swojej gałęzi.  

2. Włącz automatyczne aktualizacje rdzenia, a najlepiej też wtyczek.  

3. Do czasu aktualizacji nie przeglądaj frontu strony jako zalogowany administrator, zwłaszcza podstron z komentarzami. Użyj osobnej przeglądarki lub profilu.  

4. Jeśli nie możesz od razu zaktualizować, tymczasowo wyłącz komentarze i wstrzymaj nowe.  

5. Rozważ w wp-config.php stałą DISALLOW_FILE_MODS (blokuje instalację wtyczek z panelu, czyli ostatni krok opisanego łańcucha). Uwaga: zablokuje też aktualizacje z panelu, więc wymaga innego procesu wdrażania zmian.  

6. Dodatkowe warstwy: WAF z regułami na XSS, restrykcyjny nagłówek Content-Security-Policy na froncie, 2FA dla administratorów oraz zasada najmniejszych uprawnień (administratorzy tylko tam, gdzie trzeba).  

Jak sprawdzić, czy ktoś już to wykorzystał 

Przejrzyj listę wtyczek w katalogu wp-content/plugins pod kątem nieznanych folderów, także nieaktywnych. Atak nie wymaga aktywacji wtyczki, bo sam plik na dysku wystarcza.  

Sprawdź logi serwera pod kątem żądań do update.php?action=upload-plugin oraz późniejszych wywołań nieznanych plików w wp-content/plugins/.  

Przeszukaj bazę komentarzy pod kątem elementów blockquote z atrybutem cite zawierającym znak nowej linii oraz fragmentów typu onfocus, autofocus.  

Sprawdź daty modyfikacji plików i nowe konta administratorów.  

Co zrobić, jeśli podejrzewasz włamanie 

Ustaw stronę w tryb serwisowy, zrób kopię dowodową (pliki i logi), usuń nieznane wtyczki, zresetuj hasła i unieważnij sesje wszystkich administratorów, zmień klucze i sole w wp-config.php, sprawdź uprawnienia użytkowników i zadania cron, a następnie przywróć czystą kopię sprzed incydentu. Atakujący mógł wykonać na serwerze dowolne polecenia, więc same usunięcie jednego pliku zwykle nie wystarcza. W takiej sytuacji pomoc jaką oferuje etyczny haker do wynajęcia, może okazać sie w tej sytuacji jedynym skutecznym rozwiązaniem. 

Oś czasu 

8.09.2026 – zgłoszenie do zespołu bezpieczeństwa WordPressa (HackerOne)  

15.09 – wniosek o CVE  

17.09 – WordPress 7.1.1 i backporty do gałęzi 4.7.36  

18.09 – przydzielono CVE-2026-93485  

21.09 – publikacja badania  

FAQ 

Czy to jest atak "zero-click"? Atakujący nie potrzebuje konta, a administrator nie musi niczego klikać. Wystarczy otwarcie strony z komentarzem, ale tylko w opisanych konfiguracjach motywu. 

Czy wtyczki do komentarzy (np. Akismet) mnie chronią? Mogą utrudnić dodanie komentarza, ale nie naprawiają błędu w rdzeniu. Wyłącznie aktualizacja usuwa przyczynę. 

Dlaczego badanie zmieniło nazwę z Comment2Shell na Comment2XSS? Na prośbę opiekuna WordPressa, żeby uniknąć nieporozumień. Samo XSS jest potwierdzone, a RCE wymaga sesji administratora. 

Źródła: badanie IDNSEC (Rafie Muhammad), komunikat WordPress 7.1.1, rekord CVE-2026-93485.