WordPress 7.0.3: 12 Sicherheitslücken geschlossen

WordPress 7.0.3 ist am 6. August 2026 erschienen und schliesst zwölf Sicherheitslücken. Drei Wochen nach wp2shell klingt das nach dem nächsten Notfall — ist es aber nicht. Dieser Beitrag ordnet ein, was tatsächlich behoben wurde, welche der zwölf Lücken für Ihre Website überhaupt relevant ist, und warum «sofort handeln» diesmal etwas anderes bedeutet als im Juli.

Das Wichtigste in Kürze

Reines Sicherheitsrelease, zwölf Lücken. Keine Funktionsänderungen, zehn geänderte Kerndateien, kein aktualisiertes Paket — das Update-Risiko ist entsprechend gering.
Die schwerste Lücke ist «hoch», nicht kritisch. CVSS 8.9 mit hoher Angriffskomplexität und erforderlicher Benutzerinteraktion: Sie wirkt nur, wenn eine berechtigte Person auf einen präparierten Link klickt.
Fünf der zwölf brauchen ein Konto bei Ihnen. Wer keine fremden Redaktionskonten führt, ist von knapp der Hälfte gar nicht betroffen.
Betroffen sind alle Reihen von 4.7 bis 7.0.2. Die Korrekturen wurden zurückportiert; ab Version 4.6 abwärts gibt es keine Sicherheitsupdates mehr.
Zeitnah aktualisieren, nicht in Panik verfallen. Anders als bei wp2shell im Juli ist keine Bereinigung nötig — es gibt keine belegten Hinweise auf Ausnutzung vor der Veröffentlichung.

Was 7.0.3 behebt

7.0.3 ist ein reines Sicherheitsrelease. Es enthält keine Wartungs-Bugfixes und keine Funktionsänderungen; laut offizieller Versionsdokumentation wurden zehn Kerndateien angepasst und kein einziges Paket aktualisiert. Wer nach dem Update etwas Neues sucht, findet nichts — und genau das ist die gute Nachricht, denn ein Sicherheitsupdate ohne Funktionsänderungen bricht auch nichts.

Entscheidend ist nicht, wie viele Lücken es sind, sondern was ein Angreifer jeweils braucht, um sie zu nutzen. Danach sortiert ergibt sich ein deutlich ruhigeres Bild:

Was der Angreifer braucht	Welche Lücken	Was das für Ihre Website heisst
Nichts — ausser einem Klick Ihrerseits	1 von 12: reflektiertes XSS auf der Anmeldeseite (CVE-2026-64638)	Der einzige Weg zu vollem Zugriff. Funktioniert nur bei einem gezielten Angriff auf eine bestimmte Person, nicht per Massenscan.
Ein Konto bei Ihnen (Mitarbeiter- oder Autorenrechte)	5 von 12: viermal gespeichertes XSS, einmal CSS-Injektion	Nur relevant, wenn Fremde bei Ihnen schreiben dürfen. Reine Firmenwebsites ohne Gastautoren sind hier aussen vor.
Eine offene Registrierung im Multisite-Netz	1 von 12: Rechteausweitung, Benutzer legt eigene Website an	Betrifft ausschliesslich Multisite-Installationen. Eine normale Website mit einer Domain nicht.
Nichts — kann aber nur mitlesen	3 von 12: Kommentare zu passwortgeschützten Beiträgen, Notizen in Feeds, aufzählbare Beitragsadressen	Kein Zugriff auf die Website, aber Inhalte werden sichtbar, die nicht öffentlich sein sollten.
Zugriff auf Serverebene oder einen Anmeldevorgang	2 von 12: Umgehung der E-Mail-Bestätigung, SSRF in der URL-Prüfung	Vor allem für selbst betriebene Server relevant, auf denen interne Adressbereiche erreichbar sind.

Nur eine der zwölf Lücken führt zu vollem Zugriff — und auch die nur, wenn jemand mit Adminrechten auf einen präparierten Link klickt.

Vollständige Liste mit allen Meldenden in der offiziellen Versionsdokumentation ↗.

