WordPress 7.1.2 został wydany 22 września 2026 roku jako kolejna aktualizacja bezpieczeństwa dla najpopularniejszego systemu CMS. Nowa wersja usuwa podatność CVE-2026-87902 dotyczącą mechanizmu rozwiązywania szablonów stron. Błąd nie wymaga uwierzytelnienia, a przy spełnieniu określonych warunków po stronie motywu i środowiska serwera prowadzi od Local File Inclusion do zdalnego wykonania kodu PHP.
Aktualizacja została udostępnioa zaledwie kilka dni po WordPressie 7.1.1. Wydana 17 września wersja zawierała 17 poprawek błędów w WordPress Core oraz 11 poprawek bezpieczeństwa. Pięć dni później została zastąpiona przez 7.1.2, ponieważ zespół bezpieczeństwa udostępnił poprawkę dla kolejnej podatności, tym razem sklasyfikowanej jako krytyczna.
Ochrona WordPressa nie kończy się na instalacji najnowszej wersji CMS-a. Na hostingu SEOHOST strony są dodatkowo chronione przez Monarx Security, który działa po stronie infrastruktury serwerowej i wykorzystuje Antivirus + Active Protection, ThreatShield oraz SmartWAF. System nie zastępuje aktualizacji WordPressa, ale stanowi dodatkową warstwę ochrony przed malware i określonymi próbami ataku. Więcej informacji znajdziesz w poradnikach: jak działa ochrona Monarx w SEOHOST oraz co obejmuje ochrona Monarx.
WordPress, Elementor i WooCommerce – co zaktualizować?
WordPress Core nie jest jedynym elementem wymagającym uwagi. W drugiej połowie września poprawki bezpieczeństwa otrzymały również Elementor oraz WooCommerce. Ryzyko związane z poszczególnymi błędami jest różne, dlatego nie należy sprowadzać wszystkich trzech aktualizacji do jednego poziomu zagrożenia.
| Oprogramowanie | Wersja z poprawką | Problem | Znaczenie |
|---|---|---|---|
| WordPress | 7.1.2 | CVE-2026-87902 – path traversal / Local File Inclusion prowadzące warunkowo do RCE | Krytyczne |
| Elementor | 4.3.2 lub nowsza | CVE-2026-62062 – Cross-Site Request Forgery | CVSS 8.8 |
| WooCommerce | 11.1.2 | poprawki bezpieczeństwa dotyczące API, uwierzytelniania, sesji i obsługi opinii | aktualizacja bezpieczeństwa |
Jeżeli zarządzasz stroną opartą na WordPressie, sprawdzenie numeru wersji samego Core nie wystarcza. Wtyczki działają w tym samym środowisku PHP, korzystają z WordPress REST API, bazy danych i uprawnień użytkowników. Podatność w popularnym rozszerzeniu pozostaje podatnością strony również wtedy, gdy WordPress Core jest już aktualny.
WordPress 7.1.2 i CVE-2026-87902
WordPress 7.1.2 usuwa jedną podatność, ale jej charakter uzasadnia osobne wydanie bezpieczeństwa. Problem został oznaczony jako CVE-2026-87902 i dotyczy sposobu, w jaki WordPress rozwiązuje ścieżki wykorzystywane przy wybieraniu szablonów stron.
Odpowiednio przygotowane żądanie wysłane do podatnej strony pozwala niezalogowanemu użytkownikowi wpłynąć na ścieżkę lokalnego pliku PHP, który WordPress próbuje wczytać. W określonych konfiguracjach pozwala to wyjść poza katalog aktywnego motywu i wskazać plik znajdujący się w innym miejscu systemu plików.
Tego typu błąd określamy jako Local File Inclusion (LFI). W przypadku CVE-2026-87902 jest on powiązany z mechanizmem path traversal, czyli manipulowaniem ścieżką w taki sposób, aby aplikacja odwołała się do pliku poza katalogiem, do którego pierwotnie miała się ograniczać.
Do wykorzystania podatności nie jest wymagane konto WordPress ani dostęp do panelu administratora. Pełne przejście od LFI do wykonania kodu wymaga natomiast spełnienia dodatkowych warunków po stronie aktywnego motywu i konfiguracji środowiska PHP.
Jak LFI prowadzi do wykonania kodu?
Samo wskazanie lokalnego pliku PHP nie jest jeszcze równoznaczne z wykonaniem dowolnego kodu przesłanego przez atakującego. Znaczenie CVE-2026-87902 wynika z możliwości połączenia błędu WordPressa z istniejącymi na serwerze komponentami PHP.
Jednym z obserwowanych scenariuszy jest odwołanie do pearcmd.php, czyli narzędzia związanego z PEAR. Jeżeli odpowiedni plik jest dostępny w środowisku serwera, a konfiguracja PHP spełnia wymagane warunki, atakujący wykorzystuje LFI jako punkt wejścia do zapisania własnego pliku PHP. Następny etap prowadzi już do wykonania kodu na serwerze.
Odnotowano aktywne próby wykorzystania CVE-2026-87902. Patchstack zarejestrował pierwsze żądania sprawdzające podatność 22 września, czyli w dniu publikacji WordPressa 7.1.2. Następnie pojawiły się żądania wykorzystujące pearcmd.php oraz próby zapisywania plików PHP. Publiczne narzędzia skanujące tę podatność również znajdują się już w obiegu.
Nie każda instalacja WordPressa 7.1.1 i starsza posiada konfigurację pozwalającą przejść od LFI do RCE. Nie zmienia to jednak sposobu postępowania. Jeżeli używasz podatnego wydania, zainstaluj poprawioną wersję przeznaczoną dla używanej gałęzi.
Starsze wersje WordPressa z poprawką
Zespół WordPress przygotował poprawki nie tylko dla najnowszej gałęzi 7.1. Aktualizacja została przeniesiona również do starszych wydań objętych poprawkami bezpieczeństwa.
| Gałąź WordPressa | Wersja z poprawką CVE-2026-87902 |
|---|---|
| WordPress 7.1 | 7.1.2 |
| WordPress 7.0 | 7.0.6 |
| WordPress 6.9 | 6.9.9 |
| WordPress 6.8 | 6.8.10 |
| WordPress 6.7 | 6.7.9 |
Poprawki udostępniono również dla kolejnych starszych gałęzi, aż do WordPressa 4.7. WordPress jednocześnie przypomina, że aktywnie utrzymywana jest najnowsza wersja systemu. Backport poprawki bezpieczeństwa pozwala zabezpieczyć starszą instalację bez wykonywania w tym samym momencie dużej aktualizacji, ale nie powinien być traktowany jako docelowy model utrzymywania strony przez kolejne lata.
Aktualizacje bezpieczeństwa WordPressa są instalowane automatycznie na stronach, które obsługują automatyczne aktualizacje w tle. Sprawdź mimo to aktualny numer wersji w sekcji Kokpit → Aktualizacje. W Softaculous ustawisz również sposób wykonywania automatycznych aktualizacji WordPressa, wtyczek i kopii zapasowych.
Elementor 4.3.2 – podatność CSRF
Druga istotna poprawka dotyczy Elementora. Podatność CVE-2026-62062 występuje w wersjach Elementor 4.3.0 i 4.3.1. Została usunięta w wydaniu 4.3.2.
Problem znajduje się w mechanizmie obsługującym uwierzytelnianie żądań kierowanych do WordPress REST API. Podatne wersje Elementora sprawdzały surowy adres żądania i wyłączały standardową ochronę CSRF, gdy w URI znajdował się określony fragment związany z endpointem Elementora.
Istotny problem polegał na tym, że sprawdzenie następowało jeszcze przed właściwym routingiem REST API. Atakujący umieszczał więc odpowiedni ciąg znaków w parametrze adresu URL, podczas gdy samo żądanie było kierowane do zupełnie innego endpointu WordPressa.
Co oznacza CSRF w Elementorze?
Atak wymaga interakcji zalogowanego użytkownika. Administrator WordPressa otrzymuje odpowiednio przygotowany link i otwiera go podczas aktywnej sesji. Przeglądarka wysyła następnie żądanie do WordPressa z uprawnieniami tego użytkownika.
W demonstracji podatności badacz wykorzystał ten mechanizm do utworzenia kolejnego konta z rolą administratora. Luka nie ograniczała się wyłącznie do endpointów Elementora, ponieważ błędna decyzja dotycząca uwierzytelnienia następowała przed rozpoznaniem właściwej trasy REST API.
Elementor 4.3.0 i 4.3.1 wymagają aktualizacji. Poprawka znajduje się w wersji 4.3.2. Patchstack ocenia podatność na CVSS 8.8. Jeżeli na stronie działa jedna z dwóch podatnych wersji, zaktualizuj wtyczkę niezależnie od tego, czy WordPress Core został już podniesiony do 7.1.2.
WooCommerce 11.1.1 i 11.1.2
Aktualizacje bezpieczeństwa otrzymał również WooCommerce. Ich charakter jest inny niż w przypadku krytycznej podatności WordPress Core i nie należy zestawiać ich z CVE-2026-87902 jako problemów o identycznym poziomie ryzyka.
WooCommerce 11.1.1 został wydany 18 września. Aktualizacja poprawiła mechanizmy związane z uwierzytelnianiem REST API, uprawnieniami starszego Options API, logowaniem aplikacji mobilnej oraz walidacją sesji gości. WooCommerce oficjalnie oznaczył wydanie jako aktualizację bezpieczeństwa. Zespół projektu poinformował jednocześnie, że poprawione problemy miały niski poziom ryzyka i wymagały uprzywilejowanego administratora.
22 września pojawił się WooCommerce 11.1.2. Wydanie również zostało oznaczone jako security update. Poprawiono między innymi sposób obsługi opinii opartych na adresach e-mail oraz regresję dotyczącą galerii wariantów produktów.
Jeżeli prowadzisz sklep WooCommerce, sprawdź aktualną wersję wtyczki razem z WordPress Core i pozostałymi rozszerzeniami. WooCommerce wskazuje obecnie 11.1.2 jako stabilne wydanie gałęzi 11.1 i przypomina, że za w pełni bezpieczną uznawana jest najnowsza wersja.
Jak zadbać o bezpieczeństwo WordPressa?
Aktualizacja WordPressa usuwa podatność znajdującą się w WordPress Core. Aktualizacja Elementora usuwa błąd z kodu Elementora. Ten sam mechanizm dotyczy WooCommerce i każdej kolejnej wtyczki. Bezpieczeństwo strony jest więc sumą kilku warstw, a nie efektem jednego ustawienia albo pojedynczego programu.
W pierwszej kolejności utrzymuj aktualny WordPress Core, wtyczki i motyw. Usuń rozszerzenia, których już nie wykorzystujesz. Nieużywana, ale pozostawiona na serwerze aplikacja nadal zawiera kod, który przy wykryciu podatności staje się dodatkową powierzchnią ataku.
Automatyczne aktualizacje WordPressa
Drobne wydania bezpieczeństwa WordPressa są przeznaczone do szybkiego wdrażania. Jeżeli instalacja obsługuje aktualizacje w tle, proces rozpoczyna się automatycznie. To szczególnie istotne przy podatnościach takich jak CVE-2026-87902, gdzie automatyczne skanowanie podatnych stron zostało odnotowane jeszcze w dniu publikacji poprawki.
W przypadku stron firmowych, sklepów i rozbudowanych projektów zachowaj jednocześnie kontrolę nad dużymi aktualizacjami wtyczek oraz zmianami wersji głównej. Przed wdrożeniem wykonaj backup, a przy krytycznych projektach sprawdź zmianę na środowisku staging. Więcej o zarządzaniu tym procesem opisaliśmy w poradniku dotyczącym aktualizacji WordPressa 7.
Kopie zapasowe i możliwość odtworzenia strony
Backup nie blokuje ataku, ale ogranicza skutki awarii, błędnej aktualizacji albo uszkodzenia plików. Kopia powinna obejmować zarówno pliki strony, jak i bazę danych. Sam fakt wykonywania backupu również nie wystarcza – administrator powinien wiedzieć, gdzie znajduje się kopia i jak rozpocząć jej odtwarzanie.
Jeżeli korzystasz z Softaculous, zobacz instrukcję: jak wykonać kopię zapasową WordPressa w Softaculous.
Ochrona serwera i Monarx Security
Aktualny CMS ogranicza powierzchnię ataku wynikającą ze znanych podatności, ale nie eliminuje z Internetu skanerów, botów ani prób wykorzystania luk. Dlatego kolejną warstwą zabezpieczeń jest ochrona realizowana po stronie infrastruktury hostingowej.
Na hostingu SEOHOST wykorzystujemy Monarx Security. System działa na poziomie serwera, więc jego podstawowe mechanizmy nie są uzależnione od instalacji dodatkowej wtyczki WordPress ani od ręcznego uruchamiania skanowania przez właściciela strony.
Ochrona składa się z kilku uzupełniających się mechanizmów:
| Mechanizm Monarx | Zakres działania |
|---|---|
| Antivirus + Active Protection | Analizuje pliki znajdujące się na serwerze i automatycznie reaguje na malware jednoznacznie zaklasyfikowane jako złośliwe. |
| ThreatShield | Obserwuje wykonywanie aplikacji PHP i zatrzymuje określone złośliwe żądania podczas działania strony. |
| SmartWAF | Działa na warstwie sieciowej i blokuje określony ruch pochodzący między innymi ze znanych złośliwych źródeł. |
Warstwy działają w różnych miejscach. Część niepożądanego ruchu jest zatrzymywana przed dotarciem do aplikacji, ThreatShield reaguje podczas wykonywania aplikacji PHP, a skaner plików wykrywa złośliwy kod znajdujący się już na serwerze.
To istotna różnica również z punktu widzenia CVE-2026-87902. Oficjalną metodą usunięcia podatności jest aktualizacja WordPressa. System ochrony serwera pełni inną funkcję: ogranicza ryzyko związane z próbami wykorzystania błędów oraz wykrywa skutki infekcji i obecność złośliwych plików.
Monarx rozpoznaje między innymi web shelle, złośliwe mailery, uploadery, phishing, adware i inne skrypty malware. Właściciel hostingu otrzymuje jednocześnie dostęp do panelu Monarx Security w DirectAdminie, gdzie sprawdzi wynik skanowania oraz zdarzenia rejestrowane przez ThreatShield.
Monarx jest dodatkową warstwą ochrony, a nie zamiennikiem aktualizacji. Jeżeli przyczyną problemu jest podatna wtyczka albo nieaktualny WordPress, usunięcie złośliwego pliku nie usuwa źródła podatności. Szczegółowo opisaliśmy to w artykułach Monarx w SEOHOST – jak działa ochrona przed malware? oraz Co obejmuje ochrona Monarx i czego nie skanuje?.
Do tego dochodzą podstawowe zasady administracyjne: silne i unikalne hasła, ograniczona liczba kont administracyjnych, 2FA tam, gdzie jest dostępne, usuwanie starych instalacji oraz kontrolowanie logów i nietypowej aktywności. Bezpieczeństwo WordPressa nie jest jedną funkcją. Jest procesem utrzymywania całego środowiska w aktualnym i kontrolowanym stanie.
Hosting WordPress z ochroną przed malware
Wybierając hosting dla WordPressa, warto patrzeć szerzej niż na pojemność konta i liczbę baz danych. Strona potrzebuje aktualnego środowiska PHP, kopii zapasowych, możliwości zarządzania aktualizacjami oraz ochrony działającej po stronie serwera.
Hosting SEOHOST wykorzystuje szybkie dyski NVMe, serwer LiteSpeed, bezpłatne certyfikaty SSL oraz ochronę przed malware Monarx. Ochrona działa na poziomie infrastruktury hostingowej i nie wymaga instalowania dodatkowego skanera wyłącznie po to, aby rozpocząć analizę plików znajdujących się na koncie.
Szukasz hostingu dla WordPressa z ochroną przed malware? Sprawdź hosting SEOHOST. Jeżeli Twoja strona działa obecnie u innego operatora, skorzystaj również z bezpłatnej migracji do SEOHOST.
Co zrobić po aktualizacji WordPressa?
Po zainstalowaniu WordPressa 7.1.2 albo poprawionej wersji dla starszej gałęzi sprawdź całą instalację. Sam numer wersji Core nie daje informacji o stanie pozostałych komponentów.
- Sprawdź wersję WordPress Core w sekcji Kokpit → Aktualizacje.
- Zaktualizuj wtyczki i motyw, w szczególności Elementor i WooCommerce, jeżeli są zainstalowane.
- Sprawdź działanie strony – formularze, panel administratora, logowanie oraz najważniejsze funkcje serwisu.
- W przypadku sklepu sprawdź proces zakupowy – produkt, koszyk, zamówienie, płatność i wiadomości systemowe.
- Przejrzyj logi i stan ochrony, jeżeli strona działała na podatnej wersji podczas okresu aktywnego skanowania CVE-2026-87902.
Jeżeli aktualizację wykonujesz ręcznie, wcześniej przygotuj kopię zapasową. W przypadku rozbudowanego serwisu testuj większe zmiany na stagingu zamiast bezpośrednio na stronie produkcyjnej.
Jeżeli znajdziesz nieznane pliki PHP, nowe konto administratora, nieautoryzowane przekierowania albo inne oznaki ingerencji, sama aktualizacja nie wystarcza. Zaktualizowany WordPress zamyka podatność, ale nie usuwa automatycznie zmian wykonanych wcześniej przez atakującego. Taka strona wymaga sprawdzenia plików, kont użytkowników, logów oraz pozostałych elementów instalacji.
WordPress pozostaje najczęściej wykorzystywanym systemem CMS na świecie. Według danych W3Techs odpowiada za blisko 59% rynku stron korzystających z rozpoznanego systemu zarządzania treścią.
Komentarze