WordPress 7.0.4 ist am 12. August 2026 erschienen und schliesst genau eine Sicherheitslücke. Keine Woche nach dem Zwölf-Lücken-Release 7.0.3 klingt das nach Routine — ganz ist es das nicht: Die eine Lücke erlaubt es, eigenen Code auf dem Server auszuführen. Ob Ihre Website überhaupt angreifbar ist, hängt von zwei Bedingungen ab, die beide gleichzeitig zutreffen müssen. Dieser Beitrag erklärt sie und zeigt, wie Sie Ihren Server in zwei Minuten selbst prüfen.
Das Wichtigste in Kürze
- Genau eine Lücke, genau eine geänderte Datei. 7.0.4 ist das kleinstmögliche Sicherheitsrelease: keine Funktionsänderungen, kein aktualisiertes Paket — das Update-Risiko geht gegen null.
- Codeausführung, bewertet mit CVSS 8.8 «hoch». Der Angreifer braucht ein Konto mit Autorenrechten und einen Server, auf dem Imagick und Ghostscript laufen — beides zusammen, sonst läuft der Angriff ins Leere.
- Die Kombination ist verbreiteter, als sie klingt. Sie steckt hinter den PDF-Vorschaubildern der Mediathek; unser eigener Entwicklungscontainer bringt beides ab Werk mit.
- Betroffen sind alle Reihen von 4.7 bis 7.0.3. Die Lücke sass rund zehn Jahre im Kern; die Korrekturen wurden bis Version 4.7.35 zurückportiert.
- Kein Notfall wie im Juli. Es gibt keine belegten Hinweise auf Ausnutzung. Zeitnah aktualisieren genügt — automatische Hintergrundupdates haben es vermutlich schon erledigt.
Eine Lücke, eine Datei: was 7.0.4 behebt
7.0.4 ist ein reines Sicherheitsrelease und ein bemerkenswert kleines: Laut offizieller Versionsdokumentation wurde eine einzige Kerndatei geändert — jener Teil von WordPress, der Bilder über die PHP-Erweiterung Imagick verarbeitet. Kein Paket wurde aktualisiert, am Verhalten der Website ändert sich nichts. Zum Vergleich: Das Release sechs Tage zuvor fasste zwölf Lücken und zehn geänderte Dateien zusammen — die Einordnung dazu steht in unserem Beitrag zu WordPress 7.0.3.
Die geschlossene Lücke trägt die Kennung CVE-2026-65640 und wurde vom Team von pwn.ai gemeldet. Die offizielle Sicherheitsmeldung beschreibt sie so: Bestimmte WordPress-Installationen sind über den Upload einer präparierten Postscript-Datei verwundbar — durch Benutzer mit Autorenrechten oder höher, auf Servern, die Imagick und Ghostscript einsetzen. Der eigentliche Fehler liegt laut Meldung in der Art, wie Ghostscript eingebettete Dateien verarbeitet; WordPress härtet mit 7.0.4 die Stelle ab, an der es diese Verarbeitung anstösst.
Zwei Bedingungen — beide müssen zutreffen
Erstens: ein Konto mit Autorenrechten. Der Angriff läuft über den Datei-Upload, und dafür braucht es eine Berechtigung, die WordPress ab der Rolle «Autor» vergibt. Besucher ohne Konto erreichen die Lücke nicht. Damit stellt sich dieselbe Frage wie schon bei 7.0.3: Wer schreibt bei Ihnen? Eine Firmenwebsite, auf der zwei interne Personen arbeiten, bietet kaum einen Ansatzpunkt. Ein Portal mit Gastautorinnen, ein Magazin mit externer Redaktion oder eine Website mit alten, nie aufgeräumten Redaktionskonten sieht anders aus.
Zweitens: Imagick und Ghostscript auf dem Server. Imagick ist die PHP-Erweiterung, mit der WordPress Bilder verkleinert und zuschneidet, wo sie verfügbar ist. Ghostscript ist ein Programm, das PostScript- und PDF-Dateien versteht. WordPress nutzt die Kette aus beiden seit Version 4.7, um in der Mediathek Vorschaubilder von PDF-Dokumenten zu erzeugen. Fehlt eines von beidem, gibt es zwar keine PDF-Vorschauen — aber diese Lücke läuft dann ins Leere.
Wie verbreitet die Kombination ist, zeigt ein Blick in unsere eigene Werkstatt: Der Entwicklungscontainer, in dem wir Änderungen an dieser Website testen, basiert auf dem offiziellen WordPress-Docker-Image — und bringt ab Werk beides mit, Imagick samt PDF-Unterstützung und Ghostscript 10.05.1. Wir haben das nie eingerichtet; es war einfach da. Gehen Sie also nicht davon aus, dass Ihr Hosting die Kombination nicht hat — prüfen Sie es.
In zwei Minuten geprüft: Ist Ihr Server betroffen?
WordPress zeigt beide Angaben selbst an, ohne Zusatzwerkzeug. Melden Sie sich im Adminbereich an und öffnen Sie «Werkzeuge → Website-Zustand», dort den Reiter «Bericht». Im Abschnitt «Medienverarbeitung» finden Sie die ImageMagick-Angaben und das Feld «Ghostscript-Version».
- Beide Angaben zeigen eine Versionsnummer: Ihr Server trägt die verwundbare Kombination. Spielen Sie das Update zeitnah ein und gehen Sie danach die Benutzerkonten durch.
- Eine der beiden Angaben fehlt oder konnte nicht ermittelt werden: Die Lücke ist auf Ihrem Server nach heutigem Wissen nicht ausnutzbar. Aktualisieren Sie trotzdem — die nächste Lücke hat andere Bedingungen.
Wenn Sie den Bericht nicht deuten können oder kein Adminzugang besteht, beantwortet Ihr Hoster die Frage «Läuft auf meinem Paket Ghostscript?» in einem Satz.
CVSS 8.8 — und trotzdem kein wp2shell
Die Sicherheitsmeldung des WordPress-Projekts bewertet die Lücke mit CVSS 8.8 als «hoch». Der Bewertungsvektor lohnt einen zweiten Blick, weil er diese Lücke von den beiden Fällen der letzten Wochen unterscheidet: Anders als die schwerste Lücke in 7.0.3 braucht sie keine Mitwirkung des Opfers und keine komplizierte Ausgangslage — wer die Voraussetzungen erfüllt, kann den Angriff automatisieren. Und anders als wp2shell im Juli funktioniert sie eben nicht ohne Konto.
| Lücke | Bewertung | Was der Angreifer braucht |
|---|---|---|
| wp2shell (Juli 2026) | 9.8 «kritisch» | Nichts — flächendeckend per Skript ausnutzbar, Ausnutzung belegt |
| 7.0.3, schwerste Lücke (CVE-2026-64638) | 8.9 «hoch» | Den Klick einer berechtigten Person — gezielter Angriff, nicht skalierbar |
| 7.0.4 (CVE-2026-65640) | 8.8 «hoch» | Ein Autorenkonto plus Imagick und Ghostscript — innerhalb dieser Bedingungen automatisierbar |
Für die Praxis heisst das: Panik ist nicht angezeigt, Aufschieben auch nicht. Treffen beide Bedingungen zu, sollte das Update nicht liegen bleiben — der Abstand zwischen «Lücke veröffentlicht» und «Werkzeug dafür verfügbar» wird kürzer, wie sich schon bei wp2shell gezeigt hat. Bemerkenswert bleibt, woher die Meldung kommt: wieder aus dem KI-Umfeld, wie schon bei mehreren Meldenden des 7.0.3-Releases.
Betroffene Versionen: zurück bis ins Jahr 2016
Betroffen sind alle WordPress-Reihen von 4.7 bis 7.0.3. Das ist bemerkenswert: Version 4.7 erschien im Dezember 2016 — mit ihr kamen die PDF-Vorschaubilder in die Mediathek und damit genau die Verarbeitungskette, um die es hier geht. Die Lücke sass also rund zehn Jahre im Kern, bis sie jemand fand und meldete.
| Ihre Version | Sicher ab |
|---|---|
| 7.0.0 – 7.0.3 | 7.0.4 |
| 6.9 bis 6.0 | 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 bis 4.7 | je eigene Korrekturversion, bis hinunter zu 4.7.35 |
| 4.6 und älter | keine Sicherheitsupdates mehr |
Auch WordPress 7.1 ist berührt: Der dritte Veröffentlichungskandidat vom selben Tag enthält die Korrektur bereits, am Erscheinungstermin 19. August ändert sich nichts. Was der Versionssprung sonst bedeutet — und was er brechen kann —, steht in unserem Beitrag zu den Breaking Changes in 7.1.
Was zu tun ist — in vier Schritten
- Version prüfen. Adminbereich, unten rechts auf dem Dashboard, oder «Werkzeuge → Website-Zustand». Steht dort 7.0.4 — oder die aktuelle Korrekturversion Ihrer Reihe, etwa 6.9.7 —, sind Sie durch.
- Falls nicht: aktualisieren. «Dashboard → Aktualisierungen → Jetzt aktualisieren». Eine geänderte Datei, keine Funktionsänderungen — wenn ein Update je risikoarm war, dann dieses.
- Medienverarbeitung anschauen. Der Zwei-Minuten-Check von oben zeigt, ob Ihr Server die verwundbare Kombination trägt — und damit, wie dringend die Sache für Sie war.
- Konten mit Autorenrechten durchgehen. Der Angriff braucht ein Konto mit Upload-Recht. Alte Redaktionskonten und verwaiste Zugänge externer Dienstleister sind die Aufräumarbeit, die diese Lücke konkret verlangt.
Nicht nötig ist eine Bereinigung wie nach wp2shell: Es gibt bislang keine belegten Hinweise darauf, dass die Lücke vor der Veröffentlichung ausgenutzt wurde. Und falls Sie solche Meldungen nicht selbst verfolgen möchten: Genau dafür gibt es die laufende Betreuung — Updates werden geprüft eingespielt, und Releases wie dieses landen bei uns statt in Ihrem Posteingang. Mehr unter WordPress Support & Wartung und Security & Härtung.
Häufige Fragen
Ich habe erst letzte Woche auf 7.0.3 aktualisiert. Schon wieder?
Ja — 7.0.3 gehört zu den betroffenen Versionen, wie alle Reihen seit 4.7. Der Aufwand ist diesmal minimal: eine einzige geänderte Datei, keine Funktionsänderungen. Wenn automatische Hintergrundupdates aktiv sind, hat Ihre Website den Schritt vermutlich längst selbst gemacht.
Was ist Ghostscript, und warum läuft es auf meinem Server?
Ghostscript ist ein Programm, das PostScript- und PDF-Dateien liest und darstellt. WordPress braucht es zusammen mit der PHP-Erweiterung Imagick, um in der Mediathek Vorschaubilder von PDF-Dokumenten zu erzeugen — eine Funktion, die es seit Version 4.7 gibt. Auf vielen Hosting-Umgebungen und Server-Vorlagen ist es deshalb standardmässig installiert, auch wenn Sie es nie bewusst eingerichtet haben.
Wir haben keine Gastautoren. Sind wir damit sicher?
Der Angriffsweg setzt ein Konto mit Autorenrechten oder höher voraus. Ohne fremde Konten bleibt als Szenario ein übernommenes Konto — etwa durch ein anderswo gestohlenes und wiederverwendetes Passwort. Deshalb: trotzdem aktualisieren, und die Gelegenheit nutzen, Konten und Rollen einmal durchzugehen.
Kann ich statt des Updates einfach Ghostscript deaktivieren?
Die offizielle Sicherheitsmeldung nennt keine Behelfslösung, und auf gemietetem Hosting entscheiden Sie über installierte Serverprogramme ohnehin nicht selbst. Der belegte, einfache Weg ist das Update — es ist kleiner als jedes Plugin-Update, das Sie diesen Monat einspielen werden.
Gilt das auch für WordPress 7.1?
Der dritte Veröffentlichungskandidat vom 12. August enthält die Korrektur bereits; wer einen älteren Veröffentlichungskandidaten testet, sollte ihn aktualisieren. Am Erscheinungstermin — 19. August 2026 — ändert sich nichts.
Fazit
7.0.4 ist das Gegenteil eines Notfalls und trotzdem kein Release zum Ignorieren: eine Lücke, die auf vielen Servern theoretisch bleibt — und auf den übrigen Codeausführung bedeutet. Die Prüfung, zu welcher Gruppe Ihre Website gehört, dauert zwei Minuten; das Update selbst ist das kleinste des Jahres.
Es ist zugleich das dritte sicherheitsrelevante Ereignis innert eines Monats — wp2shell im Juli, zwölf Lücken in 7.0.3, jetzt die Imagick-Kette. Wer Updates «bei Gelegenheit» einspielt, findet dazwischen schlicht keine Gelegenheit mehr. Wenn Sie diese Taktzahl nicht selbst halten möchten, ist das der Punkt, an dem sich eine laufende Betreuung rechnet.
Quellen
- WordPress.org: WordPress 7.0.4 Release ↗ — offizielle Ankündigung vom 12. August 2026
- WordPress.org: Version 7.0.4 ↗ — Versionsdokumentation mit der geänderten Datei und allen Backport-Versionen
- Sicherheitsmeldung GHSA-8vr3-7mxf-gx8w ↗ — CVE-2026-65640, CVSS 8.8, betroffene Versionsbereiche und Voraussetzungen
- WordPress.org: Version 4.7 ↗ — Einführung der PDF-Vorschaubilder im Dezember 2016
Stand: 13. August 2026. Sicherheitslagen ändern sich; sollten Hinweise auf aktive Ausnutzung auftauchen, aktualisieren wir diesen Beitrag.
Ähnliche Beiträge
WordPress 7.0.3: 12 Sicherheitslücken geschlossenReines Sicherheitsrelease vom 6. August, zwölf Lücken, keine Funktionsänderungen. Die schwerste ist mit CVSS 8.9 «hoch», nicht kritisch…
WordPress 7.1: Was am 19. August auf Ihrer Website brichtReact 19 kommt doch nicht — dafür gilt der iframe-Zwang im Editor neu für alle Themes. Was das…
wp2shell: Kritische WordPress-Sicherheitslücke (CVE-2026-63030) — sofort patchen und bereinigenDie kritische wp2shell-Lücke (CVSS 9.8) erlaubte Angriffe ohne Login. Was WordPress 7.0.2 behebt, wie Sie prüfen, ob Sie…