Luka w WordPressie CVE-2026-119977 wykorzystywana w atakach

28 października WordPress wydał wersję 7.1.4, która łata 22 problemy bezpieczeństwa. Najpoważniejszy z nich, CVE-2026-119977, pozwala osobie bez żadnego konta wykonać kod na serwerze. Haczyk polega na tym, że luka istnieje tylko w trakcie aktualizacji samego WordPressa. 3 listopada amerykańska agencja CISA dopisała ją do katalogu podatności wykorzystywanych w atakach, a Wordfence obserwuje automatyczne próby jej wykorzystania.

Na czym polega luka

Przy pełnej aktualizacji rdzenia WordPress rozpakowuje nową wersję do katalogu tymczasowego w wp-content/upgrade/, a potem przenosi pliki na miejsce. Przez kilka sekund leży tam druga, niepełna kopia WordPressa, w tym instalator konfiguracji. Nazwa tego katalogu była przewidywalna, a na wielu serwerach jest on dostępny z przeglądarki.

Atakujący, który w tym oknie wywoła skrypt z kopii tymczasowej, może doprowadzić do wykonania własnego kodu PHP z uprawnieniami strony. To klasyczny błąd typu time-of-check to time-of-use (CWE-367), oceniony na 8.1 w skali CVSS. Wysoka, ale nie maksymalna ocena wynika z tego, że trzeba trafić w krótkie okno czasowe.

Kłopot w tym, że takie trafienie niewiele kosztuje. Skrypt może bez końca odpytywać tysiące stron o możliwe ścieżki i czekać, aż któraś zacznie się aktualizować. Wordfence widzi dokładnie taki ruch: powtarzane żądania do różnych wariantów katalogu tymczasowego. Poprawka w 7.1.4 losuje nazwę katalogu, dodaje zabezpieczenie przed jego wykonaniem i blokuje przeniesienie niebezpiecznej konfiguracji.

Kogo to dotyczy

• Samodzielnie hostowany WordPress w wersji od 4.7 do 7.1.3, czyli praktycznie każda strona, która nie dostała jeszcze wydania z 28 października.
• Problem dotyczy rdzenia, nie wtyczek ani motywów. Aktualizacje wtyczek i motywów nie otwierają tego okna.
• Ryzyko zależy od konfiguracji serwera: jeśli serwer WWW nie pozwala uruchomić PHP z katalogu wp-content/upgrade/, atak się nie uda.

Jak sprawdzić swoją stronę

1. Wersja WordPressa

W panelu: Kokpit → Aktualizacje. Na serwerze z WP-CLI:

wp core version

Bezpieczne są 7.1.4 oraz wydania wsteczne opublikowane 28 października dla starszych gałęzi (np. 6.9.11). Niższa wersja w danej gałęzi oznacza podatność.

2. Czy katalog tymczasowy jest dostępny z sieci

Sprawdź, co serwer zwraca dla adresu w tym katalogu:

curl -s -o /dev/null -w '%{http_code}\n' https://twoja-strona.pl/wp-content/upgrade/

Odpowiedź 403 albo 404 jest dobra. Odpowiedź 200 oznacza, że w czasie aktualizacji zawartość tego katalogu jest osiągalna z internetu.

3. Logi i nieznane pliki

Przejrzyj logi serwera pod kątem żądań do ścieżek zaczynających się od /wp-content/upgrade/, zwłaszcza zawierających setup-config.php. Po aktualizacji sprawdź, czy w katalogach WordPressa nie pojawiły się pliki PHP, których nie rozpoznajesz:

find . -name "*.php" -newer wp-config.php -not -path "./wp-content/upgrade/*" | head -50

To polecenie pokaże pliki zmienione po ostatniej modyfikacji wp-config.php. Część z nich to normalne efekty aktualizacji, ale plik PHP w katalogu z obrazkami albo o przypadkowej nazwie to sygnał do dokładniejszej analizy.

Co zrobić

1. Najpierw zamknij dostęp do katalogu tymczasowego, żeby sama aktualizacja nie stała się okazją do ataku. Na nginx:

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

   Na Apache dopisz w głównym pliku .htaccess (przed regułami WordPressa) linię RedirectMatch 403 ^/wp-content/upgrade/. Nie umieszczaj reguły w samym katalogu upgrade, bo WordPress może go czyścić. WordPress zapisuje i przenosi te pliki bezpośrednio na dysku, więc blokada dostępu z sieci nie przeszkadza w aktualizacji.
2. Zaktualizuj WordPressa do 7.1.4 lub najnowszej wersji w swojej gałęzi. Najlepiej w spokojnej porze, ręcznie, i z kopią zapasową wykonaną tuż przed.
3. Sprawdź strony, o których zapomniałeś: stare landing page'e, wersje testowe, blogi na subdomenach. Automatyczne aktualizacje bywają tam wyłączone od lat.
4. Jeśli w logach widać próby albo znalazłeś podejrzane pliki, sama aktualizacja nie wystarczy. Trzeba ustalić, czy atak się udał, zmienić hasła i klucze z wp-config.php i przywrócić czystą wersję plików.

Dlaczego to ważne, nawet jeśli masz automatyczne aktualizacje

Automatyczne aktualizacje to dobra praktyka i w tym przypadku pomagają: strony z włączonymi aktualizacjami w tle dostały 7.1.4 bez udziału właściciela. Ta luka pokazuje jednak, że moment aktualizacji też jest powierzchnią ataku, a o wyniku decyduje konfiguracja serwera, nie tylko wersja WordPressa. Blokada wykonywania PHP w katalogach, które nie powinny go uruchamiać, chroni także przed kolejnymi błędami tego typu.

To kolejna w tym roku poważna luka w samym rdzeniu WordPressa. Jeśli Wasza strona albo sklep obsługuje klientów, warto raz na jakiś czas sprawdzić ją z zewnątrz, tak jak zrobiłby to atakujący. Właśnie do tego służy bezpłatny skan ekspozycji, a przy rozbudowanych serwisach test penetracyjny aplikacji webowej.

Źródła: komunikat WordPress 7.1.4 (wordpress.org, 28.10.2026), katalog CISA Known Exploited Vulnerabilities (wpis z 3.11.2026), analizy Wordfence.