Wydanie bezpieczeństwa WordPress 7.1.4: co agencje powinny zrobić dziś

Aktualizacja, 5 listopada 2026 r.: Wordfence liczy już ponad 240 000 zablokowanych prób wykorzystania tej luki od 28 października, ze szczytem ponad 74 000 30 października. CISA dodała CVE-2026-119977 do katalogu Known Exploited Vulnerabilities 2 listopada. Wordfence nadal uważa udany atak za trudny w praktyce, bo działa tylko w sekundach, w których trwa aktualizacja. Ich rada jest taka sama jak nasza: zaktualizuj teraz do 7.1.4 lub backportu dla swojej gałęzi i zablokuj pliki PHP w wp-content/upgrade/ na serwerze WWW przed aktualizacją. Użytkownicy darmowej wersji Wordfence dostaną regułę zapory 27 listopada. Źródło: Wordfence, 5 listopada 2026 r..

Aktualizacja, 31 października 2026 r.: ataków przybywa. Wordfence raportuje teraz prawie 59 000 zablokowanych prób w ciągu 24 godzin wobec tymczasowych plików instalacyjnych w wp-content/upgrade/ (wobec 18 500 w pierwszych 21 godzinach). Nadal brak potwierdzonych włamań. Jeśli strona klienta nie ma jeszcze 7.1.4 ani backportu dla swojej gałęzi, zaktualizuj ją dziś i zablokuj folder upgrade na serwerze; nie czekaj do poniedziałku.

WordPress 7.1.4 ukazał się 28 października 2026 r. jako wydanie bezpieczeństwa. Naprawia 22 luki opisane w 17 komunikatach, a te same poprawki przeniesiono do każdej wspieranej gałęzi aż do 4.7.39. Jedna z nich jest nietypowa: luka w samym procesie aktualizacji rdzenia, niewymagająca logowania. Trudno ją wykorzystać, ale atakujący zaczęli jej szukać w ciągu doby, i to jedyny problem w tym wydaniu, którego nie zatrzyma zapora w postaci wtyczki. Oto co to oznacza dla stron klientów, którymi się opiekujesz, i co zrobić dziś.

Co naprawiono

• Wykonanie kodu bez logowania podczas aktualizacji. Przed 7.1.4 folder, do którego WordPress rozpakowuje aktualizacje, wewnątrz wp-content/upgrade/, miał przewidywalną nazwę, a sprzątanie usuwało plik index.php , który blokuje wyświetlanie zawartości katalogu. Atakujący, który trafi w kilka sekund trwania aktualizacji, na stronie, gdzie ten folder jest dostępny z sieci, mógł wykonać kod. Patchstack ocenia złożoność ataku jako wysoką i nie uważa wykorzystania za praktyczne. Ponieważ rozpakowana kopia nie ładuje wtyczek Twojej strony, wtyczka-zapora na poziomie PHP nie może zablokować tego żądania.
• Zapisany XSS z kont Współtwórcy i wyższych, głównie w Interactivity API (7 z 17 komunikatów) i w kilku blokach rdzenia.
• Customizer: nieopublikowane zestawy zmian mogli zobaczyć niezalogowani odwiedzający.

Kogo dotyczy

Każdej strony w wersji niższej niż 7.1.4 lub niż odpowiedni backport (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 i tak dalej, aż do 4.7.39). Strony w wersji 4.6 lub starszej nie dostaną żadnej poprawki. Problemy z XSS są najważniejsze na stronach, na których klienci, autorzy lub autorzy gościnni mają konta Współtwórcy lub wyższe.

Sprawdź stronę w dwie minuty

1. Wersja: w wp-admin przejdź do Kokpit → Aktualizacje albo uruchom wp core version. Wszystko poniżej 7.1.4 (lub backportu dla Twojej gałęzi) wymaga aktualizacji.
2. Folder upgrade: otwórz https://example.com/wp-content/upgrade/ w oknie prywatnym. Chcesz zobaczyć 403 lub 404. Lista plików albo pusta strona 200 oznacza, że folder jest dostępny z sieci.
3. Konta: w Użytkownikach odfiltruj Współtwórców, Autorów i Redaktorów. Usuń konta, których nikt nie używa.

Co zrobić teraz

1. Zaktualizuj rdzeń do 7.1.4 lub backportu dla swojej gałęzi. Małe wydania bezpieczeństwa zwykle instalują się same; sprawdź, czy tak się stało, bo firmy hostingowe i niektóre wtyczki wyłączają automatyczne aktualizacje rdzenia. Najpierw zadbaj o świeżą kopię zapasową, a potem sprawdź stronę główną, formularz i kasę.
2. Zablokuj dostęp z sieci do folderu upgrade na serwerze WWW, nie we wtyczce. Na Apache plik .htaccess w wp-content/upgrade/ z Require all denied. Na nginx location ^~ /wp-content/upgrade/ { deny all; }. WordPress nadal zapisuje do folderu przez PHP, więc aktualizacje działają dalej. Na hostingu zarządzanym, gdzie nie możesz zmienić serwera, poproś o to hosting.
3. Strony w wersji 4.6 lub starszej: zaplanuj teraz przejście na wspieraną wersję. Nie będzie dla nich poprawki.

Atakujący szukają tej luki, ale nie potwierdzono udanych włamań, więc zaktualizowana strona z zablokowanym folderem upgrade nie wymaga przywracania ani wymiany kluczy z powodu samego tego wydania. Jeśli jednak widzisz nieznane pliki w wp-content/upgrade/ lub nowe konta administratorów, traktuj to jako włamanie: przywróć z kopii sprzed pojawienia się tych plików, a potem zmień hasła i klucze salt. Nasza rutyna na dzień ujawnienia luki zawiera wszystkie kroki.

Jak pomaga Verploy

Każda aktualizacja jest sprawdzana. Ryzykowne są najpierw testowane na kopii. Rdzeń WordPressa zawsze uznawany jest za ryzykowny: jest testowany na prywatnej kopii strony, zanim zmieni się działająca strona, a jeśli kontrola po wdrożeniu się nie powiedzie, strona jest automatycznie wycofywana. Nocne szyfrowane kopie zapasowe w UE dają czysty punkt powrotu, a znane luki pojawiają się dla każdej strony z linkiem do źródła.

Źródło: Patchstack, „WordPress 7.1.4 Security Release”, 28 października 2026 r., patchstack.com. Ostrzeżenie Wordfence o wykorzystywaniu, 29 października 2026 r., według SecurityOnline; liczba z 24 godzin według CyberPress, 31 października 2026 r. Sprawdzono 31 października 2026 r.