3 listopada CISA dodała do katalogu KEV, czyli listy podatności wykorzystywanych w realnych atakach, błąd w rdzeniu WordPressa oznaczony jako CVE-2026-119977. Ciekawostką jest to, że luka nie dotyczy działającej strony, lecz chwili, w której WordPress aktualizuje samego siebie. Atakujący, który trafi w odpowiedni moment, może doprowadzić do wykonania własnego kodu na serwerze — bez logowania i bez żadnego konta w serwisie.
Na czym polega wyścig
Przy pełnej aktualizacji rdzenia WordPress rozpakowuje nowe pliki do przewidywalnego katalogu tymczasowego w wp-content/upgrade/. Na wielu serwerach ten katalog jest dostępny z poziomu przeglądarki. W rozpakowanej paczce znajduje się m.in. instalator wp-admin/setup-config.php, który może działać bez konfiguracji prawdziwej strony. Napastnik odpytuje zatem ścieżki tymczasowe i próbuje „wejść” do instalatora, zanim WordPress posprząta po sobie. To klasyczny błąd typu TOCTOU (race condition) — okno czasowe trwa zwykle kilka sekund, ale automatyczne skrypty, które odpytują serwer w kółku, potrafią je trafić.
Skala ataków
Według Wordfence w ciągu pierwszych 21 godzin od ujawnienia szczegółów zarejestrowano ponad 18,5 tys. zapytań do ścieżek ze setup-config.php, a w ciągu doby zablokowano ponad 12,6 tys. prób. Pierwsze ślady ataków widziano już 30 października. Na razie nie ma potwierdzonych udanych włamań, a sam WordPress oceniał lukę nisko, natomiast Wordfence jako autor CVE przyznał jej 8.1 w skali CVSS, z uwagi na wysoką złożoność ataku. Fakt, że CISA wpisała błąd na listę KEV, pokazuje jednak, że to już nie teoria.
Których wersji dotyczy problem
Poprawki wyszły pod koniec października. Dotyczą m.in. gałęzi 7.1 (wersja 7.1.4), 7.0 (7.0.8), 6.9 (6.9.11) i 6.8 (6.8.12), a także wielu starszych gałęzi aż do 4.7. Wersje 4.6 i wcześniejsze nie dostaną już łatki. W nowej wersji nazwa katalogu tymczasowego zawiera losowe znaki, więc nie da się jej odgadnąć.
Co zrobić
Przede wszystkim sprawdź wersję WordPressa i zaktualizuj ją do wydania naprawiającego dla swojej gałęzi. Uwaga praktyczna: sama aktualizacja używa jeszcze starego kodu rozpakowywania, więc przed nią warto zablokować dostęp z sieci do wp-content/upgrade/ w konfiguracji serwera lub w .htaccess i wyłączyć listowanie katalogów. Po aktualizacji przejrzyj logi pod kątem zapytań do plików PHP w tym katalogu, sprawdź listę administratorów i wtyczek pod kątem nieznanych pozycji oraz poszukaj plików PHP, których nikt nie dodawał. Nie polegaj wyłącznie na wtyczkach firewallowych, bo złośliwe żądanie trafia do pliku PHP, zanim załaduje się WordPress. Administratorzy hostingów powinni zwrócić uwagę na strony z wyłączonymi automatycznymi aktualizacjami oraz te działające na wersjach niewspieranych.
Podsumowanie
Ta historia pokazuje, że nawet sam proces łatania może być wektorem ataku, jeśli zostawia po sobie przewidywalne i publicznie dostępne pliki. Blokada katalogu upgrade, aktualizacja do wersji naprawiającej i kontrola logów to kwestia kilkunastu minut, a pozwala uniknąć przejęcia całego serwera.
źródło: https://thehackernews.com/2026/11/cisa-confirms-hackers-exploiting.html