Krytyczne luki w rdzeniu WordPressa: co naprawiono i jak chronić stronę

22 września 2026 r. WordPress wydał wersję 7.1.2, która łata krytyczną lukę w rdzeniu (CVE-2026-87902): w określonych warunkach niezalogowany atakujący mógł wykonać kod na serwerze. Pierwsze próby ataku odnotowano jeszcze tego samego dnia. Najlepszą ochroną jest szybka aktualizacja rdzenia, najlepiej automatyczna, a do tego kilka warstw, które ograniczą skutki, gdy aktualizacja się spóźni.

Poniżej wyjaśniamy, co dokładnie naprawiono w ostatnich wydaniach, dlaczego luka w samym WordPressie jest groźniejsza niż luka w pojedynczej wtyczce i co możesz zrobić, żeby Twoja strona lub sklep nie stały się łatwym celem.

Co naprawił WordPress 7.1.2

Według oficjalnego ogłoszenia wydania i komunikatu bezpieczeństwa GHSA-7hp8-65ch-5whp luka CVE-2026-87902 to path traversal, czyli wyjście poza dozwolony katalog, prowadzące do local file inclusion, czyli dołączenia i uruchomienia lokalnego pliku PHP. W klasyfikacji CWE to CWE-98: niewłaściwa kontrola nazwy pliku w instrukcji dołączającej kod PHP. Podatne są wszystkie wersje od 4.7.0 do 7.1.1, czyli blisko dziesięć lat wydań.

Gdzie leżał błąd

Gdy ktoś otwiera podstronę typu „Strona”, WordPress wybiera plik motywu według tzw. hierarchii szablonów. Najpierw sprawdza szablon przypisany stronie w edytorze, potem plik nazwany od adresu strony (page-{adres}.php), a na końcu ogólny page.php. Robi to funkcja get_page_template(). Adres strony pochodzi z żądania HTTP (parametr pagename), więc może na niego wpływać każdy odwiedzający, bez logowania.

Według analizy Patchstack nazwa szablonu przypisanego w edytorze była sprawdzana wbudowaną funkcją validate_file(), która odrzuca próby wyjścia z katalogu. Nazwa budowana z adresu strony, po zdekodowaniu, tej kontroli nie przechodziła, a mechanizm wyszukiwania szablonu doklejał ją do ścieżki motywu bez sprawdzenia, czy wynik nadal leży w motywie.

Poprawka robi dwie rzeczy. Stosuje validate_file() także do nazwy zbudowanej z adresu strony. Dodatkowo każdy znaleziony szablon musi leżeć wewnątrz katalogów motywu (nowa wewnętrzna funkcja _wp_is_template_path_allowed()). Ta druga zmiana ma efekt uboczny: rozwiązania, które celowo trzymają widoki poza katalogiem motywu, mogą przestać działać. Społeczność Roots opisała taki problem w części projektów opartych na Bedrocku z biblioteką Acorn i w Radicle; rozwiązaniem jest aktualizacja Acorn do wersji 6.3.0 lub nowszej. To dobry przykład, dlaczego nawet pilną poprawkę trzeba szybko przetestować.

Kiedy atak się udaje: warunki do sprawdzenia

Komunikat bezpieczeństwa wymienia dwa warunki:

1. Budowa motywu. Aktywny motyw albo jego motyw nadrzędny (przy motywie potomnym) ma w swoim głównym katalogu folder, którego nazwa zaczyna się od page-, np. page-templates. Komunikat wymienia starsze motywy domyślne Twenty Twelve i Twenty Fourteen oraz popularne motywy Neve, Hestia i Sydney, ale takich motywów jest więcej. Sprawdzisz to, przeglądając katalog motywu w wp-content/themes/ przez FTP lub menedżer plików w panelu hostingu.
2. Plik PHP, który da się nadużyć, i ustawienie PHP. Na serwerze musi istnieć czytelny plik PHP, którego dołączenie daje atakującemu dalsze możliwości. Komunikat wskazuje znany mechanizm z pakietu PEAR, który prowadzi do wykonania kodu, gdy w PHP włączone jest ustawienie register_argc_argv. Według komunikatu dotyczy to oficjalnego obrazu PHP dla Dockera i domyślnej konfiguracji cPanel przy PHP starszym niż 8.5. Wartość tego ustawienia sprawdzisz w informacjach o PHP w panelu hostingu albo zapytasz o nią hosting.

