Zum Inhalt springen
findflix live•7 Tage Pro gratis testen•Keine Kreditkarte nötig
Neues Projekt gesucht?Los geht's
Page Builder & Tools

WordPress 7.0.4: PNG mit versteckter PostScript-Fracht führt Code aus, ein Autor-Konto reicht

17. August 2026 · 3 Min. Lesezeit

Auf verwundbaren Sites reicht ein Autoren-Login, um über einen präparierten Bild-Upload eigenen Code auf dem Server auszuführen. WordPress hat die Lücke am 13. August als 7.0.4 geschlossen und den Fix bis in die Reihe 4.7 zurückportiert.

Stilisiertes WordPress-Emblem in Lime auf dunkler Bühne, dahinter ein Schutzschild und ein gerissener Bilderrahmen

Die WordPress-Sicherheits-Crew hat am 13. August die Version 7.0.4 herausgegeben, um eine kritische Lücke in der Bildverarbeitung zu schließen. Wer WordPress mit der Imagick-Erweiterung und installiertem Ghostscript betreibt, konnte über einen einzigen präparierten Bild-Upload beliebigen Code auf dem Server ausführen lassen. Angreiferseitig reicht dafür ein authentifiziertes Konto mit Autor-Rechten, also weder ein Passwort-Diebstahl an einem Admin noch ein zweiter Bruch der Rechteverwaltung.

Die Schwachstelle trägt die Kennung CVE-2026-65640 und ist mit einem CVSS-Wert von 8.8 im hohen Bereich eingestuft. Betroffen sind laut WordPress alle Versionen von 4.7 bis 7.0.3. Weil viele Sites auf älteren Zweigen leben, hat WordPress den Fix bis in die Reihe 4.7 zurückportiert. In der offiziellen Ankündigung heißt es: „WordPress version 7.0.4 has been released, containing a fix for the vulnerability, and as a courtesy to users on older branches, the fix has been backported to all branches back to 4.7.“

Wie die Kette funktioniert

Der Angriff hebelt eine bekannte Eigenheit von ImageMagick aus: die Bibliothek prüft den Datei-Inhalt und nicht die Endung. Wer eine Datei mit dem Header eines PostScript-Programms als vermeintliche PNG hochlädt, reicht darüber ein ausführbares Skript in die Bild-Pipeline. ImageMagick erkennt PostScript im Inhalt und ruft Ghostscript auf, um die Datei zu rendern. In genau diesem Moment läuft der Angreifer-Code auf dem Server, mit denselben Rechten wie der Webserver-Prozess.

Der Patch setzt zwei Riegel. Die Ladefunktion prüft jetzt den Datei-Inhalt vor der Übergabe an ImageMagick und verhindert die Manipulation über den Dateinamen. Damit fallen beide Bausteine des Exploits weg: die verschleierte Endung wird erkannt, und selbst wenn PostScript im Body auftaucht, landet die Datei nicht mehr blind bei Ghostscript.

Wer betroffen ist

Zwei Bedingungen müssen zusammenkommen, damit die Lücke ausnutzbar ist. Erstens braucht der Angreifer ein Konto mit der Berechtigung upload_files: das trifft in einer Standard-Installation Autoren, Redakteure und Administratoren. Beitrags-Ersteller (Contributor) fallen raus, weil sie keine Dateien hochladen dürfen. Zweitens muss die Site auf einem Server laufen, der sowohl die Imagick-Erweiterung nutzt als auch Ghostscript installiert hat. Diese Kombination ist besonders auf klassischem Shared-Hosting und in älteren LAMP-Stacks verbreitet, bei manchen Managed-Hostern seltener.

Für Sites mit offener Registrierung, aktiver Autoren-Community oder externem Redaktionsteam ist das Risiko akut: jedes Autor-Konto kann ab sofort zum Einfallstor werden. Bei Ein-Personen-Blogs mit einem einzigen Admin-Account ist die direkte Gefahr kleiner, aber jeder erfolgreiche Phishing-Angriff auf ein Autor-Passwort reicht ab jetzt für Vollzugriff.

Was das für Webdesigner heißt

Wer Websites für Kundinnen und Kunden betreut, hat heute drei Baustellen. Alle Kunden-Sites, die auf der 4.7er- bis 7.0.3er-Reihe laufen, müssen zeitnah auf 7.0.4 oder den passenden Backport-Zweig gehoben werden. Bei Sites mit Redaktions-Team lohnt zusätzlich ein Blick in die Nutzer-Liste: schlummernde Autor-Konten mit schwachem Passwort sind jetzt ein Vollzugriff-Risiko. Und für die eigene Hosting-Übersicht ist der Moment gut, um pro Kundenprojekt zu vermerken, ob Imagick und Ghostscript aktiv sind. Diese Info erspart bei der nächsten vergleichbaren Meldung die Suche.

Was heute konkret zu tun ist

  • Alle betreuten WordPress-Installationen inventarisieren: welche Kernversion läuft, alles unter 7.0.4 einplanen.
  • Auto-Updates für Sicherheitsreleases im Kern aktivieren, falls noch nicht scharf.
  • Nutzer-Rollen aufräumen: veraltete Autor-Konten deaktivieren, für aktive Autoren starke Passwörter und Zwei-Faktor durchsetzen.
  • Beim Hoster oder in der PHP-Info nachsehen, ob Imagick und Ghostscript aktiv sind. Wenn ja, ist das Update Pflicht, nicht Empfehlung.
  • Bei Verdacht auf zurückliegende Uploads das Upload-Verzeichnis nach Dateien mit ungewöhnlichem Inhalt scannen, besonders wenn eine Site in den letzten Wochen fremdgesteuerte Beiträge oder auffällige Login-Aktivität hatte.

Wer Sicherheits-Pflege als eigenen Betreuungs-Baustein zusätzlich zu Design und SEO verkaufen möchte, findet Argumente und Angebotsstruktur in unserer Anleitung zur Leadgewinnung für Webdesigner.