WordPress 7.1.2 łata CVE-2026-87902: kiedy aktualizacja staje się incydentem

WordPress opublikował aktualizację bezpieczeństwa 7.1.2, która usuwa krytyczną podatność CVE-2026-87902 w samym rdzeniu systemu. Nieuwierzytelniony napastnik może w określonych warunkach skłonić mechanizm wyboru szablonu strony do dołączenia lokalnego pliku PHP spoza katalogu aktywnego motywu. Najpierw oznacza to możliwość odczytu lub uruchomienia pliku, a przy spełnieniu dodatkowych warunków — zdalne wykonanie kodu.

Dla właściciela firmy najważniejsza informacja brzmi prosto: nie wystarczy zapytać, czy „WordPress aktualizuje się automatycznie”. Trzeba potwierdzić wersję każdej działającej instancji, ustalić, czy środowisko spełnia warunki ataku, oraz sprawdzić, czy podczas okresu ekspozycji nie pojawiły się oznaki włamania.

Co wydarzyło się 22 września

Oficjalny komunikat WordPress 7.1.2 klasyfikuje problem jako krytyczny i zaleca natychmiastową aktualizację. Poprawka trafiła do najnowszej wersji oraz, grzecznościowo, do gałęzi otrzymujących poprawki bezpieczeństwa aż do WordPressa 4.7.

Podatne są między innymi WordPress 7.1.0–7.1.1, 7.0.0–7.0.5, 6.9.0–6.9.8 i kolejne starsze linie wskazane w oficjalnym advisory GHSA-7hp8-65ch-5whp. Odpowiednie poprawione wydania to 7.1.2, 7.0.6, 6.9.9, 6.8.10 i właściwe backporty dla starszych gałęzi.

To jednak nie znaczy, że wieloletnia wersja WordPressa staje się bezpieczna tylko dlatego, że otrzymała jeden backport. WordPress przypomina, że aktywnie wspierana jest najnowsza wersja. Stary rdzeń, PHP, motyw i wtyczki mogą mieć inne znane problemy.

Kiedy luka może prowadzić do wykonania kodu

Advisory opisuje dwa istotne warunki. Aktywny motyw nadrzędny lub potomny musi mieć w głównym katalogu folder, którego nazwa zaczyna się od page-, na przykład page-templates. Drugi warunek to obecność na serwerze lokalnego pliku PHP, który proces WWW może odczytać i który da się wykorzystać do uzyskania poważniejszego skutku.

Wśród wymienionych przykładów motywów znajdują się starsze Twenty Twelve i Twenty Fourteen oraz popularne motywy zewnętrzne, takie jak Neve, Hestia i Sydney. To przykłady warunku, a nie kompletna lista podatnych stron. Sama obecność jednego z motywów również nie dowodzi skutecznego ataku.

Oficjalna ocena to 9,2 w CVSS 4.0. Atak odbywa się z sieci, nie wymaga konta ani działania użytkownika, ale wymaga określonego układu motywu i środowiska serwerowego. Dlatego „warunkowe RCE” nie oznacza ani „każda strona została przejęta”, ani „możemy poczekać”.

Plan na dziś dla właściciela strony

1. Ustal wszystkie instalacje. Uwzględnij stronę główną, sklep, blog, landing page, środowiska testowe, strony dawnych kampanii i kopie uruchomione u agencji.
2. Potwierdź realną wersję. Sprawdź panel, system plików lub wynik zarządzania hostingiem. W klastrze zweryfikuj każdy węzeł, a nie tylko jeden ekran.
3. Wykonaj kontrolowaną kopię. Zabezpiecz bazę, pliki i konfigurację przed aktualizacją, ale nie traktuj kopii jako zamiennika poprawki.
4. Zaktualizuj do właściwego wydania. Najlepiej przejdź na aktualnie wspieraną linię. Jeżeli dziś możesz wdrożyć tylko backport, zaplanuj modernizację z konkretną datą i właścicielem.
5. Wyczyść cache i zweryfikuj ruch. CDN, cache opcode, obrazy kontenerów i stare repliki mogą nadal serwować poprzedni kod.
6. Sprawdź najważniejsze funkcje. Formularze, logowanie, płatności, koszyk, wysyłkę maili i integracje przetestuj po aktualizacji.
7. Zachowaj logi. Nie czekaj, aż krótka retencja skasuje dane potrzebne do ustalenia, czy ktoś próbował wykorzystać lukę.

Jeśli stroną zarządza agencja, poproś o numer wdrożonej wersji, czas aktualizacji, listę objętych instancji i wynik walidacji. Zdanie „mamy automatyczne aktualizacje” nie jest dowodem wykonania.

Co sprawdzić pod kątem włamania

Szukaj nowych lub zmienionych plików PHP w katalogach motywów, wtyczek, uploads, mu-plugins i katalogu głównym. Porównaj rdzeń i rozszerzenia z czystymi paczkami. Przejrzyj nowe konta administratorów, aplikacyjne hasła, zadania cron, zmiany aktywnego motywu, nietypowe żądania HTTP oraz procesy i połączenia wychodzące z serwera.

Nie buduj detekcji wyłącznie na jednym ciągu URL znalezionym w internecie. Oficjalny opis pokazuje klasę błędu i warunki, nie kompletny katalog wszystkich sposobów wykorzystania. Ważniejsza jest korelacja: nietypowe żądanie, wykonanie PHP, zmiana pliku, nowa sesja administratora i połączenie wychodzące w krótkim czasie.

Jeżeli widzisz oznaki wykonania kodu, sama aktualizacja nie kończy incydentu. Odizoluj instancję, zachowaj dowody, odtwórz ją z zaufanego artefaktu i oceń sekrety dostępne z hosta: dane bazy, sole WordPressa, klucze API, SMTP, płatności i tokeny wdrożeniowe.

Co ta wiadomość oznacza dla biznesu

Strona firmowa nie jest wyłącznie materiałem marketingowym. Często obsługuje leady, dane kandydatów, zamówienia, płatności i integracje z CRM. Przejęcie jej może prowadzić do podmiany numeru rachunku, formularza logowania, kodu analitycznego albo treści widzianej przez klientów.

Osoba odpowiedzialna za ryzyko powinna znać odpowiedzi na cztery pytania: kto utrzymuje stronę, w jakim czasie wdraża poprawki krytyczne, jak firma potwierdza brak kompromitacji i jak odzyskuje usługę bez przywracania zainfekowanej kopii. To jest temat właścicielski, nie tylko techniczny.

Fakty źródłowe i wnioski Breachroad

WordPress potwierdza krytyczną lukę, zalecenie natychmiastowej aktualizacji oraz dostępność backportów. GHSA potwierdza CVE-2026-87902, ocenę 9,2, zakres wersji, warunki po stronie motywu i serwera oraz możliwość warunkowego RCE. Publiczne źródła nie dowodzą, że każda instalacja jest podatna ani że doszło do masowego wykorzystania.

Kolejność inwentaryzacji, zachowania logów, testów i reakcji na oznaki włamania jest oceną Breachroad wynikającą z typowego wpływu wykonania kodu w aplikacji WWW. Podstawową higienę opisuje też nasz poradnik bezpieczeństwa WordPressa. Zespoły utrzymujące aplikacje mogą przećwiczyć podobne decyzje podczas szkolenia z bezpieczeństwa aplikacji webowych, a przy potrzebie niezależnej weryfikacji zamówić test aplikacji webowej.