WordPress 7.0.4 schließt kritische RCE-Lücke bei Datei-Uploads

Veröffentlicht am 13.08.2026

Ein hochgeladenes Bild, das gar kein Bild ist – und plötzlich läuft fremder Code auf Ihrem Server. Genau dieses Szenario schließt das WordPress-Sicherheitsupdate 7.0.4. Die Schwachstelle mit der Kennung CVE-2026-65640 erlaubt es angemeldeten Nutzern ab der Rolle „Author“, über einen bösartigen Datei-Upload beliebigen Programmcode auf dem Webserver auszuführen (eine sogenannte Remote Code Execution, kurz RCE). WordPress stuft das Problem als hoch ein und empfiehlt ausdrücklich, betroffene Websites sofort zu aktualisieren.

Die gute Nachricht vorweg: Nicht jede WordPress-Installation ist verwundbar. Damit der Angriff funktioniert, müssen mehrere Bedingungen gleichzeitig erfüllt sein. Die weniger gute Nachricht: Genau diese Bedingungen sind auf vielen typischen KMU-Websites – etwa mit mehreren Redakteuren, Kundenbereichen oder Mitgliederportalen – durchaus gegeben. In diesem Artikel erklären wir verständlich, was passiert ist, wie Sie prüfen, ob Sie betroffen sind, und welche konkreten Schritte jetzt anstehen.

Was ist passiert?

Am 12. August 2026 hat WordPress die Version 7.0.4 als reines Sicherheitsrelease veröffentlicht. Damit wird die Schwachstelle CVE-2026-65640 geschlossen. Das offizielle GitHub Security Advisory (GHSA-8vr3-7mxf-gx8w) bewertet die Lücke mit einem CVSS-Wert von 8,8 von 10 („High“) – CVSS ist die branchenübliche Skala zur Einordnung der Gefährlichkeit von Sicherheitslücken.

Das WordPress-Sicherheitsteam beschreibt die Lücke so:

„Authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript.“ – WordPress Security Team

Übersetzt heißt das: Ein angemeldeter Nutzer mit mindestens der Rolle Author kann auf Websites, die die Komponenten Imagick und Ghostscript nutzen, über einen bösartigen Datei-Upload Schadcode ausführen. WordPress selbst formuliert unmissverständlich:

„Because this is a security release, it is recommended that you update your sites immediately.“ – WordPress

Der Fund wurde laut Release-Mitteilung verantwortungsvoll durch pwn.ai gemeldet. Für ältere WordPress-Zweige bis zurück zu 4.7 sind Backports – also nachgereichte Korrekturen für ältere Versionslinien – ebenfalls veröffentlicht worden.

Der technische Hintergrund – verständlich erklärt

Um zu verstehen, warum ein harmlos aussehendes Bild gefährlich werden kann, hilft ein Blick auf zwei beteiligte Werkzeuge:

• Imagick ist eine PHP-Erweiterung, mit der WordPress Bilder verarbeitet – etwa zum Erstellen von Vorschaubildern.
• Ghostscript ist ein Programm zur Verarbeitung von PostScript- und PDF-Inhalten. PostScript ist eine Seitenbeschreibungssprache, die weit mehr kann als nur Bilder darzustellen.

Der Kern des Problems: WordPress hat eine hochgeladene Datei teilweise nach ihrer Dateiendung behandelt (etwa „.png“), während ImageMagick den tatsächlichen Inhalt der Datei auswertet. Diese Diskrepanz lässt sich ausnutzen. Ein Angreifer kann PostScript-Inhalt so tarnen, dass er wie ein gewöhnliches Bild wirkt. Landet dieser Inhalt dann bei Ghostscript, greift eine Schwäche in dessen Verarbeitung bestimmter eingebetteter Dateien – und der Weg zur Code-Ausführung ist frei.

Fachlich ist die Lücke als CWE-434 klassifiziert, also „Unrestricted Upload of File with Dangerous Type“ – der unkontrollierte Upload einer Datei mit gefährlichem Typ. Dave Jong, Security Research Lead bei Patchstack, bringt es auf den Punkt:

„It changes how WordPress hands your uploaded media to ImageMagick, and it closes a path that could let a logged-in author turn an ordinary-looking image upload into code execution on your server.“ – Dave Jong, Patchstack

Der eingespielte Patch (Commit-Titel: „Media: Prevent loading images into Imagick which might be PostScript“) setzt genau hier an: WordPress liest die Dateidaten künftig vor der Verarbeitung durch Imagick ein und prüft sie. Zurückgewiesen werden nun unter anderem PostScript-Formate und -Signaturen, unechte PDFs, komprimierte Container sowie erzwungene Imagick-Formatbezeichner im Dateinamen – Letzteres verhindert, dass ein Angreifer gezielt einen gefährlichen Decoder erzwingt.

