WordPress-Sicherheitslücke CVE-2026-119977: Codeausführung während des Core-Updates – aktiv ausgenutzt, unsere Systeme sind aktualisiert

Stand: 5. November 2026

Kurzfassung

• WordPress hat am 28. Oktober 2026 die Sicherheitsversion 7.1.4 veröffentlicht. Sie schließt 22 Sicherheitslücken. Die schwerste (CVE-2026-119977, CVSS 8,1) erlaubt Codeausführung ohne Anmeldung – allerdings nur in einem kurzen Zeitfenster, während WordPress ein vollständiges Core-Update entpackt.
• Die US-Behörde CISA hat die Lücke am 3. November 2026 in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) aufgenommen. Wordfence zählte in den ersten 21 Stunden über 18.500 Anfragen auf die verwundbaren Pfade.
• Betroffen sind ungepatchte WordPress-Versionen von 4.7 bis 7.1.3. Korrigierte Versionen gibt es für jeden Zweig (z. B. 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11).
• Bei WEB-SHOP-HOSTING wurden die über das WP Toolkit verwalteten WordPress-Installationen mit aktivierten automatischen Updates in der Nacht vom 28. auf den 29. Oktober automatisch aktualisiert. Angriffsversuche auf unsere Server haben wir ab dem 29. Oktober in den Protokollen festgestellt; alle erfassten Anfragen wurden mit HTTP 403 oder 404 beantwortet. Es gibt keinen Hinweis auf eine erfolgreiche Ausnutzung. Für Installationen mit deaktivierten automatischen Updates gilt die gesonderte Prüfung in der Statusübersicht.
• Wer WordPress selbst betreibt oder automatische Updates deaktiviert hat, sollte zeitnah die Version prüfen und vor dem nächsten Core-Update den Ordner wp-content/upgrade/ für den Webzugriff sperren.

Was ist passiert?

Am 28. Oktober 2026 erschien WordPress 7.1.4 als Sicherheitsversion. Am 31. Oktober veröffentlichte Wordfence als CVE-Vergabestelle die Details zu CVE-2026-119977; gemeldet hatte die Lücke der Sicherheitsforscher Umut Bayram. Am 3. November nahm die CISA die Lücke in den KEV-Katalog auf und setzte den betroffenen zivilen US-Bundesbehörden eine Frist bis zum 6. November.

Der Fehler steckt im Update-Mechanismus von WordPress selbst (CWE-367, eine sogenannte TOCTOU-Race-Condition):

1. Bei einem vollständigen Core-Update entpackt WordPress das neue Paket in einen vorhersagbaren Ordner unterhalb von wp-content/upgrade/, zum Beispiel wp-content/upgrade/wordpress-7.1.4/.
2. Diese Zwischenkopie enthält den WordPress-Installer wp-admin/setup-config.php. Der Ordner liegt im Webroot und ist auf vielen Servern ohne Anmeldung erreichbar.
3. Wer den Installer in genau diesem Moment aufruft, kann eine Verbindung zu einer selbst kontrollierten Datenbank vorgeben. Die so erzeugte wp-config.php wurde beim Abschluss des Updates über die echte Konfiguration kopiert, weil wp-config.php nicht auf der Ausnahmeliste stand.
4. Die manipulierte Datenbankkonfiguration kann die Übernahme der Website und anschließend die Ausführung von PHP-Code ermöglichen.

Das Zeitfenster ist kurz – in Laborumgebungen wenige Sekunden. Angreifer fragen die Pfade deshalb automatisiert und fortlaufend ab, um ein laufendes Update zu treffen. Wordfence registrierte zwei Quellen, die kleine Gruppen von Websites rund 14,5 Stunden lang wiederholt abfragten.

WordPress 7.1.4 enthält drei Schutzmaßnahmen: Der Ordnername wird zufällig erzeugt, in wp-content/upgrade/ wird eine index.php angelegt, und wp-config.php wird beim Kopieren übersprungen.

Wichtig: Das Update auf 7.1.4 wird noch vom alten, ungepatchten Updater ausgeführt. Bei einem vollständigen Core-Update kann das Angriffsfenster deshalb auch beim Einspielen der Korrektur entstehen. Daher sollte wp-content/upgrade/ vor dem Update gesperrt werden (siehe Anleitung).

Welche Versionen sind betroffen?

Die Sicherheitskorrekturen wurden auf alle Zweige bis 4.7 zurückportiert. Offiziell unterstützt wird dennoch nur die jeweils aktuelle Version.

Status bei WEB-SHOP-HOSTING

Die automatischen Updates des WP Toolkits haben die Korrektur in den Stunden nach der Veröffentlichung eingespielt – noch bevor die ersten Scans auf unseren Servern eintrafen. Für Kunden, deren WordPress über das WP Toolkit bereits auf einen korrigierten Stand aktualisiert wurde, besteht wegen dieser Lücke kein weiterer Handlungsbedarf.

Die Protokollauswertung bezieht sich auf die bekannten Angriffspfade. HTTP-Statuscodes allein können eine Kompromittierung weder nachweisen noch vollständig ausschließen.

Was Sie tun sollten

1. Version prüfen: In Plesk unter *WordPress* (WP Toolkit) oder im WordPress-Dashboard unter *Dashboard → Aktualisierungen*. Korrigiert sind 7.1.4 und die oben genannten Versionen der jeweiligen Zweige.
2. Automatische Updates einschalten, falls Sie sie deaktiviert haben. Sperren Sie bei einer noch ungepatchten Installation zuerst wp-content/upgrade/ für den Webzugriff. Aktivieren Sie anschließend die Updates im WP Toolkit unter *Einstellungen → Automatische Updates → Core*.
3. Vor einem manuellen Update: wp-content/upgrade/ für den Webzugriff sperren (Anleitung unten). Danach aktualisieren.
4. Nachkontrolle, wenn ein Update seit dem 28. Oktober ohne Schutz lief: Prüfen Sie, ob in wp-config.php weiterhin die vorgesehenen Datenbankzugangsdaten stehen (DB_HOST, DB_NAME, DB_USER). Prüfen Sie außerdem die Administratorkonten auf unbekannte Einträge.
5. Plugins und Themes aktuell halten. 7.1.4 schließt daneben mehrere XSS-Lücken im Core; Plugins werden davon nicht abgedeckt.

Anleitung für Betreiber eigener Server

Nginx (im server-Block der Website, vor den PHP-Regeln):

location ^~ /wp-content/upgrade/ { deny all; return 403; }

Apache (.htaccess im WordPress-Verzeichnis oder vHost, jeweils vor bestehenden WordPress-Rewrite-Regeln):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/?wp-content/upgrade/ - [F,L]
</IfModule>

Die Apache-Regel setzt ein aktives mod_rewrite voraus. Bei Verwendung einer .htaccess muss die Serverkonfiguration die entsprechenden Direktiven zulassen; andernfalls ist die Regel nicht wirksam oder führt zu einem Konfigurationsfehler.

Die Nginx-Regel und die Apache-vHost-Regel gelten in dieser Form für WordPress im Hauptverzeichnis der Domain. Bei einer Installation in einem Unterverzeichnis müssen die URL-Pfade entsprechend angepasst werden. In der .htaccess direkt im WordPress-Verzeichnis bleibt das Muster relativ zu diesem Verzeichnis.

Nach Änderungen an der Serverkonfiguration führen Sie nginx -t && systemctl reload nginx bzw. apachectl configtest && systemctl reload apache2 aus. Änderungen an einer .htaccess benötigen keinen Reload. Prüfen Sie anschließend durch einen HTTP-Aufruf unterhalb von wp-content/upgrade/, auch auf einen PHP-Pfad, ob die Sperre tatsächlich mit HTTP 403 greift.

WordPress benötigt für den Ordner nur Dateisystemzugriff, keinen Webzugriff – das Update funktioniert weiterhin.

Plesk: Unter *Websites & Domains → Apache & nginx-Einstellungen* lassen sich die Direktiven pro Domain eintragen. Das WP Toolkit zeigt ausstehende Core-Updates an und spielt sie mit *Updates → Aktualisieren* ein; alternativ ist ein Update mit wp core update per WP-CLI möglich. Wenn Sie innerhalb eines älteren Zweigs bleiben müssen, beachten Sie die Hinweise zur Zielversion in den häufigen Fragen.

Prüfen, ob es Angriffsversuche gab:

grep -h 'wp-content/upgrade/.*setup-config' /var/log/nginx/*access*.log | awk '{print $1, $4, $7, $9}'
find /var/www -path '*/wp-content/upgrade/*' -name wp-config.php

Passen Sie die Log- und Installationspfade an Ihren Server an.

Antworten mit Status 200 auf setup-config.php oder eine wp-config.php innerhalb von wp-content/upgrade/ sind Verdachtsmomente, die geprüft werden sollten. Ein HTTP-200-Status allein belegt keine erfolgreiche Ausnutzung; umgekehrt schließt das Fehlen dieser Merkmale einen Angriff nicht sicher aus.

WordPress-Plugin-Firewalls (z. B. Wordfence) können solche direkten PHP-Aufrufe nur prüfen, wenn sie vor der Ausführung der aufgerufenen Datei geladen werden („Extended Protection“ / auto_prepend_file). Diese Einbindung muss auch für PHP-Dateien im Upgrade-Verzeichnis greifen. Ob ein Angriff blockiert wird, hängt zusätzlich von der Erkennung und den aktiven Regeln ab. Eine Firewall ersetzt das Update nicht.

Häufige Fragen

Meine Website läuft bei WEB-SHOP-HOSTING. Muss ich etwas tun?
Wenn Ihr WordPress über das WP Toolkit bereits auf eine korrigierte Version aktualisiert wurde, müssen Sie wegen dieser Lücke nichts weiter tun. Prüfen Sie zur Sicherheit die Version im Dashboard. Steht dort 7.1.4 (oder 7.0.8, 6.9.11, 6.8.12, 6.7.11 …), ist die Korrektur installiert. Aktivierte automatische Updates allein ersetzen diese Versionsprüfung nicht.

Ist jede Website mit WordPress 7.1.3 oder älter angreifbar?
Nicht dauerhaft. Betroffen sind die oben genannten ungepatchten Versionen. Die beschriebene Angriffskette setzt ein vollständiges Core-Update und einen über das Web erreichbaren Installer im Upgrade-Verzeichnis voraus. Eine ungepatchte Installation bleibt jedoch verwundbar: Beim nächsten vollständigen Core-Update kann das Angriffsfenster entstehen.

Warum ist das Update auf 7.1.4 selbst riskant?
Weil das Update noch von der alten Version entpackt wird. Die Korrektur am Update-Mechanismus greift erst bei späteren Updates. Deshalb sollte wp-content/upgrade/ vorher für den Webzugriff gesperrt werden – auch bei einem Update über das WP Toolkit.

Reicht es, wenn mein Hoster PHP und den Server aktuell hält?
Nein. Diese Lücke liegt in WordPress, nicht in PHP oder Plesk. Sie muss in jeder einzelnen betroffenen WordPress-Installation geschlossen werden.

Woran erkenne ich einen erfolgreichen Angriff?
Unbekannte Datenbankzugangsdaten in wp-config.php, unbekannte Administratorkonten oder unerwartete neue PHP-Dateien seit dem 28. Oktober sind Verdachtsmomente. Sie müssen geprüft werden und belegen für sich genommen noch keinen erfolgreichen Angriff. wp core verify-checksums per WP-CLI vergleicht die Core-Dateien mit dem Original. Die Prüfung erfasst jedoch nicht die gesamte Installation oder die Datenbank und kann eine Kompromittierung nicht vollständig ausschließen.

Wurde bei WEB-SHOP-HOSTING etwas kompromittiert?
Es gibt keinen Hinweis darauf. Wir haben die Zugriffsprotokolle aller Domains auf die bekannten Angriffspfade durchsucht: Alle erfassten Anfragen wurden mit HTTP 403 oder 404 beantwortet, keine lieferte Status 200.

Ich habe WordPress 7.0 oder älter und kann nicht auf 7.1 wechseln. Was jetzt?
Für jeden Zweig bis 4.7 gibt es eine korrigierte Version (siehe Tabelle). Prüfen Sie im WP Toolkit, welche Zielversion angeboten wird. Per WP-CLI lässt sich eine konkrete Version angeben, beispielsweise mit wp core update --version=7.0.8 für den Zweig 7.0. Sperren Sie auch vor diesem Update den Webzugriff auf wp-content/upgrade/. Langfristig sollten Sie auf die aktuelle Version wechseln – nur sie wird offiziell unterstützt.

Quellen

• WordPress.org, 28.10.2026: WordPress 7.1.4 Security Release
• Wordfence, 28.10.2026: WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE; Exploitation Attempts Detected After Release
• NVD: CVE-2026-119977 (veröffentlicht 31.10.2026, CVSS 3.1: 8,1)
• CISA, 03.11.2026: Known Exploited Vulnerabilities Catalog – CVE-2026-119977
• The Hacker News, 04.11.2026: CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades
• BleepingComputer, 04.11.2026: CISA flags WordPress RCE flaw as actively exploited in attacks

Bei Fragen erreichen Sie uns über den Support.