WordPress 7.1.2: atak ruszył kilka godzin po wydaniu poprawki

Wrzesień był dla właścicieli stron na WordPressie wyjątkowo nerwowy. 17 września ukazała się wersja 7.1.1, która załatała dwie podatności znane jako Click2Shell i Comment2Shell (CVE-2026-93485). Pięć dni później, 22 września, wyszła wersja 7.1.2 z poprawką kolejnej krytycznej luki, oznaczonej jako CVE-2026-87902. I właśnie ta druga historia jest najbardziej pouczająca: według badaczy pierwsze próby ataku pojawiły się zaledwie kilka godzin po publikacji poprawki.

Nikt nie musiał ujawniać szczegółów technicznych. Wszystko wskazuje na to, że atakujący porównali kod przed i po aktualizacji, zobaczyli, co zostało poprawione, i na tej podstawie odtworzyli podatny mechanizm. Ten artykuł nie jest o tym, jak działa sama luka w komentarzach, tylko o tym, co oznacza dla Ciebie tak krótki czas między poprawką a atakiem.

Co naprawiła wersja 7.1.2

CVE-2026-87902 to luka typu path traversal, czyli taka, która pozwala „wyjść” poza katalog, z którego aplikacja powinna czytać pliki. Dotyczy mechanizmu wybierającego plik szablonu podczas wyświetlania strony. Odpowiednio przygotowane żądanie mogło sprawić, że WordPress wczyta plik PHP spoza katalogu aktywnego motywu.

Najważniejsze cechy tej podatności:

• Nie wymagała logowania ani żadnego działania ze strony użytkownika.
• W skali CVSS otrzymała ocenę 9,2, czyli poziom krytyczny.
• W niektórych konfiguracjach mogła prowadzić do zdalnego wykonania kodu na serwerze.

Wykorzystanie luki zależało od konfiguracji WordPressa i serwera. Aktywny motyw musiał zawierać katalog o nazwie zaczynającej się od page-, na przykład page-templates. Taką strukturę mają między innymi motywy Twenty Twelve, Twenty Fourteen, Neve, Hestia i Sydney. Jednym z plików wczytywanych przez atakujących był pearcmd.php, narzędzie dołączane do części instalacji PHP. W niektórych przypadkach dawało się go użyć do tworzenia nowych plików PHP na serwerze.

Jak wyglądały ataki

Obserwowany schemat był dwuetapowy. Najpierw atakujący sprawdzali, czy strona w ogóle daje się zmusić do wczytania pliku spoza katalogu motywu. Jeśli tak, przechodzili do prób utworzenia złośliwych plików. To typowe, zautomatyzowane skanowanie: boty przechodzą po tysiącach adresów i szukają tych, które odpowiadają w oczekiwany sposób.

Dla właściciela małej firmowej strony to ważna informacja. Nie musisz być ciekawym celem, żeby zostać zaatakowanym. Wystarczy, że Twoja instalacja pasuje do wzorca, a ktoś akurat przegląda internet w poszukiwaniu takich instalacji.

Dlaczego poprawka zdradza lukę

Kod WordPressa jest otwarty. Każda aktualizacja bezpieczeństwa to publicznie dostępna zmiana w kodzie, którą można porównać z poprzednią wersją. Dla obrońców to zaleta, bo każdy może sprawdzić, co zostało naprawione. Dla atakujących to podpowiedź, gdzie szukać.

W praktyce oznacza to, że moment wydania poprawki uruchamia wyścig. Z jednej strony są właściciele stron, którzy aktualizują się „jak znajdą chwilę”. Z drugiej strony są osoby, które w tym czasie analizują zmiany i przygotowują automatyczne narzędzia. W tym przypadku na pierwsze próby wystarczyło kilka godzin.

Co może stracić strona na WordPressie

Zdalne wykonanie kodu to nie tylko podmieniona strona główna. Atakujący, który uruchamia kod na serwerze, może przejąć kontrolę nad samym WordPressem, a potencjalnie także nad innymi zasobami serwera, jeśli nie były od strony dobrze odizolowane. Na współdzielonym hostingu z kilkoma witrynami w jednym katalogu ryzyko rośnie.

Do tego dochodzą funkcje, które dokładają wtyczki: konta klientów, płatności, formularze kontaktowe, zapisy na newsletter. Każda z nich oznacza dane osobowe, a wraz z nimi obowiązki wynikające z RODO, gdyby doszło do ich wycieku.

Plan na następną krytyczną poprawkę

Nie da się przewidzieć, kiedy pojawi się kolejna luka. Da się natomiast przygotować tak, żeby kolejna poprawka trafiła na Twoją stronę możliwie szybko.

1. Włącz automatyczne aktualizacje WordPressa. W tym przypadku to jedno ustawienie zamknęłoby lukę bez Twojego udziału. Rozważ to samo dla wtyczek, z których korzystasz.
2. Sprawdź, na jakiej wersji jesteś teraz. W panelu, w sekcji aktualizacji, zobaczysz numer wersji. Jeśli jest niższy niż 7.1.2, zaktualizuj od razu.
3. Ustal, kto odpowiada za aktualizacje. Jeśli stronę zrobiła agencja albo freelancer, zapytaj wprost, czy w umowie jest opieka techniczna i jak szybko wdrażane są poprawki krytyczne.
4. Usuń to, czego nie używasz. Nieaktywne wtyczki i motywy to dodatkowy kod na serwerze, który i tak może zawierać luki.
5. Miej aktualną kopię zapasową trzymaną poza serwerem strony. Gdy coś pójdzie źle, szybciej przywrócisz działającą wersję.
6. Zapytaj hosting o izolację witryn i o to, czy na serwerze są zbędne narzędzia PHP, takie jak pearcmd.php.

Aktualizacja to też porządek w dodatkach

Jak podsumował Sekurak, rada jest taka sama jak przy wszystkich wcześniejszych lukach w WordPressie: aktualizować oprogramowanie. To brzmi banalnie, ale tutaj kluczowe okazało się tempo. Tygodniowa zwłoka, która kiedyś była normą, dziś oznacza tydzień otwartych drzwi.

Przy okazji przeglądu wtyczek warto sprawdzić także te, które ładują zewnętrzne skrypty: analitykę, piksele reklamowe, czaty. Każdy taki dodatek to element, o którym musisz pamiętać przy aktualizacjach, a często również przy zgodach użytkowników. Mniej przypadkowych dodatków to mniejsza powierzchnia ataku i prostszy porządek na stronie.

Źródło: Sekurak

WordPressaktualizacjepodatnośćbezpieczeństwo stron