Die eine Lücke, die heraussticht — und warum sie trotzdem kein wp2shell ist

CVE-2026-64638 ist die einzige der zwölf, die ohne jedes Konto erreichbar ist: ein reflektiertes Cross-Site-Scripting auf der Anmeldeseite. Die offizielle Ankündigung nennt «Potenzial zur Ausführung von PHP-Code», und das klingt zunächst nach derselben Kategorie wie die Lücke vom Juli.

Der Unterschied steckt in der Bewertung. Die Sicherheitsmeldung des WordPress-Projekts stuft sie mit CVSS 8.9 als «hoch» ein — nicht als kritisch. Zwei Angaben im Bewertungsvektor erklären, warum: eine hohe Angriffskomplexität und eine erforderliche Benutzerinteraktion. Im Klartext heisst das:

Reflektiert, nicht gespeichert. Der Schadcode liegt nicht auf Ihrer Website. Er wirkt nur im Browser der Person, die einen präparierten Link anklickt.
Gezielt, nicht flächendeckend. Ein Angreifer braucht eine bestimmte Person, auf einer bestimmten Website, die einen bestimmten Link öffnet. Automatisierte Massenscans nützen ihm nichts.
Der Weg zur Code-Ausführung führt über die Sitzung. Klickt tatsächlich eine Administratorin, kann der Angreifer deren angemeldete Sitzung übernehmen — und damit alles tun, was diese Person darf, einschliesslich eigenen Code auf die Website zu bringen.

Zum Vergleich: Die wp2shell-Kette im Juli war mit CVSS 9.8 bewertet und funktionierte ohne jede Mitwirkung — ein Skript genügte. Deshalb hiess es dort «sofort patchen und anschliessend prüfen, ob bereits jemand da war». Hier gilt: zeitnah aktualisieren, und die eigenen Konten anschauen. Wer die Unterschiede nachlesen möchte, findet sie in unserem Beitrag zu wp2shell und CVE-2026-63030.

Eine Einschränkung, die wir bewusst dazusagen: Der genaue technische Weg von der Sitzungsübernahme zur PHP-Ausführung wird in der offiziellen Sicherheitsmeldung nicht beschrieben. Unabhängige Analysen sprechen von der Möglichkeit, eigenen Code oder Plugins zu laden. Ob eine bestimmte Härtungsmassnahme diesen Weg blockiert, ist derzeit nicht belegt.

Wer wirklich handeln muss

Fast alle: einfach aktualisieren. Wenn Ihre Website automatische Hintergrundupdates zulässt — die Voreinstellung bei Nebenversionen —, ist sie vermutlich längst auf 7.0.3. Unsere eigene Installation war es bereits, ohne dass jemand etwas getan hätte. Nachprüfen können Sie es im Adminbereich unter «Werkzeuge → Website-Zustand» oder ganz unten auf jeder Seite des Dashboards.

Websites mit fremden Redaktionskonten: genauer hinsehen. Fünf der zwölf Lücken setzen ein Konto mit Mitarbeiter- oder Autorenrechten voraus. Für eine Firmenwebsite, auf der nur die Geschäftsleitung schreibt, ist das nachrangig. Für ein Portal mit offener Registrierung, externen Autorinnen oder Gastbeiträgen ist es der Punkt, an dem sich diese Woche etwas ändern sollte: Wer hat welche Rolle, und braucht die Person sie noch?

Multisite-Netzwerke mit offener Registrierung: hier ist es konkret. Die Rechteausweitung erlaubt es einem registrierten Benutzer, sich eine eigene Website im Netzwerk anzulegen. Das betrifft ausschliesslich Multisite-Installationen — normale WordPress-Websites nicht.

Wer noch auf einer älteren Version läuft: Die Korrekturen wurden bis zurück zu 4.7 zurückportiert. Eine 6.9 wird zu 6.9.6, eine 6.8 zu 6.8.7 und so weiter. Wichtig dabei: WordPress 4.6 und älter erhalten keine Sicherheitsupdates mehr. Wer dort steht, hat kein Update-Problem, sondern ein Migrationsprojekt.

