Bezpieczeństwo WordPressa 2026: Imagick RCE, zdalny JSON, wtyczki z czatu

CVE-2026-65640 to nie „WordPress jest dziurawy”. To Autor plus Imagick plus Ghostscript. Wypadnij z któregokolwiek z trzech i ta ścieżka jest zamknięta. Skanery plików nadal nie widzą następnej klasy: PHP, które robi eval JSON-a właśnie pobranego z sieci.

WordPress 7.0.4 wyszedł 12 sierpnia 2026. To było trzecie wydanie bezpieczeństwa rdzenia w cztery tygodnie (7.0.2 17 lipca, 7.0.3 6 sierpnia). CVE to uwierzytelnione zdalne wykonanie kodu przez plik, który wygląda jak obraz. Zgłosiło je pwn.ai. Łata ogląda zawartość zanim Imagick weźmie plik. Backporty idą do 4.7. Jeśli siedzisz na 6.x, backport jest tą samą klasą poprawki, nie „innym problemem”.

Ten tekst jest o tej ścieżce, o ścieżce JSON, której skaner nie zhaszuje, i o wtyczkach, które z czatu poszły na produkcję. Audyt bezpieczeństwa WordPress to powierzchnia handlowa. Szersze utwardzanie runtime (passkeys, dysk tylko do odczytu, WAF na krawędzi) jest w przewodniku po utwardzaniu. Nie mieszaj tych dwóch rzeczy.

#Imagick, Ghostscript i Author

ImageMagick umie więcej niż JPEG. PostScript, EPS i PDF idą do Ghostscript. WordPress, przez Imagick, wybierał handler po rozszerzeniu. Imagick czytał potem bajty. Plik .png, który jest PostScriptem, trafiał do Ghostscript. To jest CVE-2026-65640 (CVSS 8.8, CWE-434).

Oba warunki muszą być prawdziwe naraz:

1. Imagick i Ghostscript są zainstalowane i używane do mediów.
2. Użytkownik, który może wgrywać (Autor i wyżej), nie jest w pełni zaufany.

Host tylko z GD jest poza tą ścieżką. Imagick bez Ghostscript jest poza tą ścieżką. Upload wyłącznie przez dwóch znanych administratorów to inne ryzyko.

Autor jest ciekawą rolą. Gościnne felietony na portalu branżowym. Agencja, która oddaje klientowi konto „żeby sam publikował”. Stażysta, który „tylko wrzuca zdjęcia produktów”. Generowanie miniaturek odpala się przy uploadzie. Nikt nie otwiera pliku w aplikacji desktopowej.

7.0.4 zmienia WP_Image_Editor_Imagick::load(): ogląda zawartość, odrzuca sygnatury PostScript i EPS, fałszywe PDF, archiwa, które Imagick rozpakowałby, oraz prefiksy handlerów. To jest poprawka rdzenia. Nie zastępuje policy.xml na hoście.

Trzy wydania z lipca i sierpnia to kalendarz, nie jeden worek „RCE WordPressa”:

Traktowanie ich jako jednej awarii gubi warunek AND, od którego zależy, czy zostajesz dziś w nocy.

Metody uploadu, które omijają wp_check_filetype_and_ext, są resztką. Rdzeń mediów używa nowego oglądu. Wtyczka, która zapisuje plik, a potem woła Imagick na ścieżce, nadal może nakarmić Ghostscript. W zipie wtyczki szukaj WP_Image_Editor i surowego Imagick::readImage. Drugie jest dziurą, której łatka rdzenia nie zasłania.

Na polskim sklepie WooCommerce ta resztka siedzi w importerze zdjęć od dostawcy. CSV z URL-ami, cron, zapis do uploads, potem readImage na ścieżce, bo „miniaturka w karcie produktu musi być”. Autor, który wgrywa przez Media, idzie przez nowy inspect. Cron importera nie musi. To nie jest drugi CVE. To jest kod, który łatka 7.0.4 nie czyta.

Gościnny felieton na portalu meblarskim albo spożywczym wygląda niewinnie: copywriterka ma Autora, bo redakcja nie chce dawać administratora. Wgrywa zdjęcie nagłówka. WordPress odpala Imagick. Jeśli Ghostscript jest w systemie, warunek AND jest spełniony, zanim ktokolwiek otworzy plik. Stażyście, który „tylko wrzuca packshoty na kartę produktu”, nikt nie tłumaczy CWE-434. Tłumaczy „wrzuć JPEG”. JPEG, który jest PostScriptem, nadal jest wrzuconym plikiem.

#Ghostscript w policy.xml

