WordPress 7.1.4: 22 Sicherheitslücken geschlossen, eine davon ganz ohne Benutzerkonto ausnutzbar

WordPress 7.1.4 ist seit dem 28. Oktober 2026 verfügbar und schließt nach Angaben von WordPress.org 22 Sicherheitslücken aus 17 Advisories. Die meisten davon setzen ein bestehendes Benutzerkonto voraus, oft reicht schon die Rolle Mitwirkender. Eine Ausnahme sticht heraus: eine Wettlaufbedingung im Update-Prozess, die sich ganz ohne Anmeldung auslösen ließ und am Ende zur Codeausführung auf dem Server führen konnte. Wer sein Backend automatisch aktualisiert, hat das Update längst. Wer manuell aktualisiert, sollte das heute erledigen.

Was ist passiert?

Unter den 22 behobenen Lücken sind Schwachstellen für gespeichertes Cross-Site-Scripting, das Offenlegen von Informationen, fehlerhafte Rechteprüfungen und Denial of Service. Die kritischste betrifft den internen Ablauf, mit dem WordPress Kernupdates herunterlädt und installiert: Durch eine Race Condition ließ sich dieser Ablauf in einem kurzen Zeitfenster anstoßen, bevor die zuständige Berechtigungsprüfung griff — und das ohne jedes Benutzerkonto. Am Ende der Kette stand die Möglichkeit, eigenen Code auf dem Server auszuführen. Technisch ist das ein seltener Fall: Die meisten Sicherheitslücken in WordPress-Kern und Plugins setzen voraus, dass sich jemand erst anmeldet, wenigstens mit der schwächsten Rolle. Hier reichte der richtige Moment während eines laufenden Updates.

Daneben hatte der Customizer, also die Live-Vorschau für Designänderungen, einen Fehler, durch den noch unveröffentlichte Gestaltungsänderungen auch Besuchern ohne Anmeldung sichtbar wurden. Wer also an einem neuen Erscheinungsbild arbeitet und den Entwurf zwischenzeitlich liegen lässt, konnte ihn ungewollt öffentlich machen, bevor er fertig war. Mehrere Standardblöcke des Block-Editors — Kategorien, Kommentar-Seitennummerierung, Beitragsnavigation — waren zudem anfällig für gespeichertes XSS, wenn ein Mitwirkender bestimmte Eingaben in den Blockeinstellungen setzen konnte; das betrifft vor allem Websites mit mehreren Redakteuren oder offener Registrierung. Patchstack, das mehrere der Lücken mitgemeldet hat, bestätigt den Umfang unabhängig von WordPress selbst. Backports erschienen am gleichen Tag für alle unterstützten Versionszweige zurück bis 4.7.39 — WordPress pflegt also auch über ein Jahrzehnt alte Installationen noch mit, solange sie die automatischen Sicherheitsupdates nicht abgeschaltet haben.

Was bedeutet das für Ihre Website?

Für die meisten Websites ändert sich praktisch nichts, wenn automatische Hintergrundupdates aktiv sind — das ist bei WordPress-Standardinstallationen für kleinere Sicherheitsreleases wie dieses der Normalfall. Relevant wird es, wenn automatische Updates deaktiviert wurden (häufig bei Managed-Hosting mit eigenem Update-Fenster oder bei Agenturen, die Updates bewusst manuell freigeben) oder wenn mehrere Personen mit der Rolle Mitwirkender oder Autor im Backend arbeiten, etwa externe Redakteure oder Praktikanten. Dann lohnt ein Blick, wer aktuell welche Rolle hat. Die Customizer-Lücke betrifft vor allem Websites, die Designänderungen länger als Entwurf liegen lassen, bevor sie live gehen — ein Vorgehen, das ich ohnehin nicht empfehle, weil Entwürfe schnell veralten und am Ende doch anders aussehen, wenn sie endlich veröffentlicht werden.

Für Betreiber, die ihr WordPress selbst pflegen, ist die eigentliche Lehre eine andere: Je länger ein Update ansteht, desto größer das Zeitfenster für genau solche Angriffe. Die kritische Lücke in 7.1.4 wirkte nur während eines laufenden Updatevorgangs — wer ohnehin zügig aktualisiert, war dem Risiko also nur kurz ausgesetzt. Wer Updates dagegen wochenlang vor sich herschiebt, vergrößert die Angriffsfläche für jede Art von Sicherheitslücke, nicht nur für diese eine.

Was ist jetzt zu tun (und was nicht)?

• Im Backend unter Dashboard → Aktualisierungen prüfen, ob bereits Version 7.1.4 läuft. Steht dort eine ältere Version, einmal manuell auf „Jetzt aktualisieren“ klicken.
• Unter Benutzer → Alle Benutzer kurz durchgehen, wer die Rolle Mitwirkender oder Autor hat, und nicht mehr benötigte Zugänge entfernen.
• Laufende Customizer-Entwürfe zügig veröffentlichen oder verwerfen, statt sie unbegrenzt als Entwurf stehen zu lassen.
• Ein Sicherheits-Plugin wie Wordfence meldet in der Regel selbst, sobald eine neue Version verfügbar ist — die Meldung ernst nehmen, auch wenn sie unauffällig aussieht.

Nicht nötig: Plugins oder Theme wegen dieser Lücke austauschen, Backups wiederherstellen oder Passwörter ändern, wenn die Website ohnehin automatisch aktualisiert wurde. Das wäre Aufwand ohne erkennbaren Nutzen, solange keine konkreten Anzeichen für einen bereits erfolgten Zugriff vorliegen (etwa unbekannte Benutzerkonten oder veränderte Dateien).

Grundsätzliches zu meiner Arbeit mit dem System steht auf der Seite WordPress-Agentur. Den vorherigen Sicherheitsrelease aus dieser Reihe, 7.1.3, habe ich im Beitrag dazu eingeordnet — die Updates kommen in dichter Folge, was für das Projekt spricht, nicht dagegen. Wer unsicher ist, ob die eigene Website automatisch aktualisiert oder nicht, kann das kurz bei mir anfragen.

Quellen

WordPress News: WordPress 7.1.4 Sicherheitsrelease
Patchstack: WordPress 7.1.4 Security Release

Kurz beantwortet

Muss ich bei WordPress 7.1.4 selbst etwas tun?

Nur, wenn automatische Updates deaktiviert sind. Dann im Backend unter Aktualisierungen manuell auf 7.1.4 aktualisieren.

Ist meine Website ohne Benutzerkonten wirklich sicher?

Die kritischste Lücke brauchte kein Konto, war aber an den Moment eines laufenden Kernupdates gebunden. Mit 7.1.4 ist sie geschlossen.

Woran erkenne ich, ob meine Seite schon aktualisiert wurde?

Im Backend unter Dashboard → Startseite oder unter Aktualisierungen steht die aktuell installierte Version.