Betroffene und sichere Versionen

Ihre Version	Betroffen von	Sicher ab
7.0.0 – 7.0.2	allen 12 Lücken	7.0.3
6.9.0 – 6.9.5	11 von 12	6.9.6
6.8, 6.7, 6.6, 6.5, 6.4, 6.3, 6.2, 6.1, 6.0, 5.9, 5.8	8 von 12	6.8.7 · 6.7.6 · 6.6.6 · 6.5.9 · 6.4.9 · 6.3.9 · 6.2.10 · 6.1.11 · 6.0.13 · 5.9.14 · 5.8.14
5.7 bis 4.7	7 von 12	je eigene Korrekturversion, bis 4.7.34
4.6 und älter	—	keine Sicherheitsupdates mehr

Die Korrekturen wurden bis zur Reihe 4.7 zurückportiert. Wer älter läuft, hat kein Update-Problem, sondern ein Migrationsprojekt.

Auch WordPress 7.1, das am 19. August erscheint, enthält bereits alle anwendbaren Korrekturen — der zweite Veröffentlichungskandidat wurde entsprechend nachgezogen. Was 7.1 sonst mitbringt und was daran heikel ist, steht in unserem Beitrag zu den Breaking Changes in 7.1.

Was jetzt zu tun ist

Version prüfen. Adminbereich, unten rechts auf dem Dashboard, oder «Werkzeuge → Website-Zustand». Steht dort 7.0.3, sind Sie fertig.
Falls nicht: aktualisieren. «Dashboard → Aktualisierungen → Jetzt aktualisieren». Bei einem reinen Sicherheitsrelease ohne Funktionsänderungen ist das Risiko gering — anders als bei einem Hauptversionssprung.
Benutzerkonten durchgehen. Fünf der zwölf Lücken brauchen ein Konto. Wer hat noch Zugang, den er nicht mehr braucht? Alte Redaktionskonten sind der häufigste blinde Fleck.
Bei Multisite: Registrierungseinstellungen anschauen. Ist die offene Registrierung aktiv und wird sie tatsächlich gebraucht?
Nicht nötig: eine Bereinigung wie nach wp2shell. Es gibt bislang keine belegten Hinweise auf eine Ausnutzung dieser Lücken vor der Veröffentlichung.

Falls Sie das nicht selbst machen möchten: Genau das ist der Inhalt eines Wartungsvertrags — Updates werden vor dem Einspielen auf einer Kopie geprüft, und wenn etwas bricht, gibt es einen Rückweg. Mehr dazu unter WordPress Support & Wartung und Security & Härtung.

Zwölf Lücken in einem Release — ist das viel?

Die Zahl wirkt hoch und wird entsprechend zitiert. Sie sagt aber weniger über die Qualität von WordPress aus, als man vermuten würde. Sicherheitsreleases bündeln, was über Wochen gemeldet wurde; zwölf Meldungen in einem Paket bedeuten nicht zwölf neue Fehler in einer Woche, sondern einen geordneten Sammel-Patch. Zehn der zwölf Lücken wurden von externen Forschenden gemeldet, zwei vom WordPress-Sicherheitsteam selbst — ein Zeichen dafür, dass das Meldeverfahren funktioniert. Lücken, die niemand meldet, werden nicht behoben.

Bemerkenswert ist eher, wer meldet. Unter den Meldenden dieses Releases finden sich neben dem WordPress-Sicherheitsteam und spezialisierten Firmen auch Namen aus dem KI-Umfeld. Das ist dieselbe Entwicklung, die im Juli bei wp2shell sichtbar wurde: Sicherheitsforschung wird schneller, und zwar auf beiden Seiten. Für Betreiberinnen und Betreiber heisst das nüchtern, dass der Abstand zwischen «Lücke bekannt» und «Lücke ausgenutzt» kleiner wird — und dass ein Update, das drei Wochen liegen bleibt, ein anderes Risiko ist als noch vor ein paar Jahren.