Die Analyse von Patchstack nennt als relevante Upload-Pfade unter anderem die XML-RPC-Schnittstelle (wp.uploadFile) sowie die Cover-Art-Extraktion aus hochgeladenen MP3-Dateien. Wichtig zur Einordnung: Es handelt sich nicht um eine anonym ausnutzbare Lücke und nicht um jede WordPress-Installation. Die Voraussetzungen (Anmeldung, Upload-Berechtigung, Imagick + Ghostscript) müssen zusammenkommen.

Wer ist betroffen?

Verwundbar sind grundsätzlich alle WordPress-Versionen von 4.7.0 bis 7.0.3 – aber nur, wenn zusätzlich folgende Bedingungen erfüllt sind:

• Auf dem Server werden Imagick UND Ghostscript tatsächlich eingesetzt.
• Ein Angreifer verfügt über die Berechtigung upload_files. Diese liegt standardmäßig bei den Rollen Author, Editor und Administrator.

Besonders exponiert sind daher Websites mit mehreren Autoren: Redaktionen, Mitgliederportale, Kundenbereiche oder über die Jahre unübersichtlich gewachsene Benutzerkonten. Auch ein einzelnes kompromittiertes Author-Konto genügt bereits. Wer dagegen eine streng administrierte Einzelredaktion ohne weitere Upload-Konten betreibt, hat einen deutlich engeren Angriffsvoraussetzungskreis – aber eben nicht null.

Wichtig: Auch Installationen ohne die Kombination aus Imagick und Ghostscript sollten aktualisieren, denn die Version selbst fällt in den betroffenen Bereich. Das Update ist in jedem Fall die richtige Entscheidung.

Eine belastbare Zahl konkret verwundbarer oder kompromittierter Installationen ist nicht veröffentlicht. Zur Einordnung der Verbreitung: W3Techs ermittelte am 12.08.2026, dass WordPress auf 41,0 % aller Websites läuft – das sagt jedoch nichts über die tatsächliche Verwundbarkeit für diese spezielle CVE aus. Zum Recherchezeitpunkt gibt es keine bestätigte aktive Ausnutzung dieser Lücke; sie war nicht im CISA-KEV-Katalog gelistet. Das ist allerdings kein Freibrief: Nach der Veröffentlichung eines Patches erscheinen erfahrungsgemäß häufig öffentliche Exploits.

So prüfen Sie, ob Sie betroffen sind

1. Core-Version feststellen: Im WordPress-Backend unter Dashboard → Aktualisierungen, oder – falls das Kommandozeilenwerkzeug WP-CLI verfügbar ist – mit wp core version. Jede Version unterhalb des passenden Patchstands ist aktualisierungsbedürftig.
2. Imagick prüfen: Bei administrativem Serverzugriff zeigt php -m | grep -i imagick, ob die PHP-Erweiterung aktiv ist. Alternativ kann Ihr Hoster dies verbindlich bestätigen.
3. Ghostscript prüfen: Über gs --version oder Ihren Hoster. Ist der Befehl nicht verfügbar, beweist das allein nicht, dass Ghostscript fehlt – gerade in verwalteten Hosting-Umgebungen sollte der Anbieter Auskunft geben. Entscheidend ist die tatsächliche gleichzeitige Nutzung von Imagick und Ghostscript.
4. Benutzerkonten prüfen: Sehen Sie im Backend unter Benutzer alle Konten mit mindestens der Rolle Author, Editor oder Administrator sowie benutzerdefinierte Rollen durch. Entscheidend ist die Capability upload_files, nicht allein der Rollenname.
5. Auffälligkeiten suchen: Prüfen Sie auf unbekannte Benutzer, unerwartete Uploads oder auffällige Einträge in Server-, Webserver- und PHP-Logs. Ein solcher Befund ist Anlass für eine fachliche Incident-Response-Prüfung – aber kein alleiniger Beweis für eine Ausnutzung.

Das müssen Sie jetzt tun

1. Sofort aktualisieren: Bringen Sie den WordPress-Core unverzüglich auf den für Ihren Zweig genannten Patchstand – bevorzugt auf 7.0.4 oder eine neuere unterstützte Version. Gepatcht sind unter anderem: 7.0.4, 6.9.7, 6.8.8, 6.7.7, 6.6.7, 6.5.10, 6.4.10, 6.3.10, 6.2.11, 6.1.12, 6.0.14, 5.9.16, 5.8.15 – die Reihe reicht bis hinunter zu 4.7.35. Fertigen Sie vorher ein getestetes Backup an und dokumentieren Sie Version, Zeitpunkt und Ergebnis. Update-Wege: Download von WordPress.org oder Dashboard → Updates → „Update Now“. Unterstützte automatische Hintergrund-Updates beginnen zeitnah.
2. Berechtigungen einschränken: Reduzieren Sie bis zum erfolgreichen Update die Zahl der Konten mit upload_files auf das Nötigste. Deaktivieren oder sperren Sie ungenutzte Author-/Editor-Konten und prüfen Sie besonders externe Autoren, frühere Dienstleister und benutzerdefinierte Rollen. Das senkt die Angriffsfläche, ersetzt aber nicht den Patch.
3. Update-Prozess absichern: Sorgen Sie dafür, dass Core-Updates künftig überwacht werden – durch automatische Hintergrund-Updates, einen dokumentierten manuellen Prozess und einen klaren Ansprechpartner beim Hoster oder Dienstleister. Das BSI mahnt: „Putting off installing updates? Do not delay!“
4. Serverseitig härten (Defense in Depth): Lassen Sie Ihren Hoster als zusätzliche Schutzschicht die ImageMagick-/Ghostscript-Policy für PostScript-, EPS- und verwandte Decoder prüfen (etwa über die policy.xml). Das ist eine ergänzende Absicherung, kein Ersatz für das WordPress-Update.
5. Bei Verdacht auf Kompromittierung: Sichern Sie Beweise und Logs, bereinigen Sie die Website nicht blind, setzen Sie Passwörter und Sitzungstoken risikobasiert zurück, untersuchen Sie unbekannte Konten und geänderte Dateien und ziehen Sie einen qualifizierten Incident-Response-Dienstleister oder Ihren Hoster hinzu.

Einordnung und DSGVO-Relevanz

Eine Remote Code Execution ist nicht automatisch eine meldepflichtige Datenschutzverletzung. Werden jedoch infolge einer Ausnutzung personenbezogene Daten unbefugt eingesehen, abgegriffen, verändert, verschlüsselt oder unzugänglich, kann eine Verletzung der Vertraulichkeit, Integrität oder Verfügbarkeit vorliegen.

Art. 32 DSGVO verlangt dem Risiko angemessene technische und organisatorische Maßnahmen – dazu gehört das zeitnahe Einspielen von Sicherheitsupdates ebenso wie regelmäßige Wirksamkeitsprüfungen. Kommt es zu einer Datenpanne, greift Art. 33 DSGVO: Die zuständige Aufsichtsbehörde ist unverzüglich und möglichst binnen 72 Stunden ab Kenntnis zu informieren, sofern die Verletzung voraussichtlich zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt. Jede Datenpanne ist zu dokumentieren. Bei voraussichtlich hohem Risiko ist nach Art. 34 DSGVO grundsätzlich auch eine unverzügliche Benachrichtigung der betroffenen Personen erforderlich.

Ein Verstoß gegen Art. 32 fällt nach Art. 83 Abs. 4 DSGVO in den Bußgeldrahmen von bis zu 10 Mio. EUR oder 2 % des weltweiten Vorjahresumsatzes – je nachdem, welcher Betrag höher ist. Die konkrete Höhe hängt von Faktoren wie Schwere, Dauer, Verschulden, Schadensminderung, getroffenen Maßnahmen und Kooperation ab. Zusätzlich kann bei materiellem oder immateriellem Schaden ein Schadensersatzanspruch nach Art. 82 DSGVO entstehen.

Kurz gesagt: Wer jetzt zügig patcht und den Vorgang dokumentiert, erfüllt nicht nur eine sicherheitstechnische, sondern auch eine rechtliche Sorgfaltspflicht.

Fazit

CVE-2026-65640 ist mit CVSS 8,8 eine ernstzunehmende Lücke, die vollständige Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit haben kann. Sie ist zwar an mehrere Voraussetzungen gebunden – Anmeldung, Upload-Berechtigung sowie die Kombination aus Imagick und Ghostscript – doch genau diese Konstellation ist auf vielen KMU-Websites Realität. Ein einziges kompromittiertes Author-Konto kann ausreichen.

Die Handlungsempfehlung ist eindeutig: Aktualisieren Sie WordPress unverzüglich auf 7.0.4 oder den passenden Patchstand Ihres Zweigs, reduzieren Sie überflüssige Upload-Berechtigungen und stellen Sie einen verlässlichen Update-Prozess sicher. Auch wenn zum Recherchezeitpunkt keine aktive Ausnutzung bestätigt ist – nach einer Patch-Veröffentlichung kann sich das schnell ändern. Wer heute handelt, ist auf der sicheren Seite.