WordPress 7.1.2: krytyczna luka w rdzeniu pozwala na zdalne wykonanie kodu bez logowania
WordPress 7.1.2 łata krytyczną lukę w rdzeniu — CVE-2026-87902
22 września 2026 zespół WordPress.org wydał wersję 7.1.2. To release bezpieczeństwa — i to nietypowo poważny. Łata błąd oznaczony jako CVE-2026-87902, z oceną CVSS 9.2. Chodzi o funkcję get_page_template(), czyli mechanizm, który WordPress używa do wybrania pliku szablonu renderującego stronę. W określonych warunkach nieautoryzowany atakujący mógł skłonić ten mechanizm do wczytania dowolnego czytelnego pliku PHP spoza katalogu aktywnego motywu — czyli klasyczny path traversal prowadzący do lokalnego dołączenia pliku (LFI). Przy spełnieniu dodatkowych warunków po stronie serwera i aktywnego motywu ten sam błąd może prowadzić także do zdalnego wykonania kodu.
Najważniejsze w tej łatce jest to, kogo dotyczy. Błąd siedzi w rdzeniu od wersji 4.7.0, z 2016 roku, aż po 7.1.1. WordPress.org wydał więc nie tylko 7.1.2, ale też serię łat wstecznych dla starszych gałęzi, dokładnie dlatego, że duża część zainstalowanej bazy siedzi na starszych wersjach i nie da się tego zignorować jednym zbiorczym wydaniem. Atak nie wymaga konta na stronie ani żadnej interakcji zalogowanego użytkownika — to sama luka w logice wyboru szablonu.
Część motywów jest bardziej bezpośrednio wystawiona na ten wektor niż inne — wśród wymienianych w analizach są starsze motywy domyślne, Twenty Twelve i Twenty Fourteen, oraz kilka popularnych motywów firm trzecich. To nie znaczy, że reszta jest bezpieczna — mechanizm jest w rdzeniu, więc ryzyko związane z samym odczytem pliku dotyczy w praktyce każdej instalacji bez aktualnej łatki, niezależnie od motywu.
Co istotne z perspektywy kogoś, kto faktycznie utrzymuje stronę: według doniesień branżowych skanowanie i próby wykorzystania tej luki zaczęły się w ciągu kilku godzin od publikacji łatki. To standardowy wzorzec przy krytycznych podatnościach rdzenia — publikacja poprawki jest jednocześnie mapą, gdzie szukać dziury. Jeśli Twój panel WordPressa nie zaktualizował się automatycznie do 7.1.2 albo do odpowiedniej łaty wstecznej, warto zrobić to ręcznie z kokpitu, zamiast czekać na cykliczną aktualizację w tle.
Dla administratora strony to dobra okazja, żeby sprawdzić dwie rzeczy: czy automatyczne aktualizacje bezpieczeństwa są włączone, oraz czy hosting, na którym stoi strona, w ogóle na to pozwala i nie blokuje zapisu plików rdzenia. W naszym rankingu uwzględniamy między innymi to, jak środowisko hostingowe podchodzi do aktualizacji i bezpieczeństwa — metodologię tych testów opisujemy dokładnie na stronie jak testujemy. Pytania o konkretny przypadek możesz zadać przez kontakt.
