Amerykańska agencja CISA dopisała 3 listopada 2026 roku lukę CVE-2026-119977 w mechanizmie aktualizacji WordPressa do katalogu podatności wykorzystywanych w atakach, więc każda strona na wersji od 4.7 do 7.1.3 powinna dziś przejść na 7.1.4 albo na poprawioną wersję swojej gałęzi. Luka pozwala uruchomić kod na serwerze bez logowania, ale tylko w krótkim oknie, gdy WordPress aktualizuje się pełną paczką. Poprawki wyszły 28 października dla wszystkich gałęzi od 4.7 w górę. Stan na 4 listopada 2026 roku, godz. 07:25, według katalogu CISA, bazy NVD, komunikatu i listy wydań na wordpress.org oraz bazy Wordfence.
Co to za luka w WordPressie i kogo dotyczy
CVE-2026-119977 to błąd w rdzeniu WordPressa, czyli w samym systemie, który ma każda instalacja, niezależnie od wtyczek. Dotyczy wersji od 4.7 do 7.1.3. Podczas aktualizacji pełną paczką WordPress rozpakowywał nowe pliki do katalogu o przewidywalnej nazwie w folderze wp-content/upgrade, do którego da się dojść z przeglądarki. Napastnik, który trafi w ten moment, może według opisu w bazie NVD uruchomić na serwerze własny kod. Konto na stronie nie jest mu potrzebne.
Taki błąd fachowo nazywa się wyścigiem (TOCTOU, od “time-of-check time-of-use”). Atakujący musi zdążyć między dwiema czynnościami serwera. Dlatego Wordfence, który nadał luce numer, wycenił ją na 8,1 w skali CVSS. To ocena wysoka, ale z dopiskiem, że atak jest trudny do przeprowadzenia. Sam WordPress w biuletynie na GitHubie oznaczył wagę jako niską.
Lukę zgłosił Umut Bayram z firmy Picus Security. WordPress opisał ją w komunikacie o wersji 7.1.4 z 28 października jako słabość procesu aktualizacji, która w oknie aktualizacji może prowadzić do zdalnego wykonania kodu.
Na zdjęciu wyróżniającym: przypinki z logo WordPressa. Fot. Lisa Risager, Wikimedia Commons, licencja CC BY-SA 2.0.
Co oznacza wpis do katalogu CISA KEV
Katalog KEV (Known Exploited Vulnerabilities) to lista luk, o których amerykańska agencja CISA wie, że są wykorzystywane w prawdziwych atakach. WordPress trafił do niego 3 listopada, a wersja katalogu z tym wpisem wyszła o 21:00 czasu polskiego. Urzędy federalne w USA mają usunąć lukę do 6 listopada. Polskich firm ten termin nie obowiązuje, ale wpis oznacza, że ataki już są.
Katalog nie mówi, ile stron zaatakowano ani kto atakuje. Przy pytaniu o udział gangów ransomware ma wpis “nieznany”. CISA w swojej ocenie zaznaczyła też, że ataku nie da się w pełni zautomatyzować. Wordfence podawał na karcie luki 4 listopada o 07:22, że w ciągu poprzedniej doby zablokował 12 289 prób jej wykorzystania. To próby zatrzymane przez jedną zaporę; liczby zhakowanych stron żadne źródło nie podaje.
Jak sprawdzić wersję WordPressa
Numer wersji zobaczysz w panelu po zalogowaniu albo jednym poleceniem na serwerze. Nazwy poniżej pochodzą z polskiego tłumaczenia WordPressa.
- Wejdź w Kokpit → Aktualizacje. Strona pokazuje bieżącą wersję i przycisk “Zaktualizuj do wersji 7.1.4”, jeśli aktualizacja czeka.
- Na głównej stronie Kokpitu znajdź widżet W skrócie. Jest w nim zdanie zaczynające się od “Używasz WordPressa” i numeru wersji.
- W prawym dolnym rogu każdej strony panelu stoi napis “Wersja” z numerem.
- Jeśli masz dostęp do serwera przez SSH, wpisz
wp core versionw katalogu strony. To polecenie WP-CLI, które wypisuje sam numer.
Freelancer albo agencja z kilkunastoma stronami szybciej sprawdzi je przez WP-CLI niż przez logowanie do każdego panelu. Jeśli nie wiesz, kto ma dostęp do serwera twojej strony, zapytaj firmę hostingową albo osobę, która ją postawiła.
Która wersja WordPressa ma poprawkę
Poprawkę ma WordPress 7.1.4, a starsze gałęzie dostały własne poprawione wersje tego samego dnia. Gałąź to seria wydań z tym samym początkiem numeru, na przykład 6.8.x. Według listy wydań na wordpress.org wszystkie wersje z poprawką od 4.7.39 do 7.1.4 mają datę 28 października 2026 roku. Ten sam zestaw podaje Wordfence w zaleceniu naprawczym i WordPress w biuletynie GHSA-4w3m-c66w-69mg.
| Masz gałąź | Wersja z poprawką |
|---|---|
| 7.1 | 7.1.4 |
| 7.0 | 7.0.8 |
| 6.9 | 6.9.11 |
| 6.8 | 6.8.12 |
| 6.7 | 6.7.11 |
| 6.6 | 6.6.11 |
Pozostałe gałęzie dostały wersje 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34 i 4.7.39.
Dopisek WordPressa o starszych gałęziach mówi, że poprawki przeniesiono do nich “grzecznościowo”. Aktywnie wspierana jest tylko najnowsza wersja. Wersje sprzed 4.7 nie są na liście podatnych na tę lukę, ale nie dostały też żadnej z październikowych poprawek. Ostatnie wydanie gałęzi 4.6 pochodzi z 17 lipca 2025 roku. Stronę na takiej wersji trzeba przenieść na 7.1.4.
Czy automatyczna aktualizacja chroniła stronę
Źródła tego nie rozstrzygają. Komunikat WordPressa mówi tylko, że strony z automatycznymi aktualizacjami w tle zaczną aktualizację same. Ani WordPress, ani Wordfence, ani CISA nie piszą, czy samo przejście na 7.1.4 mogło zostać wykorzystane.
Z kodu wynika jedno. Zabezpieczenie dodano w wersji 7.1.4, w pliku odpowiedzialnym za rozpakowywanie paczek. Katalog roboczy dostaje tam losową końcówkę z 16 znaków, a w folderze wp-content/upgrade pojawia się plik index.php, który nie pozwala wyświetlić listy jego zawartości. Aktualizację na 7.1.4 rozpakowuje jeszcze kod starszej wersji. To nasz wniosek z porównania pliku class-wp-upgrader.php w wersji 7.1.4 z jego odpowiednikiem w 7.1.3; WordPress tego nie komentował.
CISA oznaczyła tę lukę jako wymagającą od urzędów analizy śladów ewentualnego włamania. Trzy szybkie kontrole po aktualizacji wyłapią oczywiste anomalie, ale pełnej analizy powłamaniowej nie zastąpią:
wp core verify-checksumsw WP-CLI porównuje pliki rdzenia z sumami kontrolnymi z wordpress.org i wypisuje te, które się nie zgadzają;- w Użytkownicy sprawdź, czy nie pojawił się administrator, którego nie znasz;
- w folderze
wp-content/upgradepoza plikiemindex.phpnie powinno być starych katalogów roboczych ani paczek. Ich obecność nie dowodzi włamania, ale wymaga sprawdzenia.
Jak bezpiecznie zaktualizować WordPressa do 7.1.4
Aktualizacja WordPressa zajmuje kilka minut, a kopia zapasowa jest jedynym krokiem, którego nie warto pomijać. Dokumentacja WordPressa o kopiach przypomina, że kopia obejmuje dwie części: pliki strony i bazę danych.
- Zrób kopię plików i bazy danych. Większość firm hostingowych ma do tego narzędzie w panelu klienta.
- Wejdź w Kokpit → Aktualizacje i kliknij “Zaktualizuj do wersji 7.1.4”. Na serwerze z WP-CLI to samo zrobi
wp core update. - Sprawdź numer wersji jeszcze raz, jednym ze sposobów z sekcji wyżej.
- Otwórz stronę główną, formularz kontaktowy i koszyk sklepu, jeśli go masz.
Jeśli zamiast przycisku WordPress prosi o dane FTP, pliki strony należą do innego użytkownika serwera niż ten, który uruchamia WordPressa. Tak jest na części hostingów i wtedy aktualizację przeprowadzisz z danymi FTP albo przez firmę hostingową. Gdy aktualizacja się przerwie i strona pokazuje komunikat o konserwacji, dokumentacja WordPressa każe usunąć plik .maintenance z głównego katalogu strony.
Strona na bardzo starej wersji potrzebuje też nowszego PHP. Wymagania PHP dla każdej wersji i sposób sprawdzenia wersji na serwerze opisaliśmy przy okazji poprawek luk w PHP.
Co jeszcze naprawia WordPress 7.1.4
Wydanie 7.1.4 łata też wiele innych błędów, głównie typu XSS, czyli wstrzyknięcia skryptu, który uruchomi się w przeglądarce innego użytkownika. Wiele z nich wymaga konta z rolą co najmniej współtwórcy. Dwa z nich zgłosił Anthropic, firma, która tworzy model Claude. Jeden dotyczył żądań usunięcia danych osobowych, drugi specjalnie przygotowanych loginów użytkowników. W wydaniu jest też aktualizacja dołączonych certyfikatów głównych po unieważnieniu urzędu eMudhra. Kolejna duża wersja, WordPress 7.2, ma wyjść 8 grudnia.
Ta luka nie ma związku z lipcowymi błędami opisanymi jako wp2shell. To osobny problem w innym miejscu kodu. Poprzednią poprawkę bezpieczeństwa przyniosła wersja 7.1.2.
{ strony www }Strona firmowa, która zbiera zapytania od klientów
Projektujemy strony dla firm na WordPressie: szybkie, wygodne na telefonie i przygotowane pod Google. Pomożemy też napisać treści, które jasno tłumaczą, co sprzedajesz.
Podsumowanie
Luka CVE-2026-119977 w aktualizatorze WordPressa jest od 3 listopada w katalogu CISA podatności wykorzystywanych w atakach. Dotyczy wersji od 4.7 do 7.1.3 i pozwala bez logowania uruchomić kod na serwerze, ale tylko w trakcie aktualizacji pełną paczką. Poprawki dla wszystkich gałęzi od 4.7 wyszły 28 października, a najnowsza wersja to 7.1.4. Źródła nie mówią, czy sama automatyczna aktualizacja na 7.1.4 była narażona. Dziś sprawdź numer wersji w Kokpicie albo poleceniem wp core version. Zrób kopię plików i bazy, a potem zaktualizuj stronę. Po aktualizacji porównaj pliki rdzenia z sumami kontrolnymi i przejrzyj listę administratorów. Stan na 4 listopada 2026 roku, godz. 07:25.
.jpg){kind=link}