Co, jeśli warunki nie są spełnione? Patchstack opisuje lukę jako łańcuch warunkowy: przy motywie z folderem page- niezalogowany atakujący może wymusić dołączenie innego pliku PHP z serwera, a wykonanie własnego kodu zależy od konfiguracji serwera. Skutki samego dołączenia zależą od tego, jakie pliki PHP leżą na serwerze. Bez folderu page- w motywie praktyczny warunek ataku według Patchstack nie jest spełniony. Aktualizuj mimo to: motyw może się zmienić, a konfigurację serwera trudno ocenić bez dostępu do niego.

Ani ogłoszenie, ani komunikat nie wyróżniają instalacji wielostanowiskowych (multisite). Bezpieczniej założyć, że narażona jest każda witryna w sieci, której aktywny motyw spełnia warunek. Patchstack wdrożył regułę ochronną dla swoich klientów 22 września. Nie znaleźliśmy natomiast wiarygodnego potwierdzenia, czy standardowe zapory hostingów blokują ten konkretny atak.

Ocena: 9,2 na 10 w skali CVSS 4.0

Pełny wektor oceny to CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. W praktyce oznacza to:

• AV:N: atak przez sieć, wystarczy wysłać żądanie do strony,
• AC:L: niska złożoność ataku,
• AT:P: po stronie celu muszą być spełnione warunki wstępne (motyw i konfiguracja serwera opisane wyżej),
• PR:N i UI:N: atakujący nie potrzebuje konta ani udziału nikogo z Twojego zespołu,
• VC:H, VI:H, VA:H: wysoki wpływ na poufność, integralność i dostępność samej strony,
• SC:N, SI:N, SA:N: ocena nie zakłada wpływu na inne systemy.

Oś czasu

• Zgłoszenie: lukę zgłosił Robert Ressl. Data zgłoszenia nie została podana.
• 22.09.2026: wydanie 7.1.2 wraz z poprawkami dla 24 starszych gałęzi, publikacja komunikatu i numeru CVE.
• 22.09, 11:49 UTC: według Patchstack pierwsze próby rozpoznania, czy strona jest podatna.
• 22.09, 15:34 UTC: pierwsze próby zapisania plików na serwerze.
• 23.09: w obiegu publiczne narzędzia do masowego skanowania, m.in. szablon dla popularnego skanera Nuclei, i szczyt ruchu atakującego. Na GitHubie pojawiły się też publiczne repozytoria z kodem demonstracyjnym (PoC).

Jak sprawdzić, czy ktoś próbował i czy masz poprawkę

W logach serwera WWW z okresu od 22 września szukaj przede wszystkim:

• żądań, w których parametr pagename zawiera sekwencje przejścia do katalogu nadrzędnego, zwykle zakodowane w adresie, czasem podwójnie,
• żądań do strony głównej lub index.php, które łączą kilka parametrów wyboru strony naraz,
• odwołań do narzędzi PEAR w adresach,
• nazw klienta (user agent), które wprost zawierają numer CVE, co jest typowe dla skanerów,
• nieoczekiwanych plików PHP w katalogach tymczasowych serwera (/tmp, /var/tmp).

Wpis w logach oznacza próbę, a nie włamanie. Jeśli jednak strona była w tym czasie bez poprawki, a motyw i serwer spełniały warunki, przejdź plan reakcji opisany niżej.

