CVE-2026-65640 heißt nicht "WordPress ist unsicher". Es heißt Author plus Imagick plus Ghostscript. Fehlt eine der drei Bedingungen, ist dieser Pfad zu. Datei-Scanner verpassen die nächste Klasse weiter: PHP, das JSON evalt, das es gerade heruntergeladen hat.
WordPress 7.0.4 ist am 12. August 2026 rausgekommen. Es war das dritte Core-Sicherheitsrelease in vier Wochen (7.0.2 am 17. Juli, 7.0.3 am 6. August). Die CVE ist authentifizierte Remote Code Execution über eine Datei, die wie ein Bild aussieht. pwn.ai hat sie gemeldet. Der Patch prüft den Inhalt, bevor Imagick greift. Backports gehen bis 4.7.
Dieser Beitrag ist dieser Pfad, der JSON-Pfad, den die Scanner nicht hashen, und Plugins die vom Chat auf Produktion gewandert sind. Das WordPress-Sicherheitsaudit ist die kommerzielle Fläche. Breitere Runtime-Härtung (Passkeys, schreibgeschützte Platte, Edge-WAF) steht im Härtungs-Guide. Die beiden nicht mischen.
Imagick, Ghostscript und Author
ImageMagick kann mehr als JPEG. PostScript, EPS, PDF gehen an Ghostscript. WordPress hat über Imagick den Handler früher an der Endung festgemacht. Imagick hat danach die Bytes gelesen. Ein .png, das PostScript ist, hat Ghostscript erreicht. Das ist CVE-2026-65640 (CVSS 8.8, CWE-434).
Beide Bedingungen müssen stimmen:
- Imagick und Ghostscript sind installiert und für Medien im Einsatz.
- Ein Nutzer, der hochladen kann (Author und höher), ist nicht vollständig vertraut.
Hosts nur mit GD liegen außerhalb dieses Pfads. Imagick ohne Ghostscript liegt außerhalb dieses Pfads. Uploads nur durch zwei Administratoren, die Sie kennen, ist ein anderes Risiko.
Author ist die interessante Rolle. Gastblogs, Agenturen, “der Praktikant veröffentlicht”. Die Thumbnail-Erzeugung läuft beim Upload. Niemand öffnet die Datei in einer Desktop-App.
Im deutschen Mittelstand ist genau diese UND-Kombination häufig, ohne dass jemand sie so benannt hat. Ein B2B-Shop lädt Bedienungsanleitungen als PDF in die Mediathek. Der Hoster hat Ghostscript angehakt, damit WordPress daraus eine Vorschau baut. Dieselbe Installation hat Imagick, weil JPEG-Kompression und Zuschnitt “schon immer so” liefen. Dieselbe Installation hat drei Authors: die Texterin der Agentur, einen Gastautor fürs Fachmagazin, einen Werkstudenten der Produkttexte pflegt. Keiner von denen soll Root sein. Alle drei dürfen png hochladen. Der Core hat bis 7.0.4 den Handler an .png festgemacht. Die Bytes waren PostScript. Ghostscript hat sie bekommen.
Das ist kein exotischer Stack. Das ist IONOS-Shared, All-Inkl, ein Mittwald-Tarif oder ein Hetzner-Managed-Kiste, auf der PDF-Vorschauen irgendwann mal “nice to have” waren. Wer denkt “wir machen nur Fotos”, hat Ghostscript trotzdem, sobald irgendwer jemals ein Datenblatt hochgeladen hat und der Hoster den Delegat nicht wieder abgeschaltet hat.
7.0.4 ändert WP_Image_Editor_Imagick::load(). Die Funktion sieht jetzt auf den Inhalt, lehnt PostScript- und EPS-Signaturen ab, unechte PDFs, Archive die Imagick entpacken würde, und Handler-Präfixe. Das ist der Core-Fix. Er ersetzt nicht policy.xml auf dem Host.
GD-only ist die saubere Antwort, wenn Sie keine PDF-Vorschau brauchen. Viele deutsche Shops brauchen sie. Dann bleibt Imagick, und Ghostscript muss in der policy.xml sterben, nicht “im Security-Plugin deaktiviert” werden. Ein Plugin schreibt /etc/ImageMagick-6/policy.xml nicht.
Contributor ohne upload_files ist die billigere Rollenwahl, wenn die Person nur Entwürfe schreibt. Author bleibt korrekt für Leute, die wirklich Medien an den Beitrag hängen. Die Capability ist dann bewusst. “Alle Redakteure bekommen Author, weil sonst das Beitragsbild fehlt” ist die UND-Bedingung in Prosa.
Headless nimmt diesen Pfad nicht weg. Ein Storefront in Astro oder einem anderen SSG liefert anonymes PHP nicht mehr aus dem Katalog. wp-admin und der Media-Upload laufen weiter in PHP. Authors laden weiter hoch. Die Imagick-Kette sitzt hinter dem Login, nicht hinter der Startseite. policy.xml zählt auf einem Headless-Origin genauso.
Ghostscript in der policy.xml, kein Security-Plugin
Das ist die Betriebsentscheidung. Core prüft den Upload jetzt. Der Host entscheidet weiter, welche ImageMagick-Coder überhaupt existieren.
Auf Debian und Ubuntu liegt die Datei oft unter /etc/ImageMagick-6/policy.xml oder ImageMagick-7. Die Delegaten, die Sie nicht brauchen, verweigern:
<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" />Ein Security-Plugin kann diese Datei nicht schreiben. Wordfence ersetzt keine Ghostscript-Policy. Eine WAF sieht multipart/form-data von einem eingeloggten Author. Sie sieht nicht die C-Bibliothek, nachdem PHP den Teil angenommen hat.
disable_functions für exec, shell_exec, passthru, system, proc_open ist ein zweiter Zaun. Er stoppt Ghostscript nicht, wenn Imagick es im selben Prozess ruft. Nützlich, nicht ausreichend.
Geteilte PHP-FPM-Pools heißen: eine erfolgreiche RCE ist der Pool-User, oft derselbe User wie jede andere Site auf dem Konto. Deshalb ist Author auf einer Shared-Kiste ein anderes Gespräch als Author auf einem Single-Tenant-VPS. Die CVE ändert sich nicht. Der Blast-Radius ändert sich.
Auf IONOS- oder All-Inkl-Konten mit fünf WordPress-Installationen unter einem SSH-User ist der Radius das ganze Konto. Der Gastautor schreibt auf der Magazin-Site. Die Shop-Site liegt daneben, gleicher User, gleiches uploads, oft gleiches wp-config Muster. Ein PostScript-Upload auf der Magazin-Site ist dann kein Magazin-Vorfall. Das ist der Shop, die Kundenliste, der Cron.
Managed-WordPress-Hoster in DE (Mittwald, RAIDBOXES, ähnliche Panels) lassen policy.xml oft nicht anfassen. Dann ist der Ticket-Text an den Hoster der Control, nicht eine Plugin-Checkbox. Entweder der Hoster setzt die Coder auf none, oder Imagick fliegt, oder Ghostscript fliegt. “Wir haben Wordfence an” ist in diesem Ticket keine Antwort.
PDF-Vorschau, die das Business wirklich braucht, gehört nicht in denselben Imagick-Prozess wie Author-Uploads. Ein interner Job, der PDFs auf einem Host ohne öffentliche Authors rendert, ist ein anderes Design. Ein öffentlicher Author, der “mal eben das Datenblatt” in dieselbe Mediathek legt, in der Imagick Ghostscript rufen kann, ist CVE-2026-65640 in der Betriebsanleitung.
Zuerst patchen. Dann policy.xml. Dann entscheiden, ob Author überhaupt hochladen soll.
JSON, das die Platte nicht berührt
Datei-Integritäts-Plugins vergleichen PHP mit den Zip-Prüfsummen von wordpress.org. Das fängt eine Webshell in wp-content/uploads. Es fängt nicht:
- einen “What’s new”-Feed, den das Plugin per
file_get_contentsholt und dann inevalinterpoliert oder in ein Template mit{php} - eine entfernte JSON-Liste von “Layout-Presets”, dekodiert und an
create_function-Reste übergeben - einen Update-Checker, der ein Phar von einem Vendor-CDN ausführt
Die Platte ist sauber. Die Runtime ist es nicht. Der Admin-User, der am Dienstag auftaucht, ist von einer Fracht erzeugt worden, die nie in Git lag.
Wir haben keine öffentliche Zahl “sieben Plugins”, die wir zitieren dürften. Die Klasse reicht: wenn das nützliche Verhalten des Plugins über HTTPS von einem Host kommt, den Sie nicht pinnen, behandeln Sie es als ausführbare Eingabe. URL pinnen, Hash pinnen, oder das Plugin entfernen.
JSON ist nicht böse. wp_remote_get plus json_decode plus escaped Output ist in Ordnung. Der Bruch ist decode, dann execute.
Was in Reviews von Plugin-PHP immer wieder steht, ohne dass daraus eine Plugin-Zählung wird:
$feed = file_get_contents( $vendor_notices_url );
$data = json_decode( $feed, true );
eval( $data['snippet'] );Die Datei notices.php im Plugin-Zip hat denselben SHA, den wordpress.org publiziert. Wordfence, iThemes, der Host-Scanner, alle drei sind grün. Der snippet kam heute Morgen. Er hat wp_insert_user mit role=administrator ausgeführt. Dienstag früh liegt ein Konto in wp_users, das niemand angelegt hat. Das Access-Log auf derselben Box können Sie danach nicht mehr als Beweis lesen, wenn die Fracht Logs rotiert hat. Deshalb stehen Logs außerhalb der Box im Härtungs-Guide, nicht in diesem Beitrag.
Pin heißt konkret: feste URL, TLS, ein erwarteter Hash des Dokuments, Timeout, Größenlimit, kein eval, kein assert, kein create_function, kein dynamisches include aus dem JSON. HTML aus dem Feed, wenn es wirklich HTML sein muss, durch wp_kses mit erlaubter Tag-Liste. Zahlen und Strings ausgeben, nicht ausführen.
Ein Plugin, das “Templates von unserm CDN” als Feature verkauft, ist diese Klasse mit Marketing drumherum. Der CDN-Host ist nicht Ihre origin. Ein kompromittiertes Vendor-Konto ändert Ihr PHP nicht. Es ändert das JSON. Der Scanner bleibt grün.
Dasselbe Muster sitzt in Update-Checkern, die ein Phar laden, statt den wordpress.org-Update-Pfad zu nutzen. Phar ist ausführbar. Ein Vendor-CDN, das Sie nicht pinnen, ist ein zweiter Origin für PHP. Composer-Lockfile plus composer audit ist die Antwort für eigenen Code. Für ein Plugin aus dem Directory ist die Antwort: den PHP-Pfad lesen, bevor es auf Produktion darf, und jeden Remote-Fetch behandeln wie eine Eingabe.
Bewertungs-Widgets und das JSON, das eval wird
Deutsche Shops laden Sterne, Siegel und “Kundenstimmen” oft als Remote-JSON. Der Datei-Scanner bleibt grün. Das ist derselbe decode-then-execute-Pfad, nur mit einem Widget das im Header hängt, nicht mit einem “What’s new” im wp-admin.
Die Fläche sieht harmlos aus. Produktlisting, 4,7 von 5 aus 1.843 Bewertungen, ein gelbes Sternchen, ein Snippet das “Bewertungen” in den Rich-Result-Kandidaten schiebt. Das Plugin auf der Platte ist das Zip von wordpress.org. Die Zahl, das HTML des Badges, oft auch ein “Layout-Preset” für die Produktkarte, kommen zur Laufzeit von einem Host, den der Vendor betreibt. ShopVote, ProvenExpert, eKomi, das Google-Kundenrezensionen-Badge, ein selbst gebautes “Sterne im Grid”-Plugin: die Marke ist hier egal. Die Klasse ist ein JSON-Dokument, das PHP liest, und danach nicht nur anzeigt.
Was wir in solchen Zips lesen, ohne eine Zählung draus zu machen:
- ein Feld
badge_htmlodersnippet, das 1:1 inechogeht, oft ohnewp_kses - ein Feld
template, das durchevaloder durch einen Mini-Parser mit{php}läuft, “damit das Layout flexibel bleibt” - ein Cron, der denselben JSON-Blob in
wp_optionsschreibt, und ein Template dasextract()darauf laufen lässt - ein
admin_init-Fetch ohne Capability-Check überreadhinaus, der bei jedem wp-admin-Hit den Vendor anfasst
Die Platte ändert sich nicht, wenn der Vendor-Feed am Montag ein zusätzliches Key bekommt. Der Scanner hashed reviews-widget.php. Das File ist identisch. Dienstag liegt ein Administrator in der Benutzerliste, oder im Footer hängt ein Script-Tag das gestern nicht da war, oder wp_remote_get läuft gegen eine URL die das JSON selbst mitgeliefert hat.
Ein Werkzeug-Shop, den wir so gelesen haben, hatte genau dieses Header-Widget. Die Sterne kamen aus einem JSON-Endpoint. Das Plugin interpolierte badge_template. Eine Woche war das Template HTML mit einem Stern. Die nächste Woche war es HTML plus ein kurzes PHP-Fragment, weil der Vendor “dynamische Snippets” ausgerollt hatte und das Plugin das Feld schon immer durch einen unsicheren Pfad jagte. Die Prüfsumme auf Disk war unverändert. Das ist Remote-Poisoning in einem deutschen Checkout-Kontext, nicht in einem abstrakten Feed.
Google-Kundenrezensionen als reines Display (Script-Tag, Merchant-Center, kein PHP-eval) ist eine andere Klasse. Gefährlich wird es, sobald Ihr PHP das Dokument dekodiert und ausführt. Ein Badge das der Browser von Google lädt, ist XSS- und Privacy-Arbeit. Ein Badge das PHP evalt, ist RCE-Arbeit. Die beiden nicht in denselben Satz stecken.
Kontrolle, die hier zählt:
- Den Fetch durch den eigenen Origin proxien oder die URL fest eintragen, nicht aus dem JSON selbst lesen.
- Den Hash des Dokuments pinnen, oder das Dokument im Deploy mitliefern, wenn sich Sterne nicht jede Minute ändern müssen.
- Jedes HTML-Feld durch
wp_kses. Keineval. Kein{php}im Template-String. - Den Cron auf einen User ohne
install_pluginsbeschränken.admin_initplusfile_get_contentsauf einen Vendor ist ein unnötiger Fetch in jedem Backend-Hit. - Sterne, die nur angezeigt werden, als Zahl und Text behandeln. Nicht als Programm.
Ein intern gebautes Zähl-Plugin, weil “das SaaS-Widget zu teuer war”, rutscht oft in denselben Pfad. Der Chat liefert ein Zip, das JSON holt und interpoliert. Das steht im nächsten Abschnitt. Der Punkt hier: der deutsche Shop hat diese Fläche schon, bevor jemand vibe-coded. Sie hängt im Header, sie konvertiert, und sie ist für Datei-Scanner unsichtbar.
Checkout-Buttons und Versand-Widgets sind ein anderes Thema (Storefront, nicht eval). Hier geht es um das JSON, das PHP zur Laufzeit zum Programm macht. Wenn das Widget nur Markup ausgibt das Sie escapen, bleibt es Display. Wenn das Widget Code aus dem Feed laufen lässt, ist der Scanner das falsche Werkzeug.
Vibe-codierte Plugins auf Produktion
Ein Chat, der ein Plugin-Zip ausgibt, ist schneller als ein Review. Produktion interessiert sich nicht für Tempo.
Was wir in diesen Zips weiter öffnen:
$wpdb->query("… $unsanitised …")ohne$wpdb->preparefile_get_contentseiner Vendor-URL aufadmin_initupdate_optioneines ganzen JSON-Blobs aus POST ohne Capability-Check überreadhinaus- CSS inline gekippt, ein Vitals-Problem, keine RCE, und es kommt trotzdem mit, weil niemand geguckt hat
Der Härtungs-Guide ist die Runtime. Dieser Abschnitt ist die Zufuhr von neuem PHP. Composer-Lockfile plus ein Read von eval und Remote-Fetches, bevor das Plugin auf Produktion darf. Auto-Install aus dem Dashboard ist der Weg, auf dem vibe-codierter Code diesen Read überspringt.
Authors die hochladen können, sind auch die Bedingung von CVE-2026-65640. Ein vibe-codiertes Formular-Plugin, das Author an “Kunden die Geschichten schicken” vergibt, baut den Imagick-Pfad absichtlich nach.
Der deutsche Fall, den wir wiederholt sehen, ist nicht “die Agentur hat den Core geforkt”. Es ist der Werkstudent mit Cursor, dem das Sterne-SaaS zu teuer vorkam, und der in einem Nachmittag ein “Bewertungszähler”-Plugin gebaut hat. Das Zip hängt unter wp-content/plugins/sternchen. Es holt JSON, schreibt eine Option, gibt HTML aus. Capability-Check ist is_user_logged_in(). SQL ist String-Interpolation, weil der Chat $wpdb->prepare in Beispiel 2 erwähnt hat und Beispiel 1 kopiert wurde. Upload-Pfad für “CSV der Bewertungen” prüft die Endung, nicht den Inhalt. An dem Punkt haben Sie zwei der drei Klassen dieses Beitrags in einem Plugin: Remote-JSON und einen Author-ähnlichen Upload, plus unvorbereitetes SQL.
Was vor Produktion gelesen werden muss, ist kurz und konkret:
rg -n "eval\(|assert\(|create_function\(|unserialize\(|file_get_contents\s*\(\s*['\"]https?|wp_remote_get|\\$wpdb->query\s*\(\s*[\"']" wp-content/plugins/neuTreffer sind nicht automatisch ein Stopp. Treffer sind die Stellen, an denen ein Mensch die Eingabe nachweist: Capability, Nonce, prepare, wp_kses, gepinnte URL. Null Treffer plus ein Plugin das “Templates vom CDN” bewirbt, heißt dass der Fetch anders geschrieben ist (curl, fopen, include einer Remote-URL). Dann diese Pfade lesen.
Auto-Install aus wp-admin überspringt genau diesen Read. “Muss schnell auf Staging” ist der Satz, nach dem das Zip auf Produktion liegt, weil Staging und Produktion denselben Plugin-Ordner teilen. Getrennte Origins, Composer oder ein Deploy aus Git, und der Chat-Export landet in einem PR. Nicht in wp-content/plugins über das Dashboard.
CSS das der Chat inline in wp_head kippt, ist kein RCE. Es ist trotzdem ein Ship-Fehler. LCP auf Produktseiten mit einem 40-KB-Block ungenutzter Selektoren ist der sichtbare Teil. Der unsichtbare Teil ist: niemand hat die Datei gelesen, also hat niemand eval gesehen, das drei Zeilen tiefer steht.
Ein Verzeichnis-Listing ersetzt den Read nicht. Es heißt, dass jemand irgendwann eine Checkliste gegen eine Version laufen ließ. Es heißt nicht, dass Ihr Fork, Ihr Chat-Zip oder das Remote-JSON von heute in dieser Checkliste standen.
Was diese Woche wirklich ändert
wp core version. Unter 7.0.4 auf der 7.0-Linie, oder ohne Backport auf 6.x / 4.7+, patchen.php -m | grep imagickund obgsexistiert. Wenn beides, heute policy.xml. Wenn der Hoster die Datei sperrt, Ticket mit den fünf Coder-Zeilen, nicht Plugin-Installation.- Plugin-Liste: alles was ein Dashboard-”Feed” oder “Templates” vom Vendor lädt. PHP öffnen. Wenn es evalt, fliegt es. Bewertungs-Widgets zählen hier, nicht nur Admin-Notices.
- Rollenliste: wie viele Authors hochladen können. Die, die nur Entwürfe schreiben, auf Contributor ohne
upload_files. Gastautoren des Magazins zuerst. - Logs von der Box, aus dem Härtungs-Guide. Eine RCE die
auth.logauf derselben Platte wischt, ist eine Vermutung, kein Vorfall.
Kein zweites Scanner-Plugin als Antwort auf einen Library-Delegat. Scanner hashen Dateien.
Konkret auf einem üblichen DE-Host:
wp core version
php -m | grep -i imagick
command -v gs
wp role list
wp user list --role=author --fields=ID,user_login,user_emailWenn Imagick und gs beide da sind, die policy.xml prüfen oder den Hoster fragen. Wenn Authors existieren die seit Monaten nicht publiziert haben, Capability entziehen. Wenn ein Plugin eval auf einen Fetch setzt, das Plugin ist die Änderung dieser Woche, nicht “wir beobachten den Feed”.
WAF-Regeln gegen multipart von Authors sind der falsche Hebel für CVE-2026-65640. Der Request ist legitim. Die Gefahr sitzt nach PHP. WAF bleibt nützlich für anonymes Scanning und bekannte Plugin-CVEs, das steht im Härtungs-Guide. Für diesen Pfad zählt Inhaltprüfung im Core plus Coder-Verbot auf dem Host.
Headless diese Woche umbauen, “damit PHP weg ist”, schließt CVE-2026-65640 nicht. Der Katalog wird statisch. wp-admin bleibt. Media bleibt. Authors bleiben. Wer Headless aus anderen Gründen plant, plant es im Härtungs- und Architekturpfad, nicht als Notfallreaktion auf 7.0.4.
Audit und Lektüre
Das Sicherheitsaudit ist Imagick/Ghostscript, Author, Remote-JSON, und das Plugin-Zip das niemand gelesen hat. Passkeys, schreibgeschützte Platte und Edge-WAF bleiben in der fortgeschrittenen Härtung.
CVE-2026-65640 ist ein Pfad. policy.xml ist die Kontrolle, die noch zählt, wenn der nächste ähnliche Bug gemeldet wird. JSON das ausgeführt wird, ist ein anderer Pfad. Vibe-codierte Zips sind ein dritter. Eine Plugin-Seite die “geschützt” schreibt, adressiert keinen davon allein.
Was wir in einem Audit zu diesem Stand konkret anfassen:
- Core-Version und Backport, nicht nur “irgendwas mit 7”
- Imagick geladen, Ghostscript vorhanden, policy.xml-Inhalt, nicht die Plugin-Checkbox “Medien härten”
- Zahl der Nutzer mit
upload_files, inklusive Author und Editor - Plugin-PHP auf
eval, Remote-Fetch, Phar,create_function - Bewertungs- und Notice-Widgets: woher das JSON kommt, ob es ausgeführt oder nur angezeigt wird
- wp-admin und Media auf Headless-Setups, nicht nur der öffentliche Katalog
Der Bericht ist eine Reihenfolge, kein Badge. Patch, policy.xml, JSON-Pfade, Rollen, dann Runtime-Themen aus dem Härtungs-Guide. Preise sind individuell, das Audit ist kein SKU. Wer schreibt, nimmt PHP-Version, ob Imagick geladen ist, und wie viele Authors hochladen mit, wenn das inspiziert werden soll.
Fazit
Drei Core-Sicherheitsreleases in vier Wochen sind der Takt, kein Slogan. Das August-Release braucht Author, Imagick und Ghostscript. Core patchen. Ghostscript-Coder auf dem Host verweigern. Eval von Remote-JSON stoppen. Chat-exportierte Plugins von Produktion fernhalten, bis sie jemand gelesen hat.
Deutsche Shops haben die JSON-Klasse oft schon im Header, als Sterne und Siegel-Widgets. Der Scanner bleibt grün, weil die Platte sich nicht ändert. Headless nimmt wp-admin und den Upload nicht weg. Ein zweites Security-Plugin schreibt policy.xml nicht.
Wenn das inspiziert werden soll, stehen im Text die PHP-Version, ob Imagick geladen ist, ob gs existiert, wie viele Authors hochladen, und welche Plugins JSON vom Vendor holen. Das Sicherheitsaudit prüft diesen Stand. Der Härtungs-Guide ist der Betrieb danach.
