Die Behörde CISA hat am 3. November 2026 die Schwachstelle CVE-2026-119977 in den Katalog der bekannten, aktiv ausgenutzten Schwachstellen (KEV) aufgenommen. Die Schwachstelle betrifft den WordPress Core – von Version 4.7.0 bis 7.1.3 – und stellt eine Race Condition vom Typ Time-of-check-to-Time-of-use (TOCTOU) dar, die es einem nicht authentifizierten Angreifer ermöglicht, während eines vollständigen Core-Updates beliebigen Code auf dem Server auszuführen. Der Patch ist in WordPress 7.1.4 verfügbar und wurde auf alle unterstützten Branches bis hin zur 4.7‑Serie zurückportiert. Zivile Bundesbehörden der USA sind verpflichtet, die Schwachstelle bis zum 6. November 2026 zu beheben.
Technische Details der Schwachstelle
Laut dem offiziellen WordPress-Sicherheitshinweis werden bei einem vollständigen Core-Update (complete-package update) die entpackten Dateien in ein vorhersagbares Verzeichnis innerhalb eines webbasiert zugänglichen Update-Verzeichnisses abgelegt. Ein Angreifer, der das Rennen gegen den Entpackungsprozess gewinnt, kann auf die temporären Dateien zugreifen – insbesondere auf den Installer-Pfad setup-config.php – und eine Remote Code Execution ohne jegliche Authentifizierung auf der Website erreichen.
Die Schwachstelle wird als CWE-367 (TOCTOU Race Condition) klassifiziert. Nach Angaben von Wordfence wurde ihr ein CVSS-Score von 8.1 (High) mit dem Vektor CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H zugewiesen. Die hohe Angriffskomplexität (AC:H) spiegelt wider, dass das enge Zeitfenster des Updates getroffen werden muss.
Abweichungen bei der Einstufung der Schwere
Hier ist eine deutliche Abweichung zwischen den Quellen zu beachten. Der ursprüngliche WordPress-Sicherheitshinweis vom 29. Oktober 2026 stuft das Problem als Low severity ein und vermerkt „No known CVE“. Später – am 31. Oktober – hält der Eintrag in der GitHub Advisory Database bereits die Kennung CVE-2026-119977 fest und klassifiziert die Schwachstelle als High. Wordfence bestätigt die Bewertung 8.1. Somit stammt der Score 8.1 von Wordfence und der GitHub Advisory Database und ist nicht die Bewertung des Herstellers im ursprünglichen Sicherheitshinweis.
Betroffene Versionen
Die Schwachstelle betrifft alle WordPress-Core-Branches von 4.7 bis 7.1.3. Laut WordPress-Sicherheitshinweis sind unter anderem betroffen:
- 7.1.0–7.1.3, 7.0.0–7.0.7
- 6.9.0–6.9.10, 6.8.0–6.8.11, 6.7.0–6.7.10
- 6.6.0–6.6.10, 6.5.0–6.5.13, 6.4.0–6.4.13
- Frühere Branches bis hin zu 4.7.0–4.7.38
Der Patch wurde in WordPress 7.1.4 veröffentlicht, und die Patches wurden auf alle genannten Branches zurückportiert.
Nachweise für Ausnutzung
Nach Angaben von Wordfence wurden innerhalb eines rollierenden 24‑Stunden‑Zeitraums 18.762 Angriffe blockiert, die auf diese Schwachstelle abzielten. Es handelt sich um eine Momentaufnahme der Telemetrie, nicht um das kumulierte Ergebnis einer Kampagne – die Zahl ändert sich mit jedem Update.
Unabhängig von Wordfence hat Previdian drei Exploit-Versuche auf seinen Honeypot-Sensoren von einer IP-Adresse registriert, die nach Großbritannien geolokalisiert wurde. Der erste Versuch datiert vom 30. Oktober 2026. Dabei stellt Previdian ausdrücklich klar: Die Beobachtungen auf den Sensoren bestätigen Exploit-Versuche, belegen jedoch nicht, dass das Zielsystem verwundbar war oder dass der Angriff erfolgreich war.
Es liegt keine Attribution vor: Keine der verfügbaren Quellen bringt die beobachtete Aktivität mit einer bestimmten Gruppe, Kampagne oder einem bestimmten Opfer-Set in Verbindung.
Auswirkungsbewertung
WordPress ist weiterhin die dominierende CMS-Plattform, und eine Schwachstelle im Core – nicht in einem Plugin – vergrößert automatisch die Angriffsfläche auf alle Installationen, die die betroffenen Versionen verwenden. Zuvor haben wir bereits Schwachstellen direkt im WordPress-Core behandelt: die kritische LFI-Schwachstelle CVE-2026-87902 und die Click2Shell-Schwachstelle. CVE-2026-119977 setzt diesen Trend fort, allerdings mit einer wichtigen Besonderheit: Das Ausnutzungsfenster ist auf den Zeitpunkt des Updates begrenzt.
Das Paradoxe an der Situation ist, dass die Schwachstelle gerade dann aktiv wird, wenn ein Update durchgeführt wird – eine Maßnahme, die Administratoren eigentlich zur Verbesserung der Sicherheit ergreifen. Dies schafft ein Risiko für Websites mit automatischen Updates und für solche, die manuell aktualisiert werden, ohne den Netzwerkzugriff auf das Update-Verzeichnis zu kontrollieren.
Empfehlungen
- Aktualisieren Sie WordPress umgehend auf Version 7.1.4 oder auf den entsprechenden Patch für Ihren Branch. Die Liste der bereinigten Versionen ist im WordPress-Sicherheitshinweis veröffentlicht.
- Kontrollieren Sie den Zugriff auf das Update-Verzeichnis. Da die Ausnutzung davon abhängt, dass während des Update-Prozesses auf vorhersagbare Pfade im webbasiert zugänglichen Update-Verzeichnis zugegriffen wird, reduziert die Einschränkung des Netzwerkzugriffs auf diese Pfade (z. B. über Webserver-Regeln oder einen WAF) das Risiko selbst vor Einspielen des Patches.
- Überwachen Sie Anfragen an temporäre Update-Dateien. Anfragen an Pfade wie
setup-config.phpim Update-Verzeichnis außerhalb eines legitimen Updates sind ein Indikator für einen Exploit-Versuch. - Führen Sie Updates unter Bedingungen mit eingeschränktem Zugriff durch: Versetzen Sie die Website nach Möglichkeit in den Wartungsmodus oder beschränken Sie den eingehenden Traffic während des Core-Updates.
Die Aufnahme von CVE-2026-119977 in den CISA-KEV-Katalog bestätigt, dass die Schwachstelle in der Praxis ausgenutzt wird und nicht nur theoretisch bleibt. Administratoren von WordPress-Websites sollten das Update auf eine bereinigte Version mit hoher Priorität einspielen – und gleichzeitig sicherstellen, dass der eigentliche Update-Prozess unter geschützten Netzwerkbedingungen mit eingeschränktem externem Zugriff auf den Server abläuft.
