WordPress opublikował pilną aktualizację bezpieczeństwa 7.1.2 po wykryciu luki CVE-2026-87902, która w określonych warunkach może pozwolić niezalogowanemu napastnikowi na wykonanie kodu na serwerze. Problem nie jest już wyłącznie teoretyczny — 24 września pojawiły się raporty o aktywnych próbach wykorzystania podatności.
To nie oznacza, że każdy serwis WordPress jest automatycznie przejmowany. Exploit wymaga spełnienia dodatkowych warunków po stronie motywu i serwera. Mimo to właściciele stron nie powinni odkładać aktualizacji, bo publicznie dostępny opis podatności szybko zwiększa liczbę prób skanowania i ataków.
Z tego artykułu dowiesz się:
- czym jest CVE-2026-87902,
- dlaczego luka może prowadzić do wykonania kodu na serwerze,
- kiedy WordPress jest szczególnie narażony,
- jak sprawdzić, czy masz poprawioną wersję,
- co zrobić, jeśli podejrzewasz, że strona została zaatakowana.
CVE-2026-87902 – na czym polega luka w WordPressie?
Podatność dotyczy mechanizmu rozwiązywania szablonów stron w WordPressie. W uproszczeniu: atakujący może spróbować wpłynąć na ścieżkę pliku PHP, który WordPress próbuje wczytać jako szablon strony. Jeżeli konfiguracja witryny i serwera spełnia określone warunki, możliwe staje się odwołanie do lokalnego pliku PHP znajdującego się poza katalogiem aktywnego motywu.
Sam dostęp do lokalnego pliku nie zawsze oznacza wykonanie kodu. W najbardziej niebezpiecznym scenariuszu napastnik może jednak doprowadzić do sytuacji, w której WordPress wczyta plik pozwalający zapisać na serwerze kolejne dane PHP, a następnie je uruchomić. To właśnie dlatego luka została potraktowana jako krytyczna.
Najważniejszy szczegół: atak nie wymaga logowania do panelu WordPressa. Jeżeli wszystkie warunki techniczne są spełnione, żądanie może zostać wysłane anonimowo.
Czy każdy WordPress jest podatny?
Nie. Według informacji WordPressa i analiz bezpieczeństwa wykorzystanie CVE-2026-87902 zależy od konfiguracji. Szczególnie istotne jest to, czy aktywny motyw lub motyw nadrzędny zawiera odpowiedni katalog związany z szablonami stron oraz czy na serwerze znajduje się lokalny plik PHP, który może zostać użyty przez atakującego.
To zmniejsza liczbę instalacji, na których exploit zakończy się sukcesem, ale nie jest dobrym powodem do pozostawienia starej wersji WordPressa. Automatyczne skanery nie muszą wiedzieć z góry, czy konkretna strona spełnia wszystkie warunki. Mogą po prostu testować tysiące witryn i sprawdzać, gdzie atak się powiedzie.
Luka jest już aktywnie wykorzystywana
24 września 2026 roku The Hacker News poinformował o obserwowanych próbach wykorzystania CVE-2026-87902. Według danych firm zajmujących się bezpieczeństwem atakujący testowali między innymi możliwość wczytania lokalnych plików PHP i zapisu kolejnych plików na serwerze.
To ważna zmiana sytuacji. Gdy pojawia się działający proof of concept, skanowanie internetu zwykle szybko przyspiesza. Atakujący nie muszą samodzielnie odkrywać technicznych szczegółów podatności — mogą zaadaptować publicznie dostępne informacje i automatyzować próby wykorzystania luki.
Która wersja WordPressa naprawia problem?
Dla aktualnej gałęzi WordPress poprawka została wydana w wersji 7.1.2. WordPress.org zaleca natychmiastową aktualizację. Poprawka została również przygotowana dla starszych wspieranych gałęzi, między innymi 7.0, 6.9, 6.8, 6.7 i 6.6.
Najprościej wejść do:
Kokpit → Aktualizacje
i sprawdzić, czy WordPress informuje o dostępnej aktualizacji bezpieczeństwa. Jeżeli aktualizacje automatyczne działają poprawnie, instalacja mogła już zostać zaktualizowana w tle. Mimo to warto ręcznie potwierdzić numer wersji.
Nie ograniczaj kontroli wyłącznie do głównego WordPressa. Przy okazji sprawdź aktualizacje motywu, motywu potomnego oraz wtyczek. CVE-2026-87902 dotyczy WordPress Core, ale przejęta strona często ma więcej niż jeden słaby punkt.
Czy wystarczy włączyć automatyczne aktualizacje?
Automatyczne aktualizacje znacząco skracają czas, przez jaki strona pozostaje podatna, ale nie zastępują kontroli. Warto sprawdzić, czy aktualizacja rzeczywiście się wykonała i czy witryna działa poprawnie po instalacji nowej wersji.
W przypadku serwisów firmowych dobrym rozwiązaniem jest również regularna kopia zapasowa oraz okresowe testowanie jej odtwarzania. Sama informacja „backup wykonany” nie daje pewności, że pliki i baza danych dają się poprawnie przywrócić. Opisujemy to szerzej w poradniku Czy kopia zapasowa naprawdę zadziała? Jak przetestować odtwarzanie danych w małej firmie.
Jak rozpoznać, że WordPress mógł zostać zaatakowany?
Po pojawieniu się aktywnych exploitów warto zwrócić uwagę przede wszystkim na zmiany, których nikt z administratorów nie wykonywał. Nie każdy symptom oznacza włamanie, ale kilka sygnałów jednocześnie powinno uruchomić dokładniejszą kontrolę.
- nieznane pliki PHP w katalogach strony lub katalogach tymczasowych,
- nowe konta administratorów, których nikt nie tworzył,
- zmiany plików motywu albo WordPress Core bez aktualizacji,
- nieznane zadania cron i nietypowe procesy,
- przekierowania na obce domeny,
- ostrzeżenia hostingu o złośliwych plikach,
- nagły wzrost ruchu do nietypowych adresów URL,
- zmiana haseł lub adresów e-mail kont administratorów.
Jeżeli masz dostęp do logów serwera, sprawdź nietypowe żądania pojawiające się w czasie, gdy strona była jeszcze na podatnej wersji. Szczególnie przydatne są logi HTTP, logi PHP oraz historia zmian plików dostępna w niektórych panelach hostingowych i systemach bezpieczeństwa.
Co zrobić, jeśli podejrzewasz przejęcie strony?
Aktualizacja WordPressa zamyka lukę, ale nie usuwa automatycznie skutków wcześniejszego włamania. Jeżeli napastnik zdążył umieścić backdoora albo utworzyć nowe konto administratora, samo wgranie poprawionej wersji nie wystarczy.
- Zrób kopię obecnego stanu strony i logów, zanim zaczniesz usuwać pliki.
- Zaktualizuj WordPress Core do wersji zawierającej poprawkę.
- Zaktualizuj wtyczki i motywy.
- Sprawdź integralność plików WordPressa.
- Przejrzyj konta administratorów.
- Usuń nieznane pliki i zmiany dopiero po ustaleniu, do czego służą.
- Zmień hasła do WordPressa, hostingu, FTP/SFTP, bazy danych i innych kont administracyjnych.
- Unieważnij aktywne sesje i klucze dostępu, jeżeli istnieje ryzyko ich przejęcia.
Jeżeli hasło administratora lub innego ważnego konta mogło wyciec, sama jego zmiana może być niewystarczająca. Sprawdź również aktywne sesje i metody odzyskiwania. Pełną procedurę opisujemy w poradniku Ktoś poznał moje hasło – co zrobić?.
Czy trzeba panikować?
Nie. CVE-2026-87902 jest poważną podatnością, ale skuteczny atak wymaga spełnienia dodatkowych warunków. Najgorszą reakcją byłoby jednak całkowite zignorowanie aktualizacji tylko dlatego, że nie każdy serwer jest podatny w ten sam sposób.
W praktyce właściciel typowej strony powinien wykonać trzy rzeczy: sprawdzić wersję WordPressa, zainstalować poprawkę bezpieczeństwa i skontrolować, czy w czasie działania podatnej wersji nie pojawiły się nieznane zmiany. To znacznie rozsądniejsze niż próba samodzielnego oceniania, czy konkretny serwer spełnia wszystkie techniczne warunki exploita.
