WordPress 7.1.4: 22 poprawki bezpieczeństwa i aktywne ataki – jak sprawdzić, czy Twoja strona jest zaktualizowana

Autor: Grzegorz Wojterzak. Aktualizacja: 3 listopada 2026. Czas czytania: około 11 minut.

Wydania poprawkowe WordPressa zwykle instalują się same i nikt o nich nie myśli. Przy 7.1.4 warto zrobić wyjątek: poprawka zamyka lukę w samym mechanizmie aktualizacji, a zapory już kilka godzin po wydaniu notowały masowe próby jej wykorzystania.

Poniżej wyjaśniam, co zostało poprawione, jak w dwie minuty sprawdzić, czy Twoja strona ma poprawki, co zrobić, gdy jesteś na starszej wersji, i jak zamknąć katalog, przez który idzie atak. Na końcu znajdziesz procedurę, którą możesz stosować przy każdej pilnej aktualizacji bezpieczeństwa.

Co poprawia WordPress 7.1.4 i dlaczego to pilne

Według oficjalnej strony wydania na wordpress.org wersja 7.1.4 usuwa 22 luki bezpieczeństwa i aktualizuje wbudowaną listę certyfikatów głównych po odwołaniu urzędu eMudhra. Dla Ciebie liczą się trzy grupy poprawek.

• Wyścig podczas aktualizacji rdzenia. Wyścig (ang. race condition) to błąd, który pojawia się tylko wtedy, gdy dwie rzeczy dzieją się w tym samym momencie. Tu chodzi o kilka sekund, w których WordPress rozpakowuje nową wersję. Zgłoszony przez badacza Umuta Bayrama błąd mógł w tym czasie doprowadzić do zdalnego wykonania kodu, czyli uruchomienia na serwerze dowolnego programu przez obcą osobę.
• Wstrzykiwanie skryptów przez konta z niższymi uprawnieniami. Kilka poprawek dotyczy luk typu stored XSS, czyli możliwości zapisania w treści strony skryptu, który potem uruchamia się w przeglądarce administratora. Większość wymaga konta z rolą Współpracownik (Contributor) lub wyższą, część roli Autor albo Redaktor. Jeśli na stronie piszą goście, pracownicy albo agencja, to dotyczy Ciebie.
• Pozostałe: ujawnianie niezalogowanym nieopublikowanych zmian z Customizera, uprawnienia moderatorów do notatek, ochrona przed przeciążeniem (DoS).

Co wiadomo o atakach

Firma Wordfence, autor popularnej zapory dla WordPressa, według doniesień mediów branżowych z 30–31 października zablokowała w pierwszej dobie po wydaniu ponad 60 tysięcy prób wykorzystania luki w aktualizacji. To liczba prób, nie włamań. Na tym etapie Wordfence nie informował o potwierdzonych przejęciach stron tą drogą. Regułę zapory dostali od razu płatni klienci Wordfence, a użytkownicy wersji darmowej dostaną ją według tych samych doniesień dopiero 27 listopada 2026.

Patchstack, inna firma zajmująca się bezpieczeństwem WordPressa, ocenia lukę jako trudną do wykorzystania, bo atakujący musi trafić w kilkusekundowe okno trwającej aktualizacji. Zwraca jednak uwagę na dwie rzeczy, które mają praktyczne znaczenie:

• okno otwiera się przy każdej aktualizacji, także automatycznej w środku nocy,
• zapora działająca jako wtyczka WordPressa nie zablokuje tego ataku, bo żądanie trafia do tymczasowej kopii WordPressa, która nie ładuje Twoich wtyczek. Pomaga blokada na poziomie serwera, opisana niżej.

Jak sprawdzić, czy Twoja strona ma poprawkę

Wystarczy jedno z trzech miejsc. Pierwsze pokazuje też ustawienia automatycznych aktualizacji.

1. Ekran aktualizacji w panelu

   Zaloguj się do panelu i wejdź w Kokpit → Aktualizacje (w wersji angielskiej: Dashboard → Updates). Na górze zobaczysz numer obecnej wersji, a pod nim informację, czy strona aktualizuje się sama.

2. Raport stanu strony

   Narzędzia → Stan witryny → Informacja, sekcja WordPress, wiersz Wersja (w wersji angielskiej: Tools → Site Health → Info, Version). Ten raport przyda się też, gdy będziesz rozmawiać z hostingiem.

3. WP-CLI, jeśli masz dostęp do terminala

   WP-CLI to narzędzie do obsługi WordPressa z wiersza poleceń, dostępne na wielu hostingach przez SSH. Pierwsze polecenie podaje wersję. Drugie porównuje pliki rdzenia z oficjalnymi sumami kontrolnymi z WordPress.org, czyli sprawdza, czy aktualizacja podmieniła wszystkie pliki i czy nikt ich nie zmienił.

$ wp core version
7.1.4
$ wp core verify-checksums