To jest wybór operacyjny. Rdzeń teraz ogląda upload. Host nadal decyduje, które kodery ImageMagick w ogóle istnieją.

Na Debianie i Ubuntu plik leży często w /etc/ImageMagick-6/policy.xml albo w drzewie ImageMagick-7. Odmów delegatom, których nie potrzebujesz:

<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="URL" />
<policy domain="coder" rights="none" pattern="HTTPS" />

Wtyczka bezpieczeństwa nie zapisze tego pliku. Wordfence nie zastępuje polityki Ghostscript. WAF widzi multipart/form-data od zalogowanego Autora. Nie widzi biblioteki C po tym, jak PHP przyjął część.

disable_functions dla exec, shell_exec, passthru, system, proc_open to drugi płot. Nie zatrzymuje Ghostscript, jeśli Imagick woła go w procesie. Traktuj to jako przydatne, nie wystarczające.

Wspólne pule PHP-FPM znaczą, że udane RCE to użytkownik puli, często ten sam, co każda inna witryna na koncie. Dlatego Autor na koncie z wieloma witrynami to inna rozmowa niż Autor na pojedynczym VPS. CVE się nie zmienia. Promień rażenia tak.

Najpierw łatka. Potem policy.xml. Potem decyzja, czy Autor w ogóle ma wgrywać.

Miniatury PDF to zwykły sprzeciw. Jeśli redakcja portalu potrzebuje podglądu PDF (uchwała, specyfikacja produktu, załącznik do artykułu), generuj je w workerze, który nie jest publicznym użytkownikiem PHP-FPM, z polityką, która pozwala na PDF tylko w tym workerze. Nie włączaj PDF z powrotem na pudełku, które serwuje wp-admin Autorom. Redakcje, które naprawdę muszą podglądać PDF, już mają potok. Redakcje, które nie muszą, nie powinny dowiadywać się o Ghostscript z advisory CVE.

phpinfo w mu-pluginie na stagingu pokazuje wersję Imagicka bez SSH. Nie zostawiaj phpinfo na produkcji. php -i | grep -i imagick na hoście wystarczy. php -m | grep imagick plus which gs to ta sama para pytań, którą zadajesz w pierwszym tygodniu.

Panel hostingu ze „stroną WordPress jednym kliknięciem” zwykle nie pokazuje policy.xml. Pokazuje „ochronę” i skaner. Skaner nie jest koderem ImageMagick. Jeśli nie umiesz przeczytać policy.xml, nie kontrolujesz tej ścieżki. Albo masz SSH i plik, albo nie masz kontroli, tylko nadzieję, że Imagick nie jest załadowany.

Na koncie z kilkoma witrynami agencji ten sam użytkownik PHP obsługuje sklep klienta, bloga i landing. Udane RCE na blogu z gościnnym Autorem to dostęp do sklepu na tym samym uid. Izolacja per witryna (osobna pula, osobny użytkownik, osobny katalog poza wspólnym sites) jest tu ważniejsza niż kolejna wtyczka skanująca hashe. CVE nie zna granic konta. Pula PHP je zna, albo nie.

#JSON, którego nie ma na dysku

Wtyczki integralności plików porównują PHP z sumami kontrolnymi zipów z wordpress.org. To łapie webshella wrzuconego do wp-content/uploads. Nie łapie:

• zasilania „co nowego”, które wtyczka bierze file_get_contents i interpoluje do eval albo do szablonu z {php}
• zdalnej listy JSON „presetów layoutu” zdekodowanej i podanej resztkom create_function
• sprawdzacza aktualizacji, który odpala phar z CDN dostawcy

Dysk jest czysty. Runtime nie. Konto administratora, które pojawia się we wtorek, powstało z ładunku, którego nigdy nie było w gicie.

Nie mamy publicznego licznika „siedmiu wtyczek”, który byłby nasz do cytowania. Klasa wystarczy: jeśli użyteczne zachowanie wtyczki przychodzi po HTTPS z hosta, którego nie przypinasz, traktuj to jako wejście wykonywalne. Przypnij URL, przypnij hash, albo usuń wtyczkę.

JSON nie jest zły. wp_remote_get plus json_decode plus eskapowane wyjście jest w porządku. Porażka to dekoduj, potem wykonaj.

Timeouty i limity rozmiaru należą do tych żądań. JSON „paczka szablonów” o 20 MB to nie komunikat. To pobranie, którego nie miałeś zamiaru uruchamiać. wp_remote_get z timeout 5 i limitem bajtów, potem json_decode, potem allow-lista kluczy. Cokolwiek innego jest interpreterem.

Hostname dostawcy ma być przypięty. Jeśli wtyczka skleja ścieżkę na bazowy URL z filtra, właściciel witryny z manage_options i tak może wskazać ją na zło. To jest funkcja, dopóki błąd na poziomie Autora albo skradzione ciasteczko nie użyje tej samej opcji. Sprawdzenie capability na ekranie ustawień to nie to samo, co niewykonywanie zdalnych stringów.

Na sklepie, który utrzymujemy, ta klasa siedziała we wtyczce „powiadomień od dostawcy motywu”. Kokpit pokazywał kafel „nowości”. PHP na dysku zgadzało się z wordpress.org. We wtorek był nowy administrator, którego nikt nie klikał. Skaner plików był zielony, bo nie miał czego porównać: ładunek przyszedł w JSON i umarł w pamięci po eval. Git tego nie widział. Kopia zapasowa plików też nie.

Szukaj w zipie: eval(, assert(, create_function, unserialize(, file_get_contents z http, wp_remote_get bez przypiętego hosta, interpolacja do $wpdb->query. Godzina. Skaner haszy tego nie zrobi, bo nie ma czego zhaszować, zanim runtime nie pobierze dokumentu.

Motyw kupiony z marketplace, który „ciągnie dema layoutów” z CDN, należy do tej samej klasy, nawet jeśli nikt nie nazwał tego wtyczką. Preset JSON, który po dekodowaniu ląduje w eval albo w create_function, jest interpreterem. Przypięcie hosta i hasha, albo wyłączenie kafelka „nowości”, zamyka to bez czekania na advisory z nazwą marki. Marki i tak się zmieniają. Klasa nie.

#Vibe-coding na produkcji

Czat, który emituje zip wtyczki, jest szybszy niż przegląd. Produkcja nie obchodzi szybciej.

Co nadal otwieramy w tych zipach:

• $wpdb->query("… $niesanityzowane …") bez $wpdb->prepare
• file_get_contents URL-a dostawcy na admin_init
• update_option całego bloba JSON z POST bez sprawdzenia capability poza read
• CSS wylewany inline, co jest problemem vitals, nie RCE, i i tak wychodzi, bo nikt nie spojrzał

Przewodnik po utwardzaniu to runtime. Ta sekcja to dostawa nowego PHP. Lockfile composera plus przeczytanie eval i zdalnych pobrań, zanim wtyczka wejdzie na produkcję. Autoinstalacja z kokpitu jest tym, jak kod z vibe-codingu omija to czytanie.

Autorzy, którzy mogą wgrywać, są też warunkiem CVE-2026-65640. Wtyczka formularza z czatu, która nadaje Autora „klientom przysyłającym historie”, odtwarza ścieżkę Imagicka celowo.

Composer nie uratuje, jeśli zip nigdy do composera nie wszedł. „Dodaj wtyczkę” w kokpicie to ramp na vibe-code. Produkcja nie powinna tego pozwalać. Staging może, jeśli staging nie sięga Imagick plus Ghostscript i nie sięga żywej bazy. Widzieliśmy „testową” wtyczkę na klonie, który nadal miał produkcyjne stałe wp-config. To nie jest CVE. To jest klon.

Przegląd to grep, nie ceremonia: eval, assert(, create_function, unserialize(, file_get_contents z http, $wpdb->query z interpolacją, update_option z $_POST bez manage_options. Godzina. Czat tego nie zrobi.

Martwy CSS i wyciek pamięci po pętli WP_Query bez wp_reset_postdata nie są RCE. Są powodem, dla którego ten sam zip i tak nie powinien iść na sklep przed szczytem sezonu. Bezpieczeństwo i vitals spotykają się w tym samym miejscu: nikt nie przeczytał pliku. Jeśli nie przeczytałeś SQL, nie przeczytałeś też admin_init.

Prompt „zrób wtyczkę, która importuje opisy z arkusza” produkuje działające demo i trzy dziury naraz, bo model optymalizuje pod „działa w kokpicie”. Capability, nonce, prepare i brak zdalnego eval nie są w prompcie, więc nie są w zipie. Przegląd nie jest brakiem zaufania do modelu. Jest brakiem zaufania do zipa, którego nikt nie otworzył.

#Vibe-coding wtyczki i wp-admin na produkcji

To jest ścieżka, którą w polskich agencjach i sklepach widzimy częściej niż advisory CVE. Nie hosting. Kokpit.

Piątek, 16:40. Klient na umowie utrzymaniowej dzwoni, że „mamy importer opisów, wgrajcie ZIP”. ZIP przyszedł z czatu. Nazwa w stylu ai-product-importer.zip. README ma jedno zdanie. Lockfile composera nie istnieje, bo zip nigdy nie był paczką composera. Na produkcji nie ma gita. Jest wp-admin.

Ścieżka jest wtedy zawsze ta sama: Wtyczki, Dodaj nową, Wgraj wtyczkę. WordPress przyjmuje zip, rozpakowuje do wp-content/plugins, aktywuje. W ciągu minuty na produkcji jest nowy PHP, którego nikt nie grepował pod eval i $wpdb->query. To nie jest „wdrożenie”. To jest piątkowy klik.

W zipie, który otworzyliśmy po fakcie, siedziały trzy rzeczy naraz:

1. Na admin_init file_get_contents do URL-a „changelogu” i interpolacja do eval. Dysk czysty, runtime nie.
2. $wpdb->query z nazwą produktu z POST, bez prepare. Formularz importera był dostępny dla roli Autora, bo „dostawcy przysyłają opisy”.
3. Upload zdjęć produktu przez tę samą rolę. Autor, Imagick, Ghostscript. Warunek CVE-2026-65640 zrobiony z rozmysłem, tylko nikt tak tego nie nazwał.

Nikt nie dał dostawcom administratora. Dał im Autora, bo w macierzy ról WordPressa Autor „wgrywa pliki do swoich wpisów”. Na sklepie „wpis” to produkt, a plik to JPEG od hurtowni. Miniaturka liczy się przy uploadzie. Ghostscript nie pyta, czy to felieton, czy karta produktu.

Druga, równie częsta wersja: portal z gościnnymi felietonami. Copywriterka ma Autora, bo publikuje. Agencja ma administratora. Klient ma administratora, „bo to jego strona”. W piątek marketing prosi czat o „małą wtyczkę do spisu autorów gościnnych”. Zip idzie przez ten sam ekran Dodaj wtyczkę. Wtyczka nadaje upload_files każdemu z read, bo prompt nie wspomniał o rolach, a model wziął najkrótszą ścieżkę, żeby demo działało. W poniedziałek Autorzy gościnni wgrywają obrazy. To jest CVE-2026-65640 plus kod, którego nie ma w composerze.

Trzecia: freelancer na umowie o dzieło. Nie ma dostępu do stagingu. Ma hasło administratora, bo „inaczej nie wgra motywu”. Zip z czatu ląduje na produkcji, bo staging „i tak jest nieaktualny”. Po weekendzie nikt nie umie powiedzieć, który plik PHP jest nowy. Nie ma composer.lock. Nie ma PR. Jest katalog plugins i pamięć, że „to ten importer”.

Composer nie jest tu religią. Jest spisem. Jeśli zip nie wszedł do lockfile, nie umiesz powiedzieć w poniedziałek, co działa. Skaner plików porówna PHP z wordpress.org i powie, że importera tam nie ma, więc nie ma sumy. To prawda. To nie jest ochrona. To jest ślepy punkt, który kokpit „Dodaj wtyczkę” produkuje za każdym razem.

Kontrola, która zamyka tę ścieżkę, nie jest kolejną wtyczką bezpieczeństwa. Jest decyzją, że produkcja nie instaluje z kokpitu. Staging może przyjąć zip, jeśli staging nie ma Imagicka z Ghostscript i nie ma produkcyjnego wp-config. Potem grep. Potem lockfile. Potem obraz albo rsync. Piątkowy klik w wp-admin ten porządek omija w trzydzieści sekund.

Rola Autora zostaje, jeśli ktoś naprawdę publikuje. Zostaje bez upload_files, jeśli pisze szkice, a zdjęcia wgrywa redaktor, któremu ufasz. Zostaje z upload_files, jeśli wiesz, że 7.0.4 jest na miejscu, policy.xml odmawia PS, EPS, PDF, URL i HTTPS, a ten człowiek nie instaluje wtyczek. Te trzy rzeczy są osobne. Piątkowy zip z czatu zwykle psuje wszystkie trzy naraz: nowy PHP, nowa rola, stary Imagick.

Umowa utrzymaniowa, którą agencja podpisuje ze sklepem, często milczy o kokpicie. Klient ma administratora, „bo to jego strona”. Agencja ma administratora, „bo utrzymuje”. Freelancer od mailingu ma administratora, „bo musi wgrać formularz”. Trzy hasła, jeden ekran Dodaj wtyczkę, zero lockfile. W piątek którykolwiek z trzech może wgrać zip z czatu. W poniedziałek nikt nie umie powiedzieć, który.

To, czego brakuje, nie jest narzędziem. Jest zakazem instalacji z kokpitu na produkcji i jednym miejscem, w którym zip w ogóle wchodzi: staging, grep, lockfile, potem wdrożenie. Jeśli staging ma produkcyjny wp-config i produkcyjny Imagick z Ghostscript, staging jest produkcją z inną domeną. Klon bez osobnej bazy i bez osobnej polityki koderów nie jest kwarantanną.

Copywriterka z Autorem nie jest problemem, jeśli nie wgrywa i nie instaluje. Dostawca packshotów z Autorem i upload_files jest problemem, jeśli 7.0.4 albo policy.xml nie stoją. Piątkowy zip z czatu zwykle dokłada trzeci problem: nowy PHP, który na admin_init ciągnie JSON. Trzy klasy w jednym kliknięciu. Skaner haszy jedną, i to tylko jeśli plik leży na dysku.

Grep, który miał być przed wgraniem, zajmuje godzinę i łapie to, czego czat nie napisze sam z siebie:

• eval, assert(, create_function, preg_replace z /e
• file_get_contents albo wp_remote_get do hosta spoza allow-listy
• $wpdb->query z interpolacją, $_GET / $_POST w SQL
• update_option albo add_user z żądania bez manage_options i bez nonce
• surowe Imagick::readImage poza WP_Image_Editor

Jeśli zip nie przechodzi tej listy, nie idzie na produkcję. Jeśli nie ma kto tej listy odpalić, zip nie idzie na produkcję. Tempo czatu nie jest argumentem. Argumentem jest lockfile, którego po piątkowym kliknięciu nie ma.

Nie cytujemy liczby „siedmiu wtyczek”. Cytujemy klasę, którą da się odtworzyć w każdej agencji, która oddaje klientowi ZIP i hasło do wp-admin. To nie jest luka rdzenia. To jest dostawa PHP przez kokpit, w piątek, bez lockfile.

#Co zmienić w tym tygodniu

1. wp core version. Jeśli jesteś poniżej 7.0.4 na linii 7.0, albo bez backportu na 6.x / 4.7+, łataj.
2. php -m | grep imagick i czy istnieje gs. Jeśli oba, policy.xml dzisiaj.
3. Lista wtyczek: cokolwiek, co ładuje w kokpicie „zasilanie” albo „szablony” od dostawcy. Otwórz PHP. Jeśli robi eval, wtyczka spada.
4. Lista ról: ilu Autorów może wgrywać. Zetnij tych, którzy piszą tylko szkice.
5. Logi poza hostem, z przewodnika po utwardzaniu. RCE, które ściera auth.log na tym samym dysku, to zgadywanie, nie incydent.
6. Wyłącz na produkcji „Dodaj wtyczkę”. Zip z czatu ma wejść przez staging i grep, albo nie wejść.

Nie instaluj drugiego skanera jako odpowiedzi na delegata biblioteki. Skanery haszują pliki.

Jeśli w tym tygodniu masz czas tylko na trzy ruchy: łatka 7.0.4, policy.xml, wyłączony ekran Dodaj wtyczkę na produkcji. Reszta (role, grep JSON, logi poza hostem) jest na ten sam tydzień, nie na „kiedyś”. Piątkowy zip nie poczeka na kwartalny audyt.

#Audyt i lektura

Audyt bezpieczeństwa to Imagick i Ghostscript, Autor, zdalny JSON i zip wtyczki, którego nie przeczytałeś. Passkeys, dysk tylko do odczytu i WAF na krawędzi zostają w zaawansowanym utwardzaniu.

CVE-2026-65640 jest jedną ścieżką. policy.xml jest kontrolą, która nadal ma znaczenie, gdy wpłynie następna podobna luka. JSON, który się wykonuje, jest inną ścieżką. Zip z czatu wgrany przez wp-admin jest trzecią. Strona wtyczki, która pisze „chronione”, nie adresuje żadnej z nich sama z siebie.

#Podsumowanie

Trzy wydania bezpieczeństwa rdzenia w cztery tygodnie to kadencja, nie slogan. Sierpniowe potrzebuje Autora, Imagicka i Ghostscript. Załataj rdzeń. Odmów koderom Ghostscript na hoście. Zatrzymaj eval zdalnego JSON. Trzymaj wtyczki wyeksportowane z czatu z dala od produkcji, dopóki ktoś ich nie przeczyta. Jeśli chcesz to sprawdzić, pisz z wersją PHP, czy Imagick jest załadowany, i ilu Autorów wgrywa.

Następna podobna luka będzie miała nowy numer CVE. policy.xml, brak eval zdalnego JSON i brak instalacji wtyczek z kokpitu na produkcji nadal będą listą. Czwarty skaner nie.