Wersję WordPressa zobaczysz w Kokpicie, w sekcji Aktualizacje, albo poleceniem wp core version. Wersje z poprawką według komunikatu to: 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32 i 4.7.37. Jeśli Twoja wersja jest niższa niż numer z poprawką w Twojej gałęzi, strona jest podatna. Strony z działającymi automatycznymi aktualizacjami drobnych wydań powinny dostać poprawkę same. Pozostałe trzeba zaktualizować ręcznie, i to od razu.

Nie tylko 7.1.2: wydania bezpieczeństwa rdzenia w ostatnim roku

Luka z września nie była wyjątkiem. Od jesieni 2025 r. WordPress wydał kilka wydań bezpieczeństwa rdzenia, część z poprawkami oznaczonymi jako krytyczne.

Wydanie	Data	Co naprawiło	Kogo dotyczyło
6.8.3	30.09.2025	2 poprawki: dostęp do części treści zastrzeżonych, XSS w menu nawigacji	Zalogowani użytkownicy
6.9.2, 6.9.3, 6.9.4	10 i 11.03.2026	10 poprawek, m.in. SSRF, XSS, obejście autoryzacji, XXE. Wersja 6.9.3 naprawiała błąd w części motywów spowodowany przez 6.9.2, a 6.9.4 dokończyła niepełne poprawki	Różne poziomy uprawnień
7.0.2	17.07.2026	Krytyczna luka typu SQL injection i poważna luka w REST API prowadząca do wykonania kodu	Wersje 6.8 i nowsze
7.0.3	6.08.2026	Kilkanaście poprawek, m.in. XSS na ekranie logowania bez logowania, SSRF, eskalacja uprawnień w multisite	Od niezalogowanych gości po autorów
7.0.4	12.08.2026	Wykonanie kodu przez złośliwy plik wgrany na stronę	Konta z rolą Autor lub wyższą, serwery z Imagick i Ghostscript
7.1.1	17.09.2026	11 poprawek, m.in. XSS przez komentarze, nadpisywanie cudzych wpisów, obejście uprawnień przez XML-RPC	Od niezalogowanych gości po współpracowników
7.1.2	22.09.2026	Krytyczna: wczytanie pliku PHP i wykonanie kodu (CVE-2026-87902)	Bez logowania, przy określonym motywie i konfiguracji PHP

Dwie rzeczy z tej tabeli warto zapamiętać. Po pierwsze, wiele luk wymaga zalogowania, choćby na konto autora lub współpracownika. To argument za porządkiem w kontach, o czym niżej. Po drugie, historia 6.9.2 i 6.9.3 pokazuje, że nawet poprawka bezpieczeństwa potrafi coś zepsuć. Dlatego szybka aktualizacja i szybki test muszą iść w parze.

Dlaczego luka w rdzeniu jest groźniejsza, choć zdarza się rzadko

Według raportu Patchstack „State of WordPress Security in 2026” w 2025 r. w ekosystemie WordPressa wykryto 11 334 nowe podatności. 91% dotyczyło wtyczek, 9% motywów, a w samym rdzeniu było ich tylko 6, i to o niskim priorytecie. Rok 2026 pokazuje jednak, że rdzeń też potrafi zaskoczyć.

Luka we wtyczce dotyczy tylko stron, które mają tę wtyczkę. Luka w rdzeniu dotyczy potencjalnie każdej strony na WordPressie, więc atakującym opłaca się szybko przygotować automat i skanować cały internet. Ten sam raport podaje, że przy najczęściej atakowanych lukach ważona mediana czasu do pierwszego ataku wynosiła 5 godzin. Aktualizacja „w przyszłym tygodniu, jak ktoś znajdzie chwilę” oznacza więc kilka dni wystawienia strony na atak.

Jak ograniczać ryzyko: 7 warstw ochrony

1. Automatyczne aktualizacje bezpieczeństwa

WordPress domyślnie sam instaluje drobne wydania rdzenia (np. z 7.1.1 na 7.1.2). Problem w tym, że ktoś mógł to kiedyś wyłączyć: poprzedni wykonawca, wtyczka albo hosting. Jak to sprawdzić:

• W panelu otwórz Kokpit, Aktualizacje. Na górze zobaczysz informację, czy strona aktualizuje się automatycznie i w jakim zakresie.
• W Narzędzia, Zdrowie witryny sprawdź, czy nie ma ostrzeżenia o aktualizacjach w tle.
• Sprawdź numer wersji. Po 22 września powinna to być 7.1.2 albo wersja z poprawką w Twojej gałęzi, np. 6.9.9.
• Upewnij się, że adres e-mail administratora w ustawieniach ogólnych trafia do kogoś, kto czyta te wiadomości. WordPress wysyła tam powiadomienia o automatycznych aktualizacjach i ich błędach.

2. Stara gałąź WordPressa: poprawka to nie wsparcie

To, że poprawkę przeniesiono aż do 4.7, nie znaczy, że stara wersja jest bezpieczna. Zespół WordPressa wprost pisze, że aktywnie wspierana jest tylko najnowsza wersja, a poprawki dla starszych gałęzi przygotowuje „tam, gdzie to konieczne”. Takie backporty mają też swój koniec: w 2025 r. zespół bezpieczeństwa zakończył wydawanie poprawek dla wersji 4.1-4.6, uzasadniając to kosztem ich przygotowania. Jeśli Twoja strona stoi na starej gałęzi, zaplanuj przejście na aktualną wersję. Jak to zrobić bez przestoju, opisujemy we wpisie WordPress 7 w firmie: aktualizować teraz?

3. Monitoring wersji i powiadomienia

Ktoś musi wiedzieć o nowym wydaniu bezpieczeństwa tego samego dnia. W praktyce to subskrypcja ogłoszeń na wordpress.org albo alertów z bazy podatności (Patchstack, Wordfence, WPScan) oraz narzędzie, które pokazuje wersje rdzenia, wtyczek i PHP na wszystkich Twoich stronach w jednym miejscu. Przy kilku serwisach, np. stronie firmowej, sklepie i landingu kampanii, łatwo o jeden zapomnieć.

4. WAF: przydatny, ale nie zamiast aktualizacji

Zapora aplikacyjna (WAF) filtruje ruch i potrafi zablokować znany atak, zanim trafi do WordPressa. Przy CVE-2026-87902 Patchstack wdrożył regułę ochronną w dniu publikacji poprawki. Granice są jednak wyraźne: w testach opisanych w raporcie Patchstack standardowe zabezpieczenia firm hostingowych zablokowały tylko 26% ataków. WAF kupuje czas do aktualizacji, ale jej nie zastępuje.

5. Konta, uprawnienia i 2FA

Luki z 7.0.4 i 7.1.1 wymagały konta autora lub współpracownika. Każde zbędne konto z takimi uprawnieniami to dodatkowa furtka. Dlatego:

• nadawaj najniższą rolę, która wystarcza do pracy (redaktor tekstów nie potrzebuje roli administratora),
• usuwaj konta byłych pracowników, agencji i freelancerów zaraz po zakończeniu współpracy,
• włącz logowanie dwuskładnikowe (2FA) przynajmniej dla administratorów i redaktorów, przez wtyczkę albo firmowe logowanie jednokrotne,
• nie używaj wspólnych kont „admin” dla kilku osób.

6. Mniej funkcji, mniej punktów ataku

Wyłącz to, czego nie używasz. Przykładem jest XML-RPC, starszy interfejs do zdalnej publikacji. Wrześniowa poprawka 7.1.1 dotyczyła m.in. obejścia uprawnień właśnie przez XML-RPC. Jeśli nie korzystasz z aplikacji mobilnej WordPressa ani z usług, które go wymagają, można go zablokować. Usuń też nieaktywne motywy i wtyczki. Pamiętaj przy tym, że ukrywanie numeru wersji czy zmiana adresu logowania nie zastępują aktualizacji: automaty i tak próbują ataku na każdej stronie.

7. Kopie zapasowe i szybka ścieżka wdrożenia

