WordPress 7.0.4: łatka na prawie dziesięcioletnią lukę w obsłudze obrazków

WordPress 7.0.4 łata prawie dziesięcioletnią dziurę w obsłudze obrazków

12 sierpnia 2026 WordPress.org wydał wersję 7.0.4 — wydanie w całości poświęcone bezpieczeństwu, które łata jedną lukę: CVE-2026-65640. Błąd pozwala zalogowanemu autorowi (rola Author lub wyższa) uruchomić dowolny kod na serwerze przez zwykłe wgranie pliku „obrazka” w bibliotece mediów. Problem siedział w kodzie WordPressa od wersji 4.7, czyli praktycznie dekadę.

Mechanizm jest prosty do opisania, trudniejszy do wykrycia. Plik z rozszerzeniem .png, który w środku zawiera nie dane obrazu, lecz instrukcje PostScript, przechodzi przez podstawową walidację uploadu. Jeśli serwer używa do obróbki obrazów biblioteki Imagick zamiast domyślnego GD, plik trafia do ImageMagick, która do wyrenderowania PostScriptu, EPS-u czy PDF-u woła zewnętrzny program Ghostscript. Ghostscript ma długą historię dawania się namówić do wykonania poleceń, których wykonywać nie powinien — to ta sama rodzina błędów, która pod nazwą „ImageTragick” narobiła zamieszania dekadę temu. Efekt: plik, który wygląda jak niewinny PNG, po stronie serwera wykonuje się jak program.

Dla kogoś, kto prowadzi jednoosobowego bloga z jednym kontem administratora, to wiadomość, którą można odhaczyć aktualizacją i iść dalej — atak wymaga zalogowanego konta na poziomie Autora, więc nie jest to dziura otwarta na cały internet. Inaczej wygląda to na stronach z wieloma autorami, portalach z kontami gościnnymi, serwisach członkowskich albo witrynach klientów, gdzie kontrahenci czy freelancerzy dostają konto Author, żeby wgrywać własne wpisy. Tam ryzyko jest realne, bo konto na tym poziomie jest znacznie łatwiej zdobyć albo skompromitować niż konto administratora.

Co warto sprawdzić w takiej sytuacji? Po pierwsze — aktualizacja do 7.0.4 powinna pójść od razu, najlepiej automatycznie; to wydanie zabezpieczające i nie warto na nie czekać. Po drugie — jeśli nie wiadomo, czy serwer używa Imagick czy GD, odpowiedź znajduje się w Narzędzia → Zdrowie strony → Informacje, w sekcji obsługi mediów, albo trzeba zapytać hosting wprost — to jeden z tych szczegółów infrastruktury, które rzadko ktoś sprawdza, dopóki coś nie pójdzie nie tak (o tym, jak dokładnie sprawdzamy takie rzeczy u hostingów, piszemy przy okazji naszych testów). Po trzecie — warto przejrzeć listę kont z rolą Author i wyżej i usunąć te, które od dawna nie są używane. To niewielki koszt, a realnie zmniejsza powierzchnię ataku.

To kolejne przypomnienie, że najstarszy kod w rdzeniu bywa najmniej przetestowany pod kątem nowych scenariuszy ataku — luka czekała blisko dekadę, zanim ktoś ją znalazł i zgłosił odpowiedzialnie. Warto też pamiętać, że sama aktualizacja WordPressa nie zastąpi solidnie skonfigurowanego serwera — to, jak hosting radzi sobie z bezpieczeństwem i aktualizacjami, sprawdzamy regularnie i publikujemy w rankingu na głównej stronie.