WordPress 7.0.4 jest już dostępny. Zaledwie kilka dni po publikacji wersji 7.0.3 zespół WordPress udostępnił kolejną aktualizację bezpieczeństwa, która usuwa nową podatność umożliwiającą w określonych warunkach zdalne wykonanie kodu na serwerze.
Tym razem problem dotyczy sposobu obsługi przesyłanych plików na stronach korzystających z Imagick oraz Ghostscript. Luka oznaczona jako CVE-2026-65640 wymaga posiadania konta z uprawnieniami co najmniej na poziomie Author, a więc nie jest podatnością dostępną dla anonimowego użytkownika odwiedzającego stronę. Skutkiem jej wykorzystania może być jednak wykonanie kodu na serwerze, dlatego WordPress rekomenduje niezwłoczną instalację najnowszej wersji.
WordPress 7.0.4 jest aktualizacją bezpieczeństwa. Nie wprowadza nowych funkcji ani zmian w obsłudze CMS-a.
Ważne! Jeżeli Twoja instalacja WordPress obsługuje automatyczne aktualizacje bezpieczeństwa, wersja 7.0.4 powinna zostać pobrana w tle. Warto mimo to zalogować się do panelu i w sekcji Kokpit → Aktualizacje sprawdzić, czy strona rzeczywiście korzysta już z najnowszej wersji.
Jeżeli chcesz zobaczyć, co wydarzyło się kilka dni wcześniej, przeczytaj również: WordPress 7.0.3 już dostępny. Aktualizacja usuwa 12 luk bezpieczeństwa.
Co poprawia WordPress 7.0.4?
Aktualizacja usuwa podatność CVE-2026-65640, związaną z przetwarzaniem plików przesyłanych do WordPressa. Problem występuje na stronach wykorzystujących bibliotekę Imagick wraz z Ghostscript i może zostać wykorzystany przez użytkownika mającego możliwość przesyłania plików do biblioteki mediów.
W typowej instalacji WordPress uprawnienie takie posiada między innymi użytkownik z rolą Author. Atakujący nie może więc po prostu wejść na przypadkową stronę i przesłać złośliwego pliku bez logowania. Jeżeli jednak uzyska dostęp do odpowiedniego konta albo serwis z założenia posiada wielu autorów, odpowiednio przygotowany plik może zostać przekazany do dalszego przetwarzania przez ImageMagick i Ghostscript.
W efekcie możliwe jest Remote Code Execution (RCE), czyli wykonanie kodu na serwerze.
Co właściwie dzieje się z WordPress nie tak?
Problem, który teraz opisujemy pokazuje, że podczas sprawdzania przesyłanego pliku nie wystarczy patrzeć wyłącznie na jego nazwę i rozszerzenie.
Przykładowo: plik mógł wyglądać jak zwykła grafika, np. zdjecie.png, podczas gdy jego rzeczywista zawartość wskazywała na inny format. ImageMagick analizuje zawartość pliku i potrafi obsługiwać znacznie więcej formatów niż JPEG czy PNG, między innymi PostScript, EPS i PDF. W określonych ścieżkach przesyłania danych do WordPressa plik mógł więc przejść początkową kontrolę, a następnie zostać potraktowany przez ImageMagick inaczej, niż sugerowało jego rozszerzenie.
W tym miejscu pojawiał się problem zidentyfikowany przez zespół WordPress. Jeżeli taki plik trafiał następnie do Ghostscript, odpowiednio przygotowana zawartość mogła zostać wykorzystana do wykonania kodu na serwerze.
Jak zespół WordPress naprawił podatność?
Poprawka w WordPress 7.0.4 zmienia sposób, w jaki pliki są przekazywane do biblioteki Imagick.
- WordPress sprawdza teraz rzeczywistą zawartość pliku przed rozpoczęciem jego przetwarzania i blokuje formaty, które mogłyby skierować dane do niebezpiecznych mechanizmów ImageMagick lub Ghostscript.
- Zabezpieczenie obejmuje między innymi pliki PostScript i EPS, nieprawidłowe pliki PDF oraz część sposobów pozwalających wymusić konkretny sposób obsługi pliku.
Zmiana została wprowadzona bezpośrednio w mechanizmie odpowiedzialnym za obsługę obrazów przez Imagick.
To wprawdzie jest niewielka zmiana w kodzie WordPressa, ale jak się okazuje, co widać wyżej, istotna z punktu widzenia bezpieczeństwa.
Które strony WordPress są zagrożone?
Do wykorzystania opisanej podatności musi wystąpić kilka warunków jednocześnie:
- strona korzysta z Imagick i Ghostscript,
- atakujący posiada konto WordPress,
- konto ma uprawnienie do przesyłania plików, np. rolę Author lub wyższą,
- używana wersja WordPressa nie zawiera jeszcze poprawki.
Nie oznacza to więc, że każda nieaktualna strona WordPress zostanie automatycznie przejęta. Niemniej, jeśli korzystasz z usług administratora lub opiekuna strony, sugerujemy skierowanie zapytania, czy wszystko jest w porządku ze stroną oraz czy aktualizacja przebiegła pomyślnie.
Ryzyko jest szczególnie istotne w serwisach wieloautorskich, portalach redakcyjnych oraz innych projektach, w których więcej użytkowników posiada możliwość przesyłania własnych plików. W prostym serwisie firmowym, w którym dostęp administracyjny ma jedna zaufana osoba, droga do wykorzystania podatności jest znacznie trudniejsza.
Nowe błędy są odkrywane niezależnie od harmonogramu rozwoju WordPressa. Jeżeli problem dotyczy bezpieczeństwa i gotowa jest poprawka, zespół projektu może udostępnić kolejne wydanie bez czekania na większą aktualizację funkcjonalną.
Historię poprzedniej aktualizacji opisaliśmy tutaj: WordPress 7.0.3 – aktualizacja usuwa 12 luk bezpieczeństwa.
Co powinien zrobić właściciel strony WordPress?
Najpierw sprawdź numer wersji.
Jeżeli korzystasz z WordPress 7.0.3 lub starszej wersji, przejdź do Kokpit → Aktualizacje i zainstaluj najnowszą dostępną wersję WordPressa. Jeżeli aktualizacje bezpieczeństwa wykonywane są automatycznie, sprawdzenie numeru wersji pozwoli potwierdzić, że cały proces zakończył się prawidłowo.
Przy ręcznej aktualizacji pamiętaj o podstawach:
- wykonaj wcześniej kopię zapasową strony,
- zaktualizuj WordPress Core,
- sprawdź dostępne aktualizacje motywów i wtyczek,
- po zakończeniu sprawdź działanie strony, formularzy i najważniejszych funkcji.
Nie ma potrzeby ponownie opisywać całego procesu krok po kroku. Szczegółową instrukcję znajdziesz w naszym Centrum Pomocy: Jak ręcznie zaktualizować WordPress?.
Przed większymi zmianami warto również posiadać aktualny backup. Zobacz: Jak skonfigurować kopię zapasową WordPress w Softaculous?.
Aktualizacja WordPress 7.x.x i starszych wersji
Uwaga! Problem nie dotyczy wyłącznie gałęzi 7.0. Zespół WordPress przygotował poprawki również dla starszych wersji CMS-a, sięgając aż do gałęzi 4.7. Przykładowo dla WordPress 6.9 poprawiona wersja to 6.9.7, a dla 6.8 — 6.8.8.
WordPress przypomina, że aktywnie wspierana jest wyłącznie najnowsza wersja CMS-a. Poprawki dla starszych gałęzi są udostępniane dodatkowo, aby ograniczyć ryzyko dla instalacji, które nie zostały jeszcze przeniesione na aktualne wydanie.
Jeżeli nie istnieje konkretny powód techniczny, aby pozostać przy starszej wersji, rekomendowanym rozwiązaniem jest aktualizacja do aktualnie wspieranego wydania WordPressa.
W jaki sposób SEOHOST dba o bezpieczeństwo stron WordPress?
Bezpieczeństwo naszych klientów traktujemy priorytetowo.
Po publikacji informacji o nowych podatnościach analizujemy sposób ich wykorzystania oraz możliwości ograniczenia ryzyka na poziomie infrastruktury hostingowej. Tam, gdzie rodzaj ataku pozwala zastosować dodatkowe zabezpieczenia, wykorzystujemy między innymi reguły ModSecurity (WAF), które mogą blokować część podejrzanych żądań zanim trafią one do aplikacji.
Firewall aplikacyjny stanowi dodatkową warstwę ochrony, ale nie usuwa podatności znajdującej się w kodzie CMS-a. W tym przypadku właściwym rozwiązaniem pozostaje instalacja oficjalnej poprawki przygotowanej przez zespół WordPress.
Dlatego rekomendujemy sprawdzenie używanej wersji i aktualizację WordPressa do 7.0.4 lub najnowszej wersji dostępnej dla używanej gałęzi.
W ostatnich tygodniach pojawiło się kilka niezależnych poprawek bezpieczeństwa WordPress Core. To dobry moment, aby sprawdzić nie tylko wersję samego CMS-a, ale także stan wtyczek, motywu i kopii zapasowych — nawet jeśli strona była aktualizowana kilka dni temu.
Komentarze