WordPress atakowany przez lukę w aktualizacjach: zablokuj jeden folder, zanim zainstalujesz poprawkę

Luka w samym rdzeniu WordPressa, oznaczona jako CVE-2026-119977, jest już wykorzystywana przez przestępców. Amerykańska agencja CISA wpisała ją na listę aktywnie atakowanych podatności, a badacz, który ją znalazł, ostrzega: na części stron ryzyko pojawia się jeszcze raz właśnie podczas instalowania poprawki. Jeśli masz stronę lub sklep na WordPressie, warto poświęcić dziś kwadrans.

Na czym polega problem

Podczas aktualizacji rdzenia WordPress rozpakowuje nową wersję do tymczasowego folderu w wp-content/upgrade. W pełnej paczce aktualizacji znajduje się także instalator WordPressa, a serwer WWW zwykle pozwala otworzyć ten folder z przeglądarki. Jeśli ktoś z zewnątrz odgadnie nazwę folderu i trafi w kilkusekundowe okno, zanim kopia zostanie usunięta, może doprowadzić do wykonania własnego kodu na serwerze. Nie potrzebuje do tego żadnego konta na stronie.

Podatne są wersje od 4.7 do 7.1.3. Ocena CVSS to 8.1 na 10. Sam WordPress oceniał lukę jako mało groźną, bo okno ataku jest bardzo krótkie, ale firma Wordfence zauważyła pierwsze próby ataków zaledwie dziewięć minut po opublikowaniu reguły ochronnej. Część automatów przez kilkanaście godzin regularnie „zaglądała” na wybrane strony, czekając na moment aktualizacji. W publicznych repozytoriach pojawił się też kod opisywany przez autorów jako exploit, choć nie wiadomo, czy działa.

Poprawka jest, ale z haczykiem

WordPress wydał 28 października wersję 7.1.4 z poprawką oraz odpowiedniki dla starszych gałęzi, m.in. 7.0.8, 6.9.11, 6.8.12 i dalej aż do 4.7. Po poprawce tymczasowy folder dostaje losową nazwę. Haczyk polega na tym, że samą aktualizację do wersji z poprawką wykonuje jeszcze stary, niezałatany kod. Na stronach z WordPressem 5.9 lub nowszym nazwa folderu może więc być przewidywalna ostatni raz, podczas tej jednej aktualizacji. Dotyczy to przede wszystkim pełnych paczek, np. przy przeskoku z gałęzi 7.0 na 7.1. Drobne aktualizacje w obrębie jednej gałęzi (np. z 7.1.3 do 7.1.4) zwykle używają mniejszej paczki, która nie musi zawierać instalatora.

Wersje 4.6 i starsze nie dostaną już żadnej poprawki. Takie strony trzeba po prostu przenieść na wspieraną wersję.

Co zrobić krok po kroku

• Sprawdź wersję w kokpicie, w menu Kokpit → Aktualizacje. Jeśli masz 7.1.4 lub poprawioną wersję ze swojej gałęzi, kolejne aktualizacje są już bezpieczne pod tym względem.
• Przed aktualizacją zablokuj folder wp-content/upgrade dla przeglądarki. WordPress korzysta z niego bezpośrednio na dysku, więc blokada nie psuje aktualizacji. Na Nginx służy do tego reguła location ^~ /wp-content/upgrade/ { deny all; }, na Apache dyrektywa Require all denied dla tego folderu, a jeśli możesz edytować tylko plik .htaccess w katalogu głównym strony, wpis RedirectMatch 403 ^/wp-content/upgrade/ nad regułami WordPressa. Nie wrzucaj .htaccess do samego folderu upgrade, bo aktualizator go usunie.
• Sprawdź blokadę: adres twojastrona.pl/wp-content/upgrade/ powinien zwracać błąd 403.
• Dopiero potem zaktualizuj do 7.1.4 lub poprawionej wersji ze swojej gałęzi. Uwaga: polecenie wp core update z WP-CLI korzysta z tego samego mechanizmu, więc nie jest obejściem problemu.
• Nie masz dostępu do konfiguracji serwera? Na hostingu współdzielonym poproś firmę hostingową o blokadę folderu albo o ręczną aktualizację poza katalogiem publicznym.

Jak sprawdzić, czy ktoś już się włamał

Jeśli strona przez ostatnie dni stała na starej wersji, Wordfence radzi poszukać kilku sygnałów: nieznanych kont administratorów, wtyczek, których nikt nie instalował, plików PHP w folderze wp-content/upgrade oraz w logach serwera nietypowych zapytań do plików PHP w tym folderze. W razie wątpliwości zmień hasła administratorów i do bazy danych, a incydent zgłoś do CERT Polska przez stronę incydent.cert.pl.

WordPress napędza ogromną część polskich stron firmowych, blogów i sklepów na WooCommerce, więc ta luka dotyczy także wielu małych firm, które aktualizacje zostawiają „na później”. Tym razem lepiej nie czekać, ale zrobić to w dobrej kolejności: najpierw blokada folderu, potem aktualizacja.

Źródło: WordPress.org – Version 7.1.4, The Hacker News, NHS England Digital – alert CC-4884

Artykuł zredagowany przy pomocy AI.