WordPress 7.0.3 stopft 12 Lücken, der Login-XSS steht ganz oben auf der To-do-Liste

Am 6. August hat das WordPress-Team die Sicherheitsversion 7.0.3 ausgeliefert und dabei zwölf Schwachstellen quer durch den Kern geschlossen. Ganz oben auf der Liste steht ein Cross-Site-Scripting-Fehler auf der Login-Seite, der ohne Anmeldung ausgelöst werden kann und laut Release-Notiz das Potenzial hat, in eine Ausführung von PHP-Code zu kippen.

Für alle, die WordPress-Seiten für Kunden betreiben, ist das ein klarer Wartungsauftrag: Version prüfen, automatische Hintergrund-Updates einschalten, im Zweifel manuell aktualisieren. Betroffen sind alle Kernversionen ab 4.7 aufwärts, die passenden Backports werden nachgereicht.

Was 7.0.3 genau schließt

Release-Lead John Blackbourn listet in der offiziellen Ankündigung diese Kategorien auf:

• ein unauthentifizierter Reflected XSS auf dem Login-Bildschirm mit möglichem Weg zur PHP-Ausführung, gemeldet vom pwn.ai-Team
• vier Stored-XSS-Lücken auf Contributor-Ebene: in den Emoji-Einstellungen, im Post-Content-Block, im Post-Date-Block und im Quick-Edit-Panel großer Nutzerlisten
• eine Rechteausweitung im Multisite-Modus mit aktiver Nutzerregistrierung, gemeldet von Aikido Security
• drei Informationslecks: der Latest-Comments-Block gab Kommentare zu passwortgeschützten Beiträgen preis, Post-Slugs ließen sich enumerieren, Notizen tauchten in Kommentar-Feeds auf
• eine CSS-Injection ab Author-Rolle, die den Safe-CSS-Filter umging (gemeldet von Anthropic)
• ein Bypass der E-Mail-Bestätigung
• ein Server-Side-Request-Forgery-Fehler in der URL-Validierung, der Anfragen an link-local-Adressen erlaubte

Der Login-XSS trägt die Kennung CVE-2026-64638 (GitHub-Advisory GHSA-52p2-r8wf-jcrf). Die restlichen elf Fixes werden auf einen Schlag ausgeliefert, dedizierte CVE-Nummern sind teilweise noch nicht öffentlich verlinkt.

Warum der Login-XSS besonders zählt

Reflected XSS klingt nach „nur ein Browser-Fehler“, ist aber genau dann gefährlich, wenn er auf einer Seite sitzt, die Redakteure und Administratoren täglich öffnen. Ein präparierter Link, ein Klick aus einem Support-Ticket oder aus einer angeblich internen Slack-Nachricht, und schon läuft Angreifer-Code im Kontext einer angemeldeten Session. Der Weg von dort zu plugin-editor.php und einem Stück eingeschleustem PHP ist bekannt, kurz und in Post-Mortems ausführlich dokumentiert.

Dass die Lücke pre-auth ausgenutzt werden kann, verschiebt die Angriffsfläche vom internen Nutzer auf das offene Web: Jeder crawlbare Login-Screen ist ein potenzieller Landeplatz. Autoupdates auf 7.0.3 nehmen die Gefahr binnen Stunden aus dem Netz, händisch veraltete Installationen bleiben liegen.

Ungewöhnlich in dieser Runde: eine KI-Firma und eine Meldungswelle

Zwei Details fallen aus der üblichen Namensliste heraus. Erstens taucht in den Danksagungen für die CSS-Injection der Reporter Anthropic auf, also die Firma hinter Claude. Sicherheitsforschung ist bei KI-Laboren selten prominent, und ein WordPress-Kernbug im offiziellen Advisory einer Modell-Firma ist ein neues Bild.

Zweitens berichtet Patchstack, dass die Zahl der WordPress-Meldungen bei HackerOne 2026 spürbar gestiegen ist, im Juli auf rund 450 Reports, gegenüber üblichen zwei- bis dreißig Fällen pro Monat in den Vorjahren. Ein Teil davon geht laut Patchstack auf Modelle zurück, die eigenständig vom Fund zum Proof-of-Concept kommen. Für die Praxis bedeutet das: Die Frequenz der Sicherheitsreleases wird eher steigen als sinken, und der Wartungsplan für Kundenseiten sollte damit rechnen.

Was heute konkret zu tun ist

• Version prüfen: Im Dashboard unter „Aktualisierungen“ oder per WP-CLI mit wp core version. Alles unter 7.0.3 gehört heute aktualisiert.
• Autoupdates einschalten, wo möglich. WordPress rollt Sicherheitsreleases im Hintergrund aus, die Option muss aber am Host aktiv sein.
• Multisite mit offener Registrierung härten: Wenn Nutzer sich selbst anlegen dürfen, ist die Priorität dieses Releases höher.
• Login-URL im Auge behalten: kein blindes Anklicken von Login-Links aus Chats und Tickets, bis die Version durch ist.
• Ältere Zweige (bis 4.7) auf die passenden Backports warten und im Wartungsvertrag als Sonderposten einplanen.

Wer diese Wartungsarbeit fürs Kunden-Portfolio übernimmt, verkauft dabei nicht nur den Patch, sondern das Vertrauen, dass jemand hinschaut. Wenn dir noch die passenden Wartungskunden für so einen Service fehlen, hilft dir unser Leitfaden Webdesign-Leads gewinnen beim Aufbau der Pipeline.