Technik & Sicherheit · · 7 Min. Lesezeit · Von Alexander
WordPress 7.1.4: Was die Update-Lücke für Ihre Website bedeutet
WordPress hat am 28. Oktober 2026 die Version 7.1.4 veröffentlicht und empfiehlt deren sofortige Installation. Sie behebt eine Race Condition im Core-Updater, also einen Fehler im zeitlichen Ablauf der Aktualisierung. Dabei kann eine kurzzeitig entpackte WordPress-Kopie über das Web erreichbar sein. Unter passenden Bedingungen wäre die Ausführung fremden Codes ohne WordPress-Konto möglich. Das Angriffsfenster ist laut Patchstack kurz; eine aktive Ausnutzung dieser konkreten Lücke ist in den geprüften Quellen nicht belegt.

Was ist bei WordPress 7.1.4 passiert?
Beim Core-Update entpackt WordPress die neue Version unter `wp-content/upgrade/`. Vor der Korrektur war der Arbeitsordnername aus dem Paketnamen ableitbar. Laut Patchstack konnte ein Angreifer den dort über das Web erreichbaren Installer mit einer eigenen Datenbank verbinden und fremden Code ausführen, wenn er den Pfad rechtzeitig traf und der Installer ausführbar war.
Dafür benötigt der Angreifer kein WordPress-Konto. Daraus folgt keine Berechtigung, selbst ein Core-Update auszulösen. Der beschriebene Angriff setzt ein laufendes Update voraus. Patchstack spricht von wenigen Sekunden; eine feste Dauer ist nicht belegt.
Der Patch ergänzt den Arbeitsordnernamen um 16 zufällige Zeichen, legt eine `index.php` an beziehungsweise erhält sie und schließt eine dort entstandene `wp-config.php` vom Kopieren aus. Weitere Korrekturen betreffen eingeschleusten Browsercode (XSS), Dienststörungen (DoS), Informationslecks und Berechtigungen. Die Quellen zählen diese Probleme unterschiedlich.
Wie gefährlich ist die Update-Lücke wirklich?
Patchstack zeigt einen CVSS-Score von 9 und zugleich „Low priority / No impactful threat“, also geringe Priorität und laut Anbieter keine erhebliche Bedrohung. WPScan nennt 8,1 und „high“. Die jeweilige CVSS-Version und die vollständigen Bewertungsparameter bleiben offen. Eine CVE- oder GHSA-Kennung wurde in der Recherche nicht bestätigt.
Die technischen Bewertungen und Patchstacks praktische Priorität sind getrennt zu lesen. Patchstack begründet die geringe Priorität mit dem kurzen Zeitfenster: Ein Angreifer müsste den richtigen Pfad im entscheidenden Moment erreichen. Das erschwert einen Angriff, schließt ihn aber nicht aus.
Stand 29. Oktober 2026 ist in den geprüften Quellen weder eine erfolgreiche Ausnutzung noch ein verifizierter öffentlicher, ausführbarer Angriffsnachweis (Proof of Concept) belegt. Das beweist keine Angriffsfreiheit. Verdächtige Anfragen, blockierte Versuche und erfolgreiche HTTP-Abrufe allein belegen keinen Einbruch. Installieren Sie das Sicherheitsupdate zeitnah.
Welche WordPress-Versionen sind sicher?
„Sicher“ bedeutet hier ausschließlich: Die für den jeweiligen Versionszweig vorgesehenen Korrekturen dieses Releases sind enthalten. Die folgenden Sicherheitsstände wurden am 28. Oktober 2026 veröffentlicht. Ältere Patchstände innerhalb desselben Zweigs müssen aktualisiert werden. Ein passender Backport, also ein Sicherheitsupdate für einen älteren Zweig, genügt für diese Korrekturen.
- 7.1.4, 7.0.8, 6.9.11, 6.8.12
- 6.7.11, 6.6.11, 6.5.14, 6.4.14
- 6.3.14, 6.2.15, 6.1.16, 6.0.18
- 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24
- 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31
- 4.9.35, 4.8.34, 4.7.39
Aktiv unterstützt wird ausschließlich die neueste WordPress-Hauptversion. Backports versprechen keine dauerhafte Pflege alter Installationen. WordPress 4.6 und ältere Zweige erhielten mit diesem Release keinen Backport; ihre historische Betroffenheit ist nicht vollständig geprüft. Planen Sie bei solchen Altständen mit Ihrer Betreuung einen kontrollierten Wechsel auf eine unterstützte Version.
Wie prüfe ich, ob meine Website betroffen ist?
Lesen Sie die Version im Backend unter „Dashboard → Start → Auf einen Blick“ ab, alternativ unter „Werkzeuge → Website-Zustand → Bericht/Info → WordPress“. Unter „Dashboard → Aktualisierungen“ finden Sie angebotene Core-Updates. Sichern Sie vorher Dateien und Datenbank. Kontrollieren Sie auch nach automatischen Updates die tatsächlich installierte Version; aktivierte Hintergrundupdates bestätigen keinen erfolgreichen Abschluss.
In Plesk öffnen Sie, falls verfügbar, unter „WordPress“ das WP Toolkit, wählen die Installation und deren Core-Aktualisierung. Lassen Sie den angebotenen Wiederherstellungspunkt aktiviert. Bei cPanel liegt das Werkzeug, sofern freigeschaltet, unter „Domains → WP Toolkit“. Die Verfügbarkeit im Shared Hosting hängt von der Hosting-Konfiguration ab. Fehlt es, nutzen Sie das WordPress-Backend oder beauftragen Ihren Hoster.
Für Administratoren: Im Verzeichnis der richtigen Installation zeigt `wp core version` den Stand; `wp core update --minor` aktualisiert nach dem Backup innerhalb des Zweigs. Eine explizite Zielversion verlangt eine bewusste Zweigentscheidung. Bei Updatefehlern schalten Sie Ihre Betreuung ein.
Was muss ich meinem Hoster schreiben?
Diese Vorlage können Sie zusammenhängend kopieren und ergänzen:
„Betreff: Bitte WordPress-Core-Sicherheitsupdate und Upgrade-Verzeichnis prüfen. Guten Tag, bitte prüfen Sie meine WordPress-Installation unter [Domain] zum Sicherheitsrelease vom 28. Oktober 2026. Welche Core-Version ist installiert? Wann wurde das letzte Core-Update gestartet und erfolgreich beendet, einschließlich Zeitzone? Lief es automatisch oder manuell? Falls ein älterer Zweig bleibt: Welche Backport-Version ist installiert und enthält sie den Fix für die Upgrade-Race-Condition? Ist `wp-content/upgrade/` einschließlich Unterverzeichnissen über das Web erreichbar oder auflistbar? Sind direkte PHP-Aufrufe dort auch am Origin-Server, also dem eigentlichen Webserver hinter einem vorgeschalteten Schutzdienst, gesperrt? Bitte prüfen Sie Zugriffs- und Fehlerlogs rund um die Updatezeit auf Aufrufe entpackter Installationsdateien und verdächtige Folgeaktivität. Unterscheiden Sie blockierte Versuche, erfolgreiche HTTP-Abrufe und nachgewiesene Veränderungen. Prüfen Sie nach fehlgeschlagenen Updates auch zurückgebliebene Entpackverzeichnisse und deren Erreichbarkeit. Welches aktuelle Backup von Dateien und Datenbank ist vorhanden, wie erfolgt die Wiederherstellung und welchen Datenstand würde sie liefern? Falls das Update aussteht: Wann können Sie es durchführen und welche zeitweilige Zugriffssperre können Sie einrichten? Bitte bestätigen Sie anschließend Version und Funktionsprüfung. Vielen Dank und freundliche Grüße, [Name / Kundennummer]“
Was tun, wenn das Update nicht sofort geht?
Der Patch bleibt die Hauptmaßnahme. Für die Zwischenzeit empfiehlt Patchstack, Webzugriffe auf `wp-content/upgrade/` serverseitig zu sperren und die Verzeichnisauflistung zu verhindern. Eine leere Verzeichnisansicht beweist keine Sperre direkter Dateiabrufe. Der Hoster sollte Unterverzeichnisse, PHP-Aufrufe und direkten Origin-Zugriff mitprüfen. Eine Schutzdatei allein im temporären Ordner ist unzuverlässig: Die Bereinigung kann sie entfernen. Die Sperre gehört außerhalb dieses Löschbereichs konfiguriert.
Eine ausdrücklich eingerichtete Pfadsperre in Cloudflare oder einer anderen Web Application Firewall (WAF) kann helfen. Automatischer Schutz gegen diesen Fehler ist nicht belegt; ein direkt erreichbarer Origin kann vorgeschalteten Schutz umgehen. Laut Patchstack lädt die entpackte Kopie die als WordPress-Plugin laufende PHP-Firewall der eigentlichen Website nicht. Das lässt sich nicht pauschal auf serverseitige Schutzsysteme übertragen.
Diese Ergänzungen zur Serversperre sind technische Ableitungen, keine offiziell getestete WordPress-Konfigurationsanleitung. Wenn weder Update noch wirksame Sperre zeitnah möglich sind, besprechen Sie als letzte Maßnahme eine befristete Offline-Schaltung mit dem Hoster. Diese redaktionelle Abwägung bedeutet eine Unterbrechung der Erreichbarkeit Ihrer Website.
Was sollte ich nach dem Update testen?
Rufen Sie Startseite, wichtige Unterseiten und Navigation auf. Testen Sie Login, Editor, Medien und Formulare. Bei Shops prüfen Sie Warenkorb, Checkout und Benachrichtigungen in einem geeigneten Testablauf. Lesen Sie die WordPress-Version erneut ab und prüfen Sie bei Darstellungsfehlern den verwendeten Cache.
Kontrollieren Sie außerdem, ob ein aktuelles Backup von Dateien und Datenbank vorhanden ist. Klären Sie, wie und mit welchem Datenstand es wiederhergestellt werden kann.
Administratoren können `wp core verify-checksums` ausführen. Der Vergleich der Core-Dateien mit WordPress.org beweist keine vollständig saubere Website: Datenbank, eigene Konfiguration und sämtliche Erweiterungen werden nicht abschließend geprüft. Auffälligkeiten erfordern eine breitere Untersuchung.
Häufige Fragen zur WordPress-Update-Lücke
Meine Plugins sind aktuell – reicht das?
Nein. Die Korrektur betrifft den WordPress-Core-Updater. Aktuelle Plugins und Themes bleiben wichtig, ersetzen diesen Core-Patch aber nicht.
Schützt Cloudflare meine Website?
Die Nutzung allein belegt keinen Schutz gegen diesen Fehler. Eine wirksame Pfadsperre kann helfen, wenn der Origin-Server nicht direkt erreichbar ist. Die serverseitige Sperre bleibt sinnvoll.
Betrifft mich die Lücke bei einem statischen Website-Export?
Ein reiner HTML-Auftritt ohne erreichbare WordPress- oder PHP-Installation hat diesen Core-Update-Angriffsweg nicht. Bleibt das WordPress-Backend öffentlich erreichbar, muss diese Installation separat geprüft werden.
Muss ich auf 7.1.4 wechseln oder reicht ein Backport?
Der passende Backport enthält die für seinen Zweig vorgesehenen Korrekturen dieses Releases. Langfristig sollte die Installation auf die aktiv unterstützte Hauptversion wechseln.
Wurde meine Website bereits gehackt?
Weder die Versionsnummer noch ein einzelner Logeintrag belegen das. Lassen Sie verdächtige Dateien, unerwartete Benutzer, Konfigurationsänderungen und Logs gemeinsam prüfen. Ein Update entfernt eine frühere Kompromittierung nicht automatisch.
Was muss ich nach dem Update testen?
Nutzen Sie die obige Prüfliste einschließlich Formularen und gegebenenfalls Shop-Funktionen. Kontrollieren Sie danach die installierte Version und klären Sie Backup und Wiederherstellung.