WordPress 7.0.4: die zweite kritische Lücke in vier Wochen — und was 7.0.3 noch geschlossen hat

Wer im Juli nach wp2shell auf 7.0.2 aktualisiert und dann aufgeatmet hat, sollte noch einmal ins Dashboard schauen. Innerhalb von vier Wochen erschienen zwei weitere Sicherheits-Releases, und beide sind keine Kosmetik.

7.0.3 (6. August 2026): zwölf Lücken auf einmal

Das Sammel-Release schließt zwölf Schwachstellen. Die gewichtigste ist ein reflektiertes Cross-Site-Scripting auf der Login-Seite, das ohne Anmeldung ausgelöst werden kann und unter bestimmten Bedingungen bis zur Ausführung von PHP-Code reicht (CVE-2026-64638). Der Angriffsweg läuft über eine manipulierte fremde Website, auf die ein Administrator klickt — also klassisches Phishing, diesmal mit technischem Rückenwind.

Dazu kommen mehrere gespeicherte XSS-Lücken für Nutzer ab der Rolle „Mitarbeiter” (Post-Datum-Block, Emoji-Einstellungen, Schnellbearbeitung), eine Rechteausweitung in Multisite-Installationen mit offener Registrierung, eine Informationspreisgabe über den Block „Neueste Kommentare” bei passwortgeschützten Beiträgen und eine serverseitige Anfragefälschung (SSRF) in der URL-Prüfung. Für eine Firmenseite mit einem einzigen Admin sind die Mitarbeiter-Lücken egal; für Magazine, Verbandsseiten und alles mit Gastautoren sind sie es nicht.

7.0.4 (12. August 2026): ein Bild, das Code ausführt

Die Lücke CVE-2026-65640 steckt in der Bildverarbeitung. WordPress hat beim Upload der Dateiendung vertraut — die Bibliothek ImageMagick dagegen schaut in den Inhalt. Eine Datei, die .png heißt, aber PostScript enthält, kam so durch die Upload-Prüfung, wurde zur Vorschaubild-Erzeugung an ImageMagick gereicht, und das übergab sie an Ghostscript, das PostScript als Programm ausführt. Ergebnis: Codeausführung auf dem Server.

Voraussetzung ist ein Konto mit mindestens Autor-Rechten sowie ein Server, der Bilder mit Imagick und Ghostscript verarbeitet — was bei den meisten deutschen Hostern der Fall ist. Der Fehler war fast zehn Jahre alt; die Korrektur wurde deshalb in alle Zweige bis hinunter zu 4.7 zurückportiert. Eine 6.9.x oder 6.8.x hat also ebenfalls ein Update bekommen, und zwar am selben Tag.

Was das für Betreiber heißt

Drei Sicherheits-Releases in vier Wochen sind kein Ausreißer, sondern der neue Takt. Zwei Konsequenzen:

Erstens: Die Hauptversion sagt nichts mehr. „Ich habe 7.0” ist keine Aussage. 7.0.1 ist ohne Login übernehmbar, 7.0.2 hat die Login-Lücke, 7.0.3 die Bild-Lücke. Erst 7.0.4 ist im 7.0-Zweig vollständig — und seit dem 19. August gibt es 7.1, das alle Korrekturen enthält. Wer auf 7.0.4 bleibt, ist sicher, denn WordPress pflegt den Zweig weiter (ebenso 6.9 mit 6.9.7 und 6.8 mit 6.8.8); wer auf 7.1 geht, sollte vorher die Plugins gegen die neue Bildverarbeitung prüfen, die jetzt im Browser statt auf dem Server skaliert. Unser Alters-Check zählt deshalb seit heute auf, welche der drei Releases einer Seite fehlen.

Zweitens: Rollen prüfen. Die Bild-Lücke braucht ein Autoren-Konto. Wer Gastautoren, ehemalige Mitarbeiter oder eine Agentur von 2019 noch als Autor in der Benutzerliste hat, sollte das ausmisten — unabhängig vom Update. Jedes Konto, das niemand mehr braucht, ist ein Konto, das jemand anders brauchen kann.

Selbst erledigen oder erledigen lassen

Das Update selbst ist Routine: Backup, Dashboard → Aktualisierungen, prüfen, ob die Seite danach noch läuft. Die Routine ist auch das Problem — sie muss jetzt alle paar Wochen stattfinden, sicherheitskritische Releases am besten am Erscheinungstag. Genau das ist der Unterschied zwischen unseren Care-Plänen: Bei „Grundschutz” laufen Updates monatlich, bei „Werkstatt” wöchentlich, bei „Standleitung” kommen sicherheitskritische Releases am Tag ihres Erscheinens, vorher auf einer Staging-Kopie getestet. Was von den dreien passt, hängt davon ab, wie viel an der Seite hängt.