WordPress выпускает срочное обновление 7.0.4 для устранения критической уязвимости в обработке изображений

Vierundzwanzig Release-Zweige, der älteste zurück bis Version 4.7.35 — so weit reicht die Backport-Liste, die das WordPress-Sicherheitsteam am Mittwochnachmittag veröffentlicht hat. WordPress 7.0.4 schließt eine einzige Schwachstelle, CVE-2026-65640, und es ist die zweite außerplanmäßige Freigabe binnen sechs Tagen: Vergangene Woche stopfte 7.0.3 die Kette XSS2Shell auf dem Login-Bildschirm. Diesmal liegt das Problem woanders, nämlich auf dem Weg, den ein hochgeladenes Bild durch die Mediathek nimmt. Auf einen Blick - Betroffen sind alle Fassungen von 4.7.0 bis 7.0.3; gepatcht ist in 24 Zweigen, von 7.0.4 bis hinunter zu 4.7.35. - Die Lücke greift nur, wenn auf dem Server die PHP-Erweiterung Imagick und Ghostscript aktiv sind. - Der Angreifer braucht ein Konto mit Upload-Recht — Autorenrolle oder höher. Ein Vorab-Login ist also Bedingung, kein Beiwerk. - Bewertet mit 8,8 von 10 Punkten, eingeordnet als CWE-434 (Upload gefährlicher Dateitypen). - Gemeldet hat sie das Team von pwn.ai — dieselbe Adresse wie bei 7.0.3. Wenn WordPress der Endung traut und ImageMagick dem Inhalt Der Kern des Fehlers ist keine vergessene Prüfung, sondern eine Meinungsverschiedenheit zwischen zwei Komponenten darüber, was eine Datei eigentlich ist. ImageMagick entscheidet das durch einen Blick in den Dateiinhalt, also anhand der ersten Bytes. WordPress verließ sich an dieser Stelle auf die Dateiendung. Die Methode WP_Image_Editor_Imagick::load() las den Namen, nicht den Inhalt. Damit lässt sich eine Datei bauen, die für beide Seiten etwas anderes ist. Sie heißt urlaub.png und besteht innen aus PostScript. Die Upload-Kontrolle sieht ein PNG und winkt durch. ImageMagick erkennt an der Signatur PostScript und reicht die Datei an Ghostscript weiter — und Ghostscript führt Anweisungen aus, die in einem PostScript-Programm stehen. Genau dieser Delegate-Mechanismus hat die Bildbibliothek schon 2016 in die Schlagzeilen gebracht; neu ist nicht das Verhalten von Ghostscript, sondern dass man ihm über eine gewöhnliche WordPress-Mediathek etwas vorlegen konnte. Der Patch dreht die Reihenfolge um: Bevor überhaupt ein Imagick-Objekt entsteht, wird der Inhalt geprüft. Abgewiesen werden jetzt PostScript-Signaturen, als Bild getarnte PDFs, komprimierte Dateien — und Dateinamen, die einen Handler vorschreiben wollen, etwa in der Form EPS:harmlos.png. Zwei Bedingungen entscheiden, wen es trifft Die Kurzfassung „Remote Code Execution in WordPress“ trägt hier nur bedingt. Der Server muss Imagick und Ghostscript mitbringen, und der Angreifer braucht bereits ein Konto mit der Berechtigung upload_files, also mindestens die Autorenrolle. Das schlägt sich in der Bewertung nieder: 8,8 Punkte mit der Vorbedingung niedriger Rechte, nicht der Spitzenwert, den eine Lücke ganz ohne Anmeldung erreicht. Trivial sind die Bedingungen trotzdem nicht. WordPress bevorzugt Imagick seit Version 3.5, sobald die Erweiterung vorhanden ist, und Ghostscript landet auf vielen Hosting-Paketen nicht aus Versehen, sondern weil ohne es die Vorschaubilder für PDF-Uploads fehlen. Zwei Upload-Pfade kamen zudem an der üblichen Prüfung wp_check_filetype_and_ext() vorbei, weil sie direkt über wp_upload_bits() schreiben: die XML-RPC-Methode wp.uploadFile und die Titelbild-Extraktion aus hochgeladenen MP3s. Wer XML-RPC ohnehin geschlossen hat, verliert damit einen der beiden Wege — den zweiten nicht. Auf meinen eigenen Maschinen bei netcup und Hetzner ist Imagick der Normalfall und nicht die Ausnahme, schlicht weil GD bei der Skalierungsqualität abfällt und WebP-Ausgabe damit umständlicher wird. Wer eine Mehrautoren-Redaktion betreibt, sollte die Kombination deshalb nicht als exotisch abtun: Gastautoren, Praktikanten und alte Redakteurskonten, die nie deaktiviert wurden, sind genau die Rolle, die diese Lücke voraussetzt. Die Vorarbeit lag seit Ende März offen Bemerkenswert ist das Datum daneben. Die zugrunde liegende ImageMagick-Untersuchung von pwn.ai steht seit dem 30. März öffentlich im Netz — inklusive eines demonstrierten Schreibzugriffs auf WordPress 6.9.4 über XML-RPC mit Autorenrechten. Zwischen dieser Veröffentlichung und dem Kern-Patch liegen viereinhalb Monate. Dass in dieser Zeit niemand die Vorlage aufgegriffen hat, ist eine Annahme, keine Feststellung; belegt ist bislang weder ein öffentlicher Exploit für CVE-2026-65640 noch eine aktive Ausnutzung. Beide Freigaben dieser und der vergangenen Woche gehen auf dasselbe Team zurück, das seine Funde nach eigener Darstellung weitgehend autonom von einer KI erarbeiten lässt — im Fall der ImageMagick-Analyse mit der Angabe, der Agent habe knapp fünf Tage lang selbstständig recherchiert. Das ist die Aussage des Anbieters, keine unabhängig geprüfte Messung, und pwn.ai verkauft genau dieses Produkt. Ich halte die Zahl trotzdem für die interessantere Nachricht als die Lücke selbst: Wir haben hier vor zehn Tagen nachgezählt, wie wenige KI-generierte Schwachstellenmeldungen je in echten Angriffen landen. Zwei Kernlücken im meistgenutzten CMS der Welt innerhalb einer Woche fallen nicht in diese Kategorie. Für Betreiber ändert die Debatte nichts an der Reihenfolge. Automatische Hintergrund-Updates ziehen WordPress 7.0.4 von selbst nach, bei allen anderen Installationen ist es ein Klick unter Dashboard → Aktualisierungen. Wer eine ältere Hauptversion fährt, findet seinen Zweig in der Patch-Liste — dass die Backports bis 4.7 zurückreichen, ist ein stilles Eingeständnis, wie viele Installationen dort unten noch laufen. Und wer die Autorenrolle bisher als harmlos verbucht hat, hat jetzt einen Anlass, die Nutzerliste einmal durchzugehen.