CVE-2026-119977 steht seit dem 3. November 2026 im Known-Exploited-Vulnerabilities-Katalog (KEV) der US-Behörde CISA. Die Schwachstelle ist eine Time-of-check/Time-of-use-Race Condition (TOCTOU) im WordPress-Core-Upgrade und kann in einem engen Zeitfenster während eines Full-Package-Updates zu Remote Code Execution führen. Der Fix liegt seit dem 28. Oktober in WordPress 7.1.4 und Backports bis Zweig 4.7.
Wichtig vorweg: Dieser Text beschreibt Auswirkungen, Patch-Stand und Nachweisquellen – keine Exploit-Schritte. Betreiber sollen patchen und Logs prüfen, nicht Experimente nachbauen.
CVE-2026-119977: Was CISA und WordPress sagen
CISA listet die CVE explizit als „WordPress Core Time-of-check Time-of-use (TOCTOU) Race Condition Vulnerability“ und verweist auf aktive Ausnutzung als Aufnahmegrund in den KEV. Für US-Bundesbehörden (FCEB) gilt laut CISA-Alert die Frist aus Binding Operational Directive 26-04 – Berichte nennen Freitag nach der Aufnahme (6. November). CISA betont zugleich, dass auch Organisationen außerhalb des Bundes die KEV-Einträge priorisieren sollten.
Die WordPress-Sicherheitsfreigabe vom 28. Oktober beschreibt die Lücke als Race Condition während Core-Updates, die zu Remote Code Execution führen kann, und dankt dem Melder Umut Bayram. WordPress empfiehlt, Sites sofort zu aktualisieren. Die Dokumentation zu Version 7.1.4 listet den Fix neben weiteren Security-Patches und nennt Backports für ältere Zweige, etwa 7.0.8 und 6.9.11.
BleepingComputer fasst am 4. November zusammen: Die Ausnutzung setzt auf vorhersehbare, webzugängliche Staging-Pfade während Full-Package-Upgrades und gilt als high-complexity. Wordfence wird mit der Aussage zitiert, in 24 Stunden 13.095 Angriffe auf die Lücke blockiert zu haben. Ob und wie viele erfolgreiche Kompromittierungen vorliegen, legt CISA im Alert nicht detailliert offen.
Betroffene Versionen und Patch-Stand
Wordfence und unabhängige Zusammenfassungen nennen als betroffen WordPress ab etwa 4.7.0 bis 7.1.3; gepatcht sind unter anderem 7.1.4 sowie die jeweiligen Security-Releases der älteren Branches. WordPress 4.6 und älter erhalten keine Security-Updates mehr und sollten auf einen unterstützten Zweig. Wer Auto-Updates nutzt, sollte im Dashboard trotzdem prüfen, ob 7.1.4 (oder der passende Backport) wirklich anliegt – nicht annehmen.
Der Fix laut Wordfence-Darstellung: Staging-Verzeichnis randomisieren, Index-Absicherung und unsichere Promotion von staged Konfigurationsdaten verhindern. Solange Sites ungepatcht bleiben, öffnet jedes Full-Package-Update erneut ein Fenster – inklusive des Updates auf die gepatchte Version selbst, wenn Angreifer exakt in diesem Moment zielen.
Was Betreiber tun sollten – ohne Exploit-Details
Priorität 1: auf 7.1.4 oder den Backport des eigenen Zweigs aktualisieren, danach Version verifizieren. Priorität 2: Webserver-Logs auf ungewöhnliche PHP-Anfragen unter wp-content/upgrade prüfen und unbekannte Admin-Konten, Plugins oder PHP-Dateien untersuchen. Priorität 3: Firewall-Regeln können Exposure senken, ersetzen aber den Core-Patch nicht – Wordfence betont Extended Protection, weil manche Requests PHP-Dateien direkt treffen, ohne WordPress vollständig zu laden.
Wer unsicher ist, ob die Site im ungepatchten Fenster getroffen wurde, sollte Backup und Incident-Playbook bereithalten statt „nur nochmal updaten“. Kompromittierte Instanzen brauchen oft Neuaufbau statt In-Place-Bereinigung – das Muster kennen wir von anderen aktiv ausgenutzten WordPress-Fällen.
Einordnung im Umfeld aktiver WP-/PHP-Lücken
Bei code404zero haben wir kürzlich ähnliche Update- und Exploit-Druckmuster beschrieben: die Plugin-Lücke CVE-2026-81648 im CryptoPayment Gateway, die kritische PHP-Serie rund um PHP2Shell und den Notfall-Patch-Kontext zu zwei RCE-Schwachstellen mit CVSS 9.2. Auch Core-Themen wie der SQL-Mode-Wechsel in WordPress 7.2 zeigen, dass Betriebsdetails im Core Security und Datenintegrität beeinflussen.
Der Unterschied zu vielen Plugin-CVEs: Hier sitzt die Race Condition im Updater selbst. Patchen ist deshalb nicht optional „wenn Zeit ist“, sondern Teil jedes Core-Update-Prozesses. Öffentliche Exploit-PoCs und Angriffszahlen aus Firewall-Telemetrie erhöhen den Druck – unabhängig davon, ob die eigene Site schon getroffen wurde.
Bewertung der Schwere
Wordfence bewertet die Upgrade-Window-RCE öffentlich mit CVSS 8.1 (High); WordPress selbst stuft Race Conditions dieser Art in Release-Notes oft konservativer ein. CISA priorisiert über den KEV-Status und die nachgewiesene Ausnutzung, nicht über die Marketing-Headline. Für Betreiber zählt die Kombination: unauthentifiziert, Core-Updater, aktive Attempts, klarer Patch.
High Complexity bedeutet nicht „irrelevant“. Es bedeutet: Angreifer müssen Timing und Erreichbarkeit der Staging-Pfade treffen. Automatisierte Scanner und opportunistische Akteure testen genau solche Fenster massenhaft – die von Wordfence genannten Blockzahlen passen zu diesem Muster.
Für Hosting-Kunden und Agenturen lohnt ein Inventar: Welche Sites laufen noch unter 7.1.3 oder älterem Branch ohne Backport? Automatisierte Updates können fehlschlagen, wenn Dateirechte, disk space oder Custom-Upgrader im Weg stehen. Ein einmaliger Versionscheck über die Flotte verhindert, dass „wir haben Auto-Updates“ mit „wir sind gepatcht“ verwechselt wird.
Was offen bleibt
CISA nennt im Alert keine Attribution und keine detaillierte Kampagnenbeschreibung. Unklar bleibt öffentlich, wie viele Sites erfolgreich kompromittiert wurden versus wie viele Attempts Firewalls sehen. Betreiber sollten sich deshalb nicht an „noch keine Bestätigung bei uns“ festklammern, sondern am Patch-Status.
Kurz: CVE-2026-119977 ist gepatcht, aktiv im KEV und betrifft den WordPress-Core-Updater. Primärquellen sind der CISA-Alert vom 3. November, die WordPress-7.1.4-Dokumentation vom 28. Oktober und die Berichterstattung zu Ausnutzungsversuchen. Wer noch unter 7.1.4 bzw. ohne Backport läuft, sollte jetzt aktualisieren und Upgrade-Pfade in den Logs nachziehen – ohne die Lücke nachzustellen.