Kopia zapasowa przechowywana poza serwerem i sprawdzona próbnym odtworzeniem to Twój plan awaryjny. Do tego przyda się kopia testowa strony, na której w ciągu godziny sprawdzisz poprawkę: formularze, logowanie, a w sklepie całe zamówienie z płatnością. Dla wydań bezpieczeństwa warto ustalić z wykonawcą skróconą procedurę: aktualizacja, krótki test, wdrożenie, bez czekania na zaplanowane okno prac. Więcej o tym, co powinno wchodzić w stałą opiekę, piszemy we wpisie o opiece nad stroną WordPress w 2027 roku.

Co zrobić, gdy luka jest już wykorzystywana

Jeśli aktualizacja przyszła za późno albo coś budzi niepokój (nowe konta administratorów, nieznane pliki, przekierowania do obcych stron, ostrzeżenia w przeglądarce), działaj według planu:

1. Zaktualizuj rdzeń do wersji z poprawką, zanim zaczniesz sprzątać. Inaczej atakujący wróci tą samą drogą.
2. Zabezpiecz dowody: zrób kopię obecnego stanu plików, bazy i logów serwera, zanim cokolwiek usuniesz.
3. Przejrzyj logi pod kątem żądań opisanych wyżej oraz nowych plików PHP w miejscach, gdzie nie powinno ich być, w tym w katalogach tymczasowych.
4. Sprawdź integralność plików rdzenia. Polecenie wp core verify-checksums z WP-CLI porównuje pliki WordPressa z sumami kontrolnymi z wordpress.org i pokazuje, co zostało zmienione. Wtyczki z katalogu wordpress.org sprawdzisz podobnie poleceniem wp plugin verify-checksums.
5. Zmień hasła i klucze: wszystkich administratorów, do bazy danych, FTP/SSH i panelu hostingu, a także klucze bezpieczeństwa (salts) w pliku konfiguracyjnym, co wyloguje wszystkie sesje.
6. Usuń nieznane konta i sprawdź role pozostałych użytkowników.
7. Jeśli nie masz pewności, że strona jest czysta, odtwórz ją z kopii sprzed ataku i dopiero potem zaktualizuj.

Jeśli na stronie lub w sklepie są dane klientów, oceń z prawnikiem, czy incydent wymaga zgłoszenia do UODO. Gdy Twoimi klientami są firmy objęte NIS2, mogą też oczekiwać informacji o incydencie w terminie z umowy. Piszemy o tym we wpisie NIS2 u Twojego klienta: czego zażąda od dostawcy IT. Ten wpis nie jest poradą prawną.

Checklista na dzień ogłoszenia poprawki

• Sprawdź, jakie wersje naprawia wydanie i czy Twoja strona jest wśród nich.
• Potwierdź, że automatyczna aktualizacja zadziałała. Jeśli nie, zaktualizuj ręcznie jeszcze tego samego dnia.
• Zrób kopię zapasową tuż przed ręczną aktualizacją.
• Przetestuj kluczowe ścieżki: formularz, logowanie, koszyk i płatność.
• Sprawdź, czy WAF lub hosting ma już regułę dla tej luki.
• Przejrzyj listę administratorów i logi z ostatnich dni.
• Zapisz, kiedy i kto zaktualizował stronę. Przy ankietach bezpieczeństwa od klientów taki zapis bardzo się przydaje.

Sprawdzimy, czy Twoja strona jest gotowa na kolejną lukę

Jeśli nie wiesz, czy Twoja strona ma włączone automatyczne aktualizacje, na jakiej gałęzi WordPressa działa i kto zareaguje przy następnej krytycznej poprawce, zacznij od przeglądu technicznego. Opisujemy go we wpisie o audycie strony internetowej.

Możemy też przejąć stałą opiekę: aktualizacje, kopie zapasowe, monitoring i reakcję na incydenty. Napisz do nas, podaj adres strony, a sprawdzimy jej stan po ostatnich wydaniach bezpieczeństwa.