Pierwszy wynik pochodzi z instalacji testowej. Przy poprawnej instalacji drugie polecenie kończy się komunikatem Success: WordPress installation verifies against checksums. Jeśli wypisze listę plików, które się nie zgadzają, nie ignoruj tego: to może być nieudana aktualizacja albo ślad włamania.

Jaka wersja jest „dobra” dla Twojej gałęzi

Jeśli nie jesteś na 7.1, nie musisz od razu przeskakiwać na najnowszą wersję. Poprawki dostały także starsze gałęzie. Wersja jest bezpieczna względem tego wydania, jeśli ma co najmniej numer z prawej kolumny:

Dane z oficjalnej strony wydania 7.1.4, stan na początek listopada 2026. Starsze gałęzie mają mniej luk, bo nie mają nowszych funkcji, w których je znaleziono.

Nie zakładaj, że automatyczna aktualizacja zadziałała

WordPress domyślnie instaluje wydania poprawkowe sam, w tle. Działa to w większości przypadków, ale nie zawsze. Najczęstsze powody, dla których strona zostaje na starej wersji, to:

• Brak uprawnień do plików. Jeśli WordPress przy ręcznej aktualizacji pyta o dane FTP, aktualizacja w tle też się nie uda. To sprawa dla hostingu.
• Wyłączone aktualizacje. Ktoś wpisał do wp-config.php stałą AUTOMATIC_UPDATER_DISABLED albo ustawił WP_AUTO_UPDATE_CORE na false, często „na chwilę”. Podobnie działają niektóre wtyczki i instalatory w panelach hostingu.
• Wcześniejsza nieudana aktualizacja. Jeśli poprzednia aktualizacja w tle zakończyła się poważnym błędem, WordPress wstrzymuje kolejne do czasu ręcznej aktualizacji przyciskiem na ekranie aktualizacji.
• Strona pod kontrolą wersji. Gdy pliki są w repozytorium Git, WordPress z założenia nie aktualizuje się sam. Robi to wykonawca.
• Brak ruchu albo wyłączony WP-Cron. Zadania w tle uruchamiają się przy odwiedzinach, więc na rzadko odwiedzanej stronie aktualizacja może się opóźnić.

Na szczęście WordPress sam testuje część tych problemów. Wejdź w Narzędzia → Stan witryny, zakładka Status, i poszukaj testu aktualizacji w tle. Jeśli wszystko jest w porządku, zobaczysz go w zwiniętej sekcji testów zaliczonych jako Aktualizacje w tle działają (w wersji angielskiej Background updates are working). Jeśli nie, pojawi się wśród problemów z opisem przyczyny, np. o stałej w wp-config.php albo o konieczności podawania danych FTP.

Drugi sygnał to mail. Po udanej aktualizacji w tle WordPress wysyła administratorowi wiadomość z tematem [nazwa strony] Your site has updated to WordPress 7.1.4 (w polskiej wersji przetłumaczonym). Jego brak niczego nie dowodzi, bo strona może w ogóle nie wysyłać poczty.

Wtyczki aktualizują się osobno

Automatyczne aktualizacje rdzenia i wtyczek to dwa różne ustawienia. Na liście wtyczek (Wtyczki) jest kolumna Automatyczne aktualizacje, w której włączasz je dla każdej wtyczki osobno. Wydanie 7.1.4 dotyczy rdzenia, ale skoro już jesteś w panelu, sprawdź, czy wtyczki nie wiszą z zaległymi aktualizacjami.

Jak aktualizować bez ryzyka, że strona padnie, i co zrobić, gdy jednak padnie, opisuję w poradniku Strona nie działa po aktualizacji.

Masz starszą wersję WordPressa: co zrobić

Trzy sytuacje, które spotykam najczęściej:

• Gałąź 7.0 lub 6.x, aktualizacje działają. Strona powinna sama dostać poprawkę swojej gałęzi, np. 6.9.11. Sprawdź numer według tabeli wyżej. Przejście na 7.1 zaplanuj osobno, po teście na kopii. Opisuję to w poradniku WordPress 7.2: jak przygotować stronę do aktualizacji.
• Strona na starym PHP. WordPress 7.0 wymaga PHP co najmniej 7.4. Strony na PHP 7.2 lub 7.3 zostają na gałęzi 6.9 i dostają jej poprawki, czyli tu 6.9.11. To nie jest stan na lata. Zmiana PHP to osobny projekt, opisany w poradniku Koniec PHP 8.2. Jeśli po zmianie PHP coś się posypie, zajrzyj do Strona nie działa po zmianie PHP.
• Gałąź 5.x lub 4.x. Poprawki dla nich istnieją, ale WordPress wprost pisze, że aktywnie wspiera tylko najnowszą wersję, a poprawki dla starszych gałęzi publikuje grzecznościowo. Wersje 4.6 i starsze nie dostają już żadnych poprawek. Taka strona zwykle ma też stare wtyczki i motyw, groźniejsze niż sam rdzeń.

Osobną sprawą jest samo PHP: w październiku 2026 załatano w nim krytyczne luki. Aktualizacja WordPressa ich nie naprawia. Opisuję to w poradniku Krytyczne luki w PHP: jak sprawdzić, czy hosting je załatał.

Zablokuj dostęp z internetu do wp-content/upgrade

Katalog wp-content/upgrade/ to miejsce robocze, w którym WordPress rozpakowuje nowe wersje rdzenia, wtyczek i motywów. Przeglądarka nie ma tam czego szukać. WordPress korzysta z niego bezpośrednio na dysku serwera, więc zablokowanie dostępu z internetu nie przeszkadza w aktualizacjach. Zaleca ją Patchstack, a przedstawiciel Wordfence według cytowanych przez media wypowiedzi radzi wdrożyć ją nawet przed aktualizacją.

Serwer Apache lub LiteSpeed (większość polskich hostingów współdzielonych)

Otwórz plik .htaccess w głównym katalogu strony (tam, gdzie leży wp-config.php) menedżerem plików w panelu hostingu albo przez FTP. Zrób kopię pliku. Dopisz poniższe linie nad blokiem # BEGIN WordPress, bo zawartość tego bloku WordPress potrafi nadpisać:

# blokada katalogu roboczego aktualizacji
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Reguła odpowiada na każde żądanie do tego katalogu błędem 403 (dostęp zabroniony). Jeśli WordPress działa w podkatalogu, np. twojadomena.pl/sklep/, wpisz ją do pliku .htaccess w tym podkatalogu.

Serwer Nginx (zwykle VPS albo hosting zarządzany)

Na Nginx nie ma plików .htaccess. Regułę dopisuje się w konfiguracji serwera, w bloku server danej strony, a potem przeładowuje konfigurację. Jeśli nie masz do niej dostępu, wyślij poniższy fragment hostingowi:

location ^~ /wp-content/upgrade/ {
    deny all;
}

Znak ^~ sprawia, że ta reguła wygrywa z regułą obsługującą pliki PHP. Bez niego plik .php z katalogu upgrade mógłby nadal się uruchomić.

Sprawdź, czy blokada działa

Wpisz w przeglądarce adres https://twojadomena.pl/wp-content/upgrade/index.php. Powinien pojawić się błąd 403 (Forbidden). Pusta biała strona oznacza, że plik się wykonał, czyli blokada nie działa. Następnie zrób jedną drobną aktualizację, np. wtyczki, i upewnij się, że przeszła.

Przy okazji zajrzyj do środka katalogu menedżerem plików. Według Patchstack między aktualizacjami powinien zawierać tylko plik index.php. Obce pliki PHP albo stare katalogi z datą z ostatnich dni to powód, żeby sprawdzić stronę dokładniej. Jak to zrobić, opisuję w poradniku Jak sprawdzić, czy strona jest zhakowana.

Jak reagować na każdą pilną aktualizację bezpieczeństwa

Wydanie 7.1.4 za kilka miesięcy będzie historią, ale podobne sytuacje będą się powtarzać. Ta kolejność sprawdza się przy każdej pilnej poprawce rdzenia, wtyczki albo motywu:

1. Ustal, czego dotyczy poprawka

   U źródła: strona wydania na wordpress.org albo dziennik zmian wtyczki. Zanotuj numer wersji z poprawką.

2. Sprawdź numer na stronie, nie w głowie

   Ekran aktualizacji, raport Stan witryny albo WP-CLI. Przy kilku stronach prowadź listę: adres, wersja, data.

3. Kopia, potem aktualizacja

   Przy poprawce bezpieczeństwa nie czekaj tygodnia na testy. Kopia plików i bazy, aktualizacja, przegląd strony głównej, formularza i koszyka.

4. Zamknij drogę ataku, jeśli się da

   Jeśli producent albo firmy bezpieczeństwa podają obejście (blokadę katalogu, regułę serwera), wdróż je mimo aktualizacji.

5. Sprawdź, czy ktoś nie był pierwszy

   Jeśli luka była wykorzystywana przed Twoją aktualizacją, aktualizacja nie usuwa śladów. Przejrzyj administratorów, wtyczki (także zakładkę Wymuszane) i nowe pliki PHP. Szczegóły w poradniku o aktywnie wykorzystywanej luce we wtyczce.

6. Zapisz, co zrobiłeś

   Data, wersja przed i po, obejścia. Przy włamaniu łatwiej będzie ustalić, od kiedy strona była narażona.

Kiedy nie robić tego samemu

Sprawdzenie wersji i kliknięcie aktualizacji to zadanie dla każdego. Pomoc przyda się, gdy:

• aktualizacja kończy się błędem, pytaniem o dane FTP albo zawieszonym trybem konserwacji,
• strona jest na gałęzi 5.x lub starszej, na starym PHP, z wtyczkami, których nikt nie aktualizował od lat,
• nie masz dostępu do .htaccess ani konfiguracji serwera, a hosting nie odpowiada,
• wp core verify-checksums pokazuje zmienione pliki albo w wp-content/upgrade/ leżą obce pliki PHP,
• masz kilka lub kilkanaście stron i nie wiesz, które są aktualne.

Najczęstsze pytania