Häufige Fragen

Muss ich sofort handeln, so wie im Juli bei wp2shell?

Nein, die Lage ist eine andere. wp2shell war mit CVSS 9.8 bewertet und ohne jede Mitwirkung ausnutzbar — dort zählten Stunden. Die schwerste Lücke in 7.0.3 ist mit 8.9 als «hoch» eingestuft und braucht einen gezielten Angriff samt Klick durch eine berechtigte Person. Zeitnah aktualisieren genügt; die meisten Websites haben es ohnehin automatisch getan.

Kann das Update etwas kaputt machen?

Das Risiko ist gering. 7.0.3 ist ein reines Sicherheitsrelease ohne Funktionsänderungen; laut Versionsdokumentation wurden zehn Kerndateien angepasst und keine Pakete aktualisiert. Anders sieht es beim Sprung auf 7.1 am 19. August aus — dort gibt es echte Änderungen, die Themes und Plugins betreffen können.

Woher weiss ich, ob meine Website schon aktualisiert wurde?

Melden Sie sich im Adminbereich an; unten rechts auf dem Dashboard steht die Versionsnummer. Alternativ unter «Werkzeuge → Website-Zustand». Steht dort 7.0.3, ist nichts weiter zu tun. Steht dort eine ältere Nummer und es wird kein Update angeboten, sind die automatischen Updates womöglich deaktiviert — das ist einen Blick wert.

Wir betreiben eine ältere Version und wollen nicht auf 7.0 wechseln. Sind wir sicher?

Solange Ihre Versionsreihe noch Sicherheitsupdates erhält, ja — die Korrekturen wurden bis 4.7 zurückportiert, Sie brauchen dann die jeweilige Korrekturversion Ihrer Reihe. Ab 4.6 abwärts gibt es keine Sicherheitsupdates mehr; dort hilft nur eine Migration. Und bedenken Sie: Nur die jeweils neueste Version wird aktiv weiterentwickelt.

Betrifft mich die Multisite-Lücke?

Nur, wenn Sie ein Multisite-Netzwerk betreiben und die Benutzerregistrierung offen ist. Eine gewöhnliche WordPress-Installation mit einer Website ist davon nicht betroffen. Wenn Sie unsicher sind, ob Sie Multisite betreiben: Sie wüssten es — es wird bewusst eingerichtet.

Fazit

7.0.3 ist ein sauberes, unaufgeregtes Sicherheitsrelease: zwölf gemeldete Lücken, keine Funktionsänderungen, geringes Update-Risiko, und die schwerste davon braucht einen gezielten Angriff statt eines Skripts. Die praktische Konsequenz ist unspektakulär — Version prüfen, gegebenenfalls aktualisieren, Benutzerkonten durchgehen.

Interessanter als dieses eine Release ist das Muster dahinter. Nach wp2shell im Juli ist das der zweite Fall innert eines Monats, in dem Sicherheitsforschung schneller liefert als früher. Wer WordPress betreibt, kommt damit klar — aber nicht mehr dadurch, dass Updates «irgendwann» eingespielt werden. Wenn Sie das nicht selbst im Blick behalten möchten, ist genau das der Punkt, an dem sich eine laufende Betreuung rechnet.

Quellen

WordPress.org: WordPress 7.0.3 Release ↗ — offizielle Ankündigung vom 6. August 2026
WordPress.org: Version 7.0.3 ↗ — Versionsdokumentation mit vollständiger Lückenliste, geänderten Dateien und Backport-Versionen
Sicherheitsmeldung GHSA-52p2-r8wf-jcrf ↗ — CVE-2026-64638, CVSS 8.9, betroffene Versionsbereiche
Patchstack: WordPress 7.0.3 Released ↗ — Einordnung der Voraussetzungen je Lücke

Stand: 7. August 2026. Sicherheitslagen ändern sich; sollten nach Redaktionsschluss Hinweise auf aktive Ausnutzung auftauchen, aktualisieren wir diesen Beitrag.