WordPress-Lücke CVE-2026-119977: Angreifer lauern auf Updates
Für die Race Condition im WordPress-Update-Prozess gibt es jetzt die CVE-Nummer CVE-2026-119977. Wordfence meldet seit dem Patch gezielte Ausnutzungsversuche auf das Upgrade-Verzeichnis. Betroffen sind WordPress 4.7.0 bis 7.1.3, behoben in 7.1.4 und Backports.

Für die WordPress-Kernlücke im Update-Prozess gibt es jetzt eine CVE-Nummer, und Angreifer versuchen bereits, sie auszunutzen. CVE-2026-119977 betrifft WordPress 4.7.0 bis 7.1.3 und wurde am 28. Oktober mit WordPress 7.1.4 und den Backports für ältere Zweige behoben. Wordfence meldet seitdem gezielte Anfragen auf die Pfade, über die der Angriff läuft.
Betroffen sind alle Installationen, die noch keinen der gepatchten Stände erreicht haben. Wer bereits auf 7.1.4 oder dem passenden Backport läuft, ist geschützt. Weil das Risiko gerade beim nächsten Core-Update entsteht, sollten Admins den Versionsstand heute prüfen und nicht auf das nächste Wartungsfenster warten.
Was ist passiert?
Bei einem Core-Update mit vollständigem Paket entpacken betroffene Versionen die neuen Dateien in ein vorhersagbares Verzeichnis unter wp-content/upgrade. Diese temporäre Kopie enthält auch den Installer. Ist das Verzeichnis per Web erreichbar, kann ein Angreifer ohne Konto den Installer im richtigen Moment aufrufen und bis zur Ausführung von PHP-Code gelangen. Entdeckt hat die Lücke der Forscher Umut Bayram.
Wordfence verteilte am 28. Oktober um 20:30 UTC eine Firewall-Regel an zahlende Kunden. Der erste Treffer kam laut Wordfence neun Minuten später. In den ersten 21 Stunden zählte das Unternehmen mehr als 18.500 Anfragen auf vorbereitete setup-config.php-Pfade. Zwei der größten Quellen fragten rund 14,5 Stunden lang immer wieder kleine Gruppen von Websites ab, offenbar um das kurze Update-Fenster zu treffen. The Hacker News berichtet unter Berufung auf Wordfence von 62.969 blockierten Angriffen innerhalb von 24 Stunden; diese Zahl steht nicht im Wordfence-Blogbeitrag. Erfolgreiche Kompromittierungen hat Wordfence laut SecurityWeek nicht gemeldet.
Wer ist betroffen?
Verwundbar sind WordPress 4.7.0 bis 7.1.3. Gepatcht sind 7.1.4 sowie die Backports 7.0.8, 6.9.11, 6.8.12 und weitere Stände bis hinunter zu 4.7.39. WordPress 4.6 und älter erhält keine Sicherheitsupdates mehr. Ausnutzbar ist die Lücke nur, wenn ein vollständiges Core-Paket mit Installer entpackt wird, der Staging-Baum öffentlich erreichbar ist und PHP dort ausgeführt wird.
Wie kritisch ist das?
Wordfence bewertet die Lücke mit CVSS 8.1 (hoch), Patchstack stuft die Angriffskomplexität als hoch ein. Das Zeitfenster dauerte in Laborumgebungen nur Sekunden, ein einzelner Versuch ist daher wenig aussichtsreich. Automatisiertes Dauerabfragen erhöht die Chancen aber. Patchstack hält die Ausnutzung für kaum praktikabel, weist jedoch darauf hin, dass das Fenster bei jedem Update wiederkehrt, auch bei automatischen. Eine PHP-basierte Firewall greift nach Patchstack hier nicht, weil die entpackte Kopie WordPress aus eigenen Dateien lädt. Wordfence verweist deshalb auf die Option Extended Protection, die die Firewall vor direkten PHP-Aufrufen startet.
WordPress 7.1.4 behebt das Problem mit einem zufälligen Staging-Verzeichnis, einem Index-Schutz und ohne unsichere Übernahme der Staging-Konfiguration.
Was sollten Admins jetzt tun?
- Versionsstand aller Installationen prüfen, etwa unter Dashboard, Aktualisierungen oder per
wp core version, und auf 7.1.4 oder den passenden Backport bringen. Automatische Updates nicht ungeprüft als erledigt ansehen. - Wo möglich vor dem Update den Zugriff auf
/wp-content/upgrade/am Webserver oder in einer vorgelagerten WAF sperren und sicherstellen, dass das Verzeichnis nicht auflistbar ist. Diese Empfehlung stammt von Patchstack. - Bei bisher ungepatchten Seiten die Zugriffslogs auf Anfragen nach PHP-Dateien unter wp-content/upgrade durchsuchen, besonders nach setup-config.php.
- Auf unbekannte Administratorkonten, unerwartete Plugins und fremde PHP-Dateien prüfen.
- Eine Firewall als Ergänzung betrachten, nicht als Ersatz für das Update.
Einordnung für Unternehmen
Die Lücke ist schwer auszunutzen, doch die Angreifer haben das Prinzip schnell verstanden und warten gezielt auf den Moment des Updates. Für Agenturen und Betreiber mehrerer Seiten lohnt eine zentrale Sperre des Upgrade-Verzeichnisses auf Server-Ebene, weil sie über alle Installationen hinweg wirkt. Bemerkenswert ist zudem die uneinheitliche Bewertung: Das GitHub-Advisory von WordPress stuft das Problem als niedrig ein, Wordfence vergibt CVSS 8.1. Maßgeblich bleibt, ob die gepatchte Version tatsächlich läuft.
In eigener Sache
Wer Updates, Backups und Firewall seiner WordPress-Seite nicht selbst im Blick behalten will, findet bei S-EDV eine laufende WordPress-Wartung, die neue Sicherheitsupdates innerhalb von 48 Stunden einspielt.
Passende Anleitungen auf S-EDV
- WordPress mit Nginx härten und sensible Dateien sperren
- WordPress-Logs auswerten: Zugriffe, Fehler und Angriffe erkennen
- WP-CLI installieren: die wichtigsten Befehle für Admins
Quellen
- Wordfence: WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE
- Patchstack: WordPress 7.1.4 Security Release
- WordPress: GitHub-Advisory GHSA-4w3m-c66w-69mg
- The Hacker News: WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts
- SecurityWeek: Fresh WordPress Vulnerability in Attackers' Crosshairs


