WordPress 7.0.4 schließt Imagick-Lücke, die Autoren Code ausführen lässt

WordPress 7.0.4 schließt eine Lücke, die es einem angemeldeten Autor ermöglichte, einen harmlos aussehenden Bild-Upload in Code zu verwandeln, der auf dem Server ausgeführt wird. Patchstack, das Sicherheitsunternehmen, das das Problem gemeldet hat, veröffentlichte seinen Bericht am 12. August 2026 und erklärt, dass das Problem WordPress-Core-Versionen 4.7 bis 7.0 betrifft. WordPress.org hat seine eigene Ankündigung der Veröffentlichung veröffentlicht. Patchstack gibt außerdem an, eine Mitigationsregel für betroffene Websites bereitgestellt zu haben, die mit seiner Plattform verbunden sind.

WordPress verlässt sich auf ImageMagick, ein weit verbreitetes Bildverarbeitungs-Toolkit, auf das es über eine PHP-Erweiterung namens Imagick zugreift, um die Bilder in der Mediathek zu skalieren und zu verarbeiten. Der Haken ist, dass ImageMagick weit mehr als JPEG- und PNG-Bilder versteht. Es kann auch PostScript-, EPS- und PDF-Dateien öffnen, und um diese Formate darzustellen, ruft es Ghostscript auf, ein separates Programm mit einer langen Geschichte darin, dazu überredet zu werden, Befehle auszuführen, die es nicht ausführen sollte. Patchstack ordnet dies in dieselbe Problemfamilie wie die älteren ImageTragick-Bugs ein.

Die Diskrepanz, die das Risiko schuf, läuft darauf hinaus, wie beide Seiten entscheiden, was eine Datei ist. ImageMagick identifiziert eine Datei anhand ihres Inhalts, während WordPress sich überwiegend auf die Dateinamenserweiterung verließ. Eine Datei namens holiday.png, die tatsächlich PostScript enthielt, würde daher die Upload-Prüfungen passieren und an Imagick übergeben werden, das das PostScript darin erkennen und Ghostscript starten würde. Das Bild war nie ein Bild.

Patchstack führt die Lücke auf die Methode load() in WP_Image_Editor_Imagick zurück, den Teil von WordPress, der eine hochgeladene Datei an die Bildbibliothek übergibt. Sie entschied nur anhand der Erweiterung, wie die Datei weitergegeben wird, und sah nie in die Datei hinein. Die dort verwendeten Aufrufe readImage() und readImageBlob() untersuchen die identifizierenden Bytes der Datei, die sogenannten Magic Bytes, und ignorieren den Namen. Inhalt, der mit %!, \x04%!, \xC5\xD0\xD3\xC6 oder \xFFWPC beginnt, reicht aus, um ImageMagicks PostScript-, EPS- oder WordPerfect-Grafikbehandlung auszuwählen, und von dort führt Ghostscript die Datei als PostScript-Programm aus.

Bei einem gewöhnlichen Upload fängt WordPress' Prüfung wp_check_filetype_and_ext() dies ab und stoppt den Angriff. Das Problem ist, dass nicht jeder Upload-Pfad durch diese Prüfung läuft. Patchstack sagt, dass die XML-RPC-Methode wp.uploadFile und die Routine, die WordPress verwendet, um Cover-Art aus hochgeladenen MP3-Dateien zu extrahieren, ihre Bytes beide mit wp_upload_bits() auf die Festplatte schreiben, einer Funktion, die niemals den Inhalt untersucht. Die Nutzlast landet trotzdem auf dem Server und erreicht trotzdem den verwundbaren Code.

Die Korrektur ist ein Commit mit der Nummer 7daaa50, der die Funktion load() überarbeitet, sodass sie den Inhalt der Datei untersucht, bevor das Imagick-Objekt erstellt wird. Nichts, was an einen Decoder aus der PostScript-Familie weitergeleitet würde, wird mehr durchgelassen.

Konkret schnüffelt der gepatchte Code im ersten Teil jeder Datei und weist mehrere Kategorien ab. PostScript und EPS werden abgelehnt, egal ob sie anhand ihrer Signaturen (der %!-Marker, binäre EPS-Header oder WordPerfect-Grafiken), anhand der Erweiterung oder anhand von ImageMagick-Formatbezeichner-Präfixen erkannt werden. Dateien, die eine PDF-Erweiterung beanspruchen, aber nicht mit dem echten %PDF--Marker beginnen, werden als gefälschte PDFs abgelehnt. Komprimierte Dateien, die ImageMagick stillschweigend entpacken würde, wie gzip- und bzip2-Archive, werden ebenfalls abgelehnt, da sie ein weiterer Weg waren, Inhalte an den Prüfungen vorbeizuschmuggeln.

Es gibt ein subtileres Detail. ImageMagick erlaubt es, einen bestimmten Handler zu erzwingen, indem man einem Dateinamen ein Präfix voranstellt, zum Beispiel EPS:innocent.png. Der neue Code entfernt und untersucht diese Präfixe, wobei er darauf achtet, nicht über Windows-Laufwerksbuchstaben wie C: zu stolpern. Derselbe Trick kann über eine entfernte URL oder einen Stream ankommen, daher extrahiert die Korrektur auch Dateinamen aus diesen Quellen, bevor sie sie validiert.

Um den verwundbaren Code zu erreichen, ist die Fähigkeit erforderlich, Medien hochzuladen, was ein Konto der Stufe Autor oder höher bedeutet. Patchstack stellt ausdrücklich klar, dass dies kein anonymer Drive-by-Angriff ist. Aber die Hürde ist niedriger, als es klingt, bei einer Publikation mit mehreren Autoren, einer Mitgliederseite, einer Kundenseite mit Beitragenden oder jeder Seite mit offener oder locker verwalteter Registrierung. Auf solchen Seiten ist ein Autor, der ein mit einer Falle versehenes Bild hochlädt, eine realistische Bedrohung und nicht nur eine theoretische. Wo eine Seite nur ihren Eigentümer und eine kleine, eng kontrollierte Gruppe von Redakteuren hat, ist die Exposition geringer.

Update. Seiten mit aktivierten automatischen Hintergrund-Updates sind möglicherweise bereits abgedeckt, daher lohnt sich eine schnelle Überprüfung der Version, und wer manuell aktualisiert, sollte diese Veröffentlichung priorisieren, insbesondere dort, wo Konten über ein Kernteam hinaus vergeben werden. Für Seitenbetreiber, die nicht selbst jede Core-Veröffentlichung verfolgen möchten, bietet AEU Hosting verwaltetes WordPress-Hosting, bei dem die Plattformseite des Betriebs einer WordPress-Seite für Sie übernommen wird.

Patchstack schließt mit einer Erinnerung daran, wie der Umgang mit Medien im Allgemeinen angegangen wird: Der riskante Teil ist normalerweise nicht das Bild selbst, sondern alles andere, was die Bildbibliothek stillschweigend zu öffnen bereit ist.