WordPress Security Release 7.0.3: Kritische XSS-Lücke im Login-Screen geschlossen

Wenn WordPress ein Sicherheitsupdate außer der Reihe veröffentlicht, lohnt sich ein genauer Blick. Mit dem WordPress Security Release 7.0.3 hat das Core-Team gleich zwölf Schwachstellen adressiert. Darunter eine, die mit einem CVSS-Score von 8.9/10 in den High-Severity-Bereich fällt. Für Betreiber produktiver Websites, Shops und Plattformen bedeutet das: zeitnahes Handeln, nicht Abwarten.

Wir bei ROCKITdigital verfolgen jede Core-Veröffentlichung datengetrieben und ordnen ein, was für unsere Kunden operativ relevant ist. In diesem Beitrag erläutere ich, welche Lücken der Patch schließt, welche davon Priorität haben, und was Entscheider jetzt in ihren WordPress-Setups prüfen sollten.

Was das WordPress Security Release 7.0.3 leistet

Das offizielle Announcement fasst die zwölf Schwachstellen knapp zusammen, verzichtet aber weitgehend auf Severity-Bewertungen. Das ist typisch für die WordPress-Kommunikation, macht es für Betreiber allerdings nicht einfacher, die Dringlichkeit einzuschätzen. Historisch waren Core-Vulnerabilities in WordPress eher selten, doch im aktuellen Zyklus sehen wir eine ungewöhnliche Häufung, was Beobachter unter anderem auf den Einsatz von KI-gestützten Analyse-Tools bei Sicherheitsforschern zurückführen.

Die zwölf gepatchten Schwachstellen im Überblick:

• Stored XSS im Post-Date-Block (ab Rolle Contributor)
• Stored XSS im Post-Content-Block (ab Rolle Contributor)
• Information Disclosure im Latest-Comments-Block: Kommentare zu passwortgeschützten Beiträgen sichtbar
• Bypass des E-Mail-Bestätigungsprozesses
• CSS-Injection über das Safe-CSS-Filter-Bypass (ab Rolle Author)
• Stored XSS in Beiträgen über das Emoji-Settings-Element (ab Contributor)
• Privilege Escalation in Multisite-Netzwerken mit aktivierter User-Registration
• Server-Side Request Forgery (SSRF) über URL-Validierung mit Zugriff auf link-local Ranges
• Pre-Auth Reflected XSS auf dem Login-Screen mit potenzieller PHP-Codeausführung
• Offenlegung von Notes in Comment Feeds
• Enumeration von Post-Slugs
• Stored XSS in Quick Edit auf Sites mit sehr vielen Nutzern (ab Contributor)

Zwölf Einträge auf einer Liste klingen sind viel. Doch nicht jede Schwachstelle ist gleich kritisch. Drei davon sollten Betreiber besonders im Blick haben.

Die drei kritischsten Schwachstellen im Detail

Pre-Auth XSS auf dem Login-Screen (High Severity, 8.9/10)

Der prominenteste Eintrag ist die Pre-Authentication Cross-Site-Scripting-Lücke auf dem Login-Screen. „Pre-Auth“ heißt: Ein Angreifer benötigt keinen eigenen WordPress-Account, um die Schwachstelle zu adressieren. Erschwerend hinzu kommt das dokumentierte Potenzial zur PHP-Codeausführung, womit aus einem klassischen XSS ein Vektor werden kann, der weit über das Browserfenster hinausreicht.

Die Entwarnung, soweit man sie überhaupt geben kann: Die Ausnutzung erfordert User-Interaktion. Konkret muss ein eingeloggter oder einzuloggender Nutzer per Social Engineering dazu gebracht werden, eine präparierte Aktion auszulösen. In Zeiten gezielter Phishing-Kampagnen gegen Redakteure, Administratoren und Shop-Betreiber ist das allerdings kein Hindernis, das ernsthaft beruhigen sollte.

SSRF über link-local Ranges

Server-Side Request Forgery bedeutet, dass der Server durch manipulierte Eingaben dazu gebracht wird, Requests an Ziele zu senden, die aus dem öffentlichen Netz nicht erreichbar sein sollten. Link-local IP-Ranges sind für interne Kommunikation reserviert, so zum Beispiel Metadaten-Endpunkte von Cloud-Instanzen. Genau dort liegen in vielen Setups Access-Tokens, Konfigurationen oder andere sensible Informationen.

Da WordPress zur konkreten Ausnutzbarkeit bislang wenig Details veröffentlicht, bleibt eine belastbare Einordnung schwierig. Aus Erfahrung wissen wir: SSRF-Lücken werden häufig unterschätzt, entfalten in gehosteten Umgebungen aber schnell erhebliche Sprengkraft. 🔒

Privilege Escalation in Multisite-Netzwerken

In WordPress-Multisite-Installationen mit aktiver User-Registration kann ein Nutzer eine neue Site im Netzwerk anlegen ohne dazu berechtigt zu sein. Für klassische Einzelinstallationen ist das kein Thema. Wer aber Multisite betreibt, oft typisch für WordPress-Installationen von Hochschulen, Verlagen, größere Konzern-Portalen oder Plattform-Modellen, sollte den Patch mit Priorität einspielen.

Was Betreiber jetzt konkret tun sollten

Die gute Nachricht: WordPress-Sites mit aktivierten Auto-Updates für Minor-Releases haben den Patch in der Regel bereits erhalten. Wer Updates manuell steuert, bei größeren Projekten, Shops und Enterprise-Setups die Regel, sollte jetzt priorisieren.

Aus unserer Beratungspraxis empfehlen wir folgendes Vorgehen:

• Version prüfen: Läuft die Installation bereits auf 7.0.3? Bei älteren Major-Versionen prüfen, ob Backports verfügbar sind.
• Staging-Deployment: Update zuerst in einer identischen Staging-Umgebung einspielen und Regressionstests fahren – insbesondere für Custom-Blocks, Gutenberg-Anpassungen und Login-Flows.
• Multisite-Netzwerke: User-Registration temporär deaktivieren, bis der Patch produktiv aktiv ist.
• Login-Härtung: Zusätzlich zur XSS-Behebung Zwei-Faktor-Authentifizierung erzwingen, Login-URL nicht öffentlich exponieren und WAF-Regeln aktualisieren.
• Logs prüfen: Ungewöhnliche Requests auf wp-login.php, verdächtige Redirects oder auffällige SSRF-Muster in den Access-Logs identifizieren.

Warum Core-Updates strategisch geplant sein müssen

Ein Sicherheitsupdate ist selten nur ein Klick. In produktiven Umgebungen mit Custom Themes, spezialisierten Plugins und E-Commerce-Layern kann ein Minor-Release durchaus Nebenwirkungen haben. Etwa dann, wenn Third-Party-Code an Core-Funktionen andockt, die intern angepasst wurden. Genau hier zeigt sich, ob eine WordPress-Architektur sauber aufgesetzt wurde, oder ob jedes Update zur Zitterpartie wird.

Wir betreiben im Firmenverbund selbst profitable WordPress-basierte E-Commerce-Projekte. Aus dieser operativen Praxis heraus wissen wir: Wer Updates orchestriert, basierend auf automatisierten Deployment-Pipelines, sauberen Staging- bzw. Dev-Umgebungen und dokumentierten Rollback-Szenarien, kann auch ein High-Severity-Patch wie das WordPress Security Release 7.0.3 einspielen.

Einordnung: Ein Weckruf, aber kein Grund zur Panik

Die Häufung von Core-Vulnerabilities in den letzten Zyklen ist bemerkenswert, aber nicht überraschend. Sicherheitsforscher bzw. Cyper-Security-Spezialisten setzen zunehmend KI-gestützte Tools ein, die statische und dynamische Analyse skalieren. Für WordPress als Plattform mit über 40 Prozent Marktanteil im CMS-Segment ist das mittelfristig sogar eine gute Nachricht: Mehr Augen, mehr gefundene Lücken, mehr geschlossene Einfallstore.

Für Betreiber heißt das aber auch, dass die Zeiten, in denen ein Core-Update mal ein Quartal warten konnte, endgültig vorbei sind. Sicherheit ist kein Zustand, sondern ein Prozess, und der braucht Struktur, Verantwortlichkeit und ein Team, das weiß, was es tut.

Der letzte Ton ist noch nicht gespielt

Zwölf gepatchte Schwachstellen, eine davon hochkritisch: Das WordPress Security Release 7.0.3 ist ein deutliches Signal, dass Core-Sicherheit permanente Aufmerksamkeit verlangt. Wer WordPress produktiv betreibt, sollte den Patch nicht als lästige Pflicht sehen, sondern als Gelegenheit, die eigene Update- und Sicherheitsstrategie einmal grundsätzlich zu prüfen.

Wenn Sie unsicher sind, ob Ihre WordPress-Infrastruktur den aktuellen Anforderungen standhält, von Multisite-Setups über E-Commerce-Plattformen bis zu individuellen Redaktionssystemen, bringen wir gerne Klarheit ins Spiel. Wir glauben nicht, wir wissen: Ein professionelles Security-Audit deckt auf, wo Ihre Risiken tatsächlich liegen und welche Maßnahmen wirken.

Sprechen Sie mit uns über Ihre WordPress-Sicherheitsstrategie: über unser Kontaktformular oder telefonisch unter +49 (0)89 12 22 30 6-10. Wir freuen uns darauf, Ihr WordPress-Setup gemeinsam auf ein belastbares Fundament zu stellen.