Folgen Eine Schwachstelle mit hoher Schweregrad in WordPress Core wird aktiv in Angriffen ausgenutzt, was die U.S. Cybersecurity and Infrastructure Security Agency (CISA) dazu veranlasst hat, die Schwachstelle in ihren Katalog der bekannten ausgenutzten Schwachstellen (KEV) aufzunehmen. Die als CVE-2026-119977 verfolgte Schwachstelle trägt einen CVSS-Wert von 8,1 und kann es einem nicht authentifizierten Angreifer ermöglichen, während eines WordPress Core-Upgrades beliebigen Code auf einem verwundbaren Server auszuführen.
Die Schwachstelle resultiert aus einer Time-of-Check Time-of-Use (TOCTOU) Race Condition im WordPress-Upgrade-Prozess. Während vollständiger Core-Updates legt WordPress Installationsdateien vorübergehend an vorhersehbaren, im Web zugänglichen Orten ab. Angreifer können diese Orte wiederholt prüfen und versuchen, auf Installationskomponenten zuzugreifen, während ein Upgrade stattfindet.
WordPress hat das Problem in Version 7.1.4 behoben, die am 28. Oktober 2026 veröffentlicht wurde. Die Schwachstelle betrifft WordPress-Versionen von 4.7 bis 7.1.3, während Sicherheitsfixes auch auf berechtigte ältere Zweige zurückportiert wurden. WordPress betont, dass nur die neueste Version aktiv unterstützt wird.
Das Risiko hat das theoretische Exploitation-Stadium überschritten. Von Wordfence zitierte Telemetrie aus The Hacker News verzeichnete mehr als 18.500 Anfragen, die auf installierte setup-config.php-Pfade abzielten, während der ersten 21 Stunden nach der Offenlegung. CISA bestätigte anschließend Beweise für die Ausnutzung und verlangte von den betroffenen US-amerikanischen föderalen zivilen Behörden, die Schwachstelle bis zum 6. November 2026 zu beheben.
Sicherheitsteams können die SOC Prime Platform nutzen, um die Erkennungsabdeckung gegen aufkommende Ausbeutungstechniken zu stärken und nach verdächtigen Aktivitäten im Zusammenhang mit anfälligen, internetfähigen Systemen zu suchen. Erkennen Sie die Ausnutzung von CVE-2026-119977, indem Sie ungewöhnliche Anfragen an WordPress-Upgrade-Orte, unerwartete PHP-Ausführung, neu erstellte Administratorkonten, verdächtige Dateien und Post-Exploitation-Verhalten überwachen.
Erkennungsinhalte sind möglicherweise nicht für jede CVE verfügbar. Prüfen Sie die SOC Prime Platform auf aktuelle Erkennungsabdeckung. Falls relevante Erkennungen noch nicht verfügbar sind, überprüfen Sie sie erneut, da kontinuierlich neue Bedrohungsinformationen und Erkennungsinhalte hinzugefügt werden.
CVE-2026-119977-Analyse
CVE-2026-119977 ist als TOCTOU Race Condition unter CWE-367 klassifiziert und hat einen CVSS 3.1-Wert von 8,1. Sein Vektor spiegelt netzwerkbasierte Ausnutzung wider, die keine Privilegien oder Benutzerinteraktion erfordert, mit hoher potenzieller Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. Die Angriffskomplexität wird als hoch eingestuft, da der Erfolg der Ausnutzung davon abhängt, während eines engen Upgrade-Fensters auf eine anfällige Ressource zuzugreifen.
CVE-2026-119977 betrifft WordPress Core-Veröffentlichungen von Version 4.7 bis 7.1.3. Die Schwachstelle ist nicht an ein Drittanbieter-Plugin oder Thema gebunden; sie existiert im Core-Software-Upgrade-Mechanismus selbst.
Das Problem tritt während vollständiger Core-Upgrades auf. WordPress extrahiert das neue Paket vorübergehend in einen Staging-Ort unterhalb des wp-content/upgrade-Verzeichnisses, bevor es die bestehende Installation ersetzt. In betroffenen Veröffentlichungen können Teile dieses Staging-Ortes vorhersehbar und während des Updates vom Web aus erreichbar sein.
Ein besonders wichtiger Bestandteil ist der installierte setup-config.php-Installer. Ein nicht authentifizierter Angreifer, der den temporären Pfad korrekt vorhersagt und auf diese Komponente zugreift, bevor WordPress die Bereinigung abschließt, kann möglicherweise mit der temporären Installation interagieren und letztendlich PHP-Code auf dem Server ausführen.
Dies schafft ein ungewöhnliches Exploitationmodell. Eine anfällige WordPress-Site ist nicht notwendigerweise kontinuierlich ausbeutbar. Stattdessen muss der Angreifer die Site während des kurzen Zeitraums abfangen, in dem ein vollständiges Paket-Upgrade die Staging-Dateien offenlegt. Forscher weisen darauf hin, dass die Gelegenheit nur Sekunden dauern kann.
Angreifer können diese Einschränkung durch Automatisierung ausgleichen. Anstatt eine einzelne Anfrage zu stellen, können Bedrohungsakteure potenzielle Upgrade-Pfade kontinuierlich abfragen und darauf warten, dass ein Ziel mit dem Update beginnt. Wordfence beobachtete, dass Angreifer wiederholt Variationen von installierten Orten abfragten, was zeigt, dass reale Akteure schnell verstanden, wie man die Race Condition angreift.
Das große Volumen an beobachteten Anfragen sollte dennoch sorgfältig interpretiert werden. Die gemeldeten Zahlen repräsentieren blockierte Anfragen oder Exploitationversuche und bedeuten nicht, dass jede Anfrage zu einer erfolgreichen Remote-Code-Ausführung führte. Die Ausnutzung erfordert weiterhin, dass die Anfrage mit einem aktiven vollständigen Paket-Upgrade und anderen erforderlichen Serverbedingungen zusammenfällt.
Die initiale Telemetrie von Wordfence zeigte mehr als 18.500 Anfragen gegen installierte Pfade in den ersten 21 Stunden. GBHackers berichteten anschließend über fast 59.000 blockierte Versuche innerhalb von 24 Stunden, während The Hacker News weitere Telemetrie zitierte, die eine fortgesetzte Exploitation-Aktivität demonstriert.
Unabhängige Honeypot-Telemetrie, zitiert von The Hacker News, zeichnete Exploitationversuche am 30. Oktober auf und unterstützte CISA’s Entscheidung, die Schwachstelle als aktiv ausgenutzt zu klassifizieren. Die Aufnahme der Schwachstelle in den KEV durch CISA erhöht die Dringlichkeit für Organisationen, die öffentliche WordPress-Infrastrukturen betreiben, erheblich.
Zum Zeitpunkt des Schreibens dokumentieren die geprüften Quellen kein weitverbreitetes, öffentlich validiertes CVE-2026-119977 PoC-Repository. Öffentlich vorhandene Exploit-Codes sind jedoch nicht erforderlich, um ein Risiko zu etablieren, da Exploit-Versuche bereits in großem Maßstab beobachtet wurden und CISA aktive Ausnutzung bestätigt hat.
WordPress 7.1.4 ändert den anfälligen Upgrade-Prozess. Laut der verfügbaren technischen Berichterstattung beinhaltet die Beseitigung, dass Staging-Orte weniger vorhersehbar werden, zusätzliche Schutzmaßnahmen gegen den direkten Zugriff eingeführt und verhindert wird, dass temporäre Konfigurationsdaten unsicher befördert werden.
WordPress hat den Sicherheitsforscher Umut Bayram anerkannt, der die Schwachstelle im Upgrade-Prozess gemeldet hat. Version 7.1.4 wurde am 28. Oktober 2026 veröffentlicht und der CVE-Eintrag wurde anschließend am 31. Oktober veröffentlicht.
Für die Erkennung von CVE-2026-119977 sollten Verteidiger besonderes Augenmerk auf Webanfragen richten, die auf ungewöhnliche Pfade unterhalb von wp-content/upgrade abzielen, insbesondere Anfragen, die auf temporäre Kopien von setup-config.php verweisen. Wiederholte Anfragen über mehrere mögliche Staging-Verzeichnisse hinweg können auf automatisierte Prüfungen hinweisen, die versuchen, die Race Condition zu gewinnen.
Erfolgreiche Ausnutzung kann potenziell Remote-PHP-Code-Ausführung im Kontext des betroffenen Webservers ermöglichen. Verteidiger sollten daher verdächtige Anfragen an Upgrade-Pfade mit nachfolgenden Beweisen wie unerwarteten PHP-Dateien, Änderungen der WordPress-Konfigurationsdaten, unbekannten Administratorkonten, bösartigen Plugins, ungewöhnlichen vom Webserver gestarteten Child-Prozessen oder unerwarteten ausgehenden Verbindungen in Verbindung bringen.
Öffentliche Berichterstattung hat kein umfassendes Set von angreiferspezifischen CVE-2026-119977 IOCs wie stabile Command-and-Control-Domains oder Malware-Hashes identifiziert. Dies macht verhaltensbasierte Erkennung besonders wichtig. Anfragen zu vorhersehbaren Staging-Pfaden, verdächtige Aktivitäten während eines Update-Fensters und nachträgliche Änderungen bieten langlebigere Jagdmöglichkeiten als das alleinige Verlassen auf statische Indikatoren.
CVE-2026-119977-Minderung
Die primäre Minderung für CVE-2026-119977 besteht darin, WordPress sofort zu aktualisieren. WordPress 7.1.4 enthält den Sicherheitsfix, und Fixes wurden auch für berechtigte ältere Release-Zweige verfügbar gemacht oder zurückportiert. Organisationen sollten die Migration zur neuesten aktiv unterstützten WordPress-Version priorisieren, anstatt sich unbegrenzt auf alte Sicherheitsrückports zu verlassen.
Administratoren sollten folgende Maßnahmen ergreifen:
- Aktualisieren Sie WordPress-Installationen mit Internetzugang auf Version 7.1.4 oder höher.
- Überprüfen Sie, dass automatische Updates erfolgreich abgeschlossen wurden, anstatt davon auszugehen, dass ein Update angewendet wurde.
- Inventarisieren Sie ältere WordPress-Installationen, einschließlich vergessener Entwicklungs-, Staging- und Altsysteme.
- Überprüfen Sie die Webserver- und WAF-Protokolle auf Anfragen, die auf wp-content/upgrade und installierte setup-config.php-Pfade abzielen.
- Untersuchen Sie unerwartete PHP-Dateien, neue WordPress-Administratorkonten, unbefugte Plugins und unerklärliche Konfigurationsänderungen.
- Überprüfen Sie ausgehende Verbindungen und Webserver-Child-Prozesse auf Hinweise auf nachträgliche Exploit-Aktivitäten.
- Stellen Sie sicher, dass WAF-Schutzmaßnahmen frühzeitig genug im Anfragepfad wirksam werden, um direkte Anfragen an temporäre PHP-Dateien abzudecken.
- Erwägen Sie, den direkten Webzugriff auf temporäre Upgrade-Verzeichnisse, wo betrieblich machbar, einzuschränken.
Firewallregeln für Webanwendungen können die Exposition gegenüber automatisierten Exploit-Versuchen reduzieren, sollten jedoch nicht als Ersatz für Patchen angesehen werden. Da die anfällige Ressource temporär außerhalb des normalen WordPress-Anfrageflusses existieren kann, sollten Administratoren überprüfen, ob ihre WAF-Implementierung tatsächlich direkte Anfragen an installierte PHP-Dateien inspiziert.
Organisationen, die während bereits laufender Ausnutzung aktualisiert haben, sollten auch eine rückblickende Untersuchung in Betracht ziehen. Das Abschließen des Updates beseitigt das anfällige Verhalten, beweist jedoch nicht, dass der Server nicht kompromittiert wurde, während das anfällige Staging-Verzeichnis verfügbar war.
Überprüfen Sie Zugriffsprotokolle, die den genauen Upgrade-Zeitstempel umgeben. Anfragen an die betroffenen Staging-Pfade, die unmittelbar vor oder während des Upgrades stattfinden, sollten zusätzliche Aufmerksamkeit erhalten. Sicherheitsteams sollten diese Anfragen dann mit Dateisystemänderungen, WordPress-Kontomodifikationen, PHP-Ausführungen, verdächtigen Netzwerkverbindungen und anderen Indikatoren für nachfolgende Ausnutzung korrelieren.
Falls ein Kompromiss vermutet wird, isolieren Sie den betroffenen Host, wo praktisch, bewahren Sie relevante Web-, Anwendungs-, Authentifizierungs- und Systemprotokolle auf und sammeln Sie verdächtige Dateien vor der Behebung. Anmeldeinformationen und Secrets, die dem WordPress/PHP-Prozess zugänglich sind, sollten als potenziell exponiert betrachtet und basierend auf den Untersuchungsergebnissen rotiert werden.
Die Aufnahme der Schwachstelle in den KEV durch CISA bestätigt, dass die Behebung als unmittelbare operative Priorität und nicht als Routine-Patch-Zyklus-Item behandelt werden sollte. Den Bundeszivilbehörden des Executive Branch wurde aufgetragen, das Problem bis zum 6. November 2026 zu adressieren.
FAQ
Was ist CVE-2026-119977 und wie funktioniert es?
CVE-2026-119977 ist eine hochgradige nicht authentifizierte Remote-Code-Ausführungs-Schwachstelle in WordPress Core, die durch eine TOCTOU-Race Condition im Upgrade-Prozess verursacht wird. Während vollständiger Core-Updates legt WordPress Installationsdateien vorübergehend an vorhersehbaren, im Web zugänglichen Orten ab. Ein Angreifer, der während dieses kurzen Zeitfensters auf den installierten Weg zugreift, kann möglicherweise beliebigen PHP-Code auf dem Server ausführen.
Wann wurde CVE-2026-119977 erstmals entdeckt?
WordPress hat den Sicherheitsforscher Umut Bayram damit anerkannt, die Schwachstelle gemeldet zu haben. WordPress veröffentlichte die Version 7.1.4 mit dem Fix am 28. Oktober 2026, während der CVE-Eintrag am 31. Oktober veröffentlicht wurde. Die geprüften Quellen spezifizieren kein genaues Datum, an dem die Schwachstelle ursprünglich privat an WordPress gemeldet wurde.
Welche Auswirkungen hat CVE-2026-119977 auf Systeme?
Erfolgreiche Ausnutzung kann es einem nicht authentifizierten Remote-Angreifer ermöglichen, während des anfälligen Upgrade-Fensters beliebigen Code auf dem betroffenen WordPress-Server auszuführen. Abhängig von den Privilegien des Webserver-Prozesses und den Folgeaktionen des Angreifers kann dies zu einer Kompromittierung der Website, der Bereitstellung bösartiger Dateien, Datendiebstahl, Persistenz, der Offenlegung von Anmeldedaten oder weiteren Eindringung in verbundene Infrastruktur führen.
Kann CVE-2026-119977 mich 2026 noch beeinflussen?
Ja. WordPress-Installationen, die betroffene Versionen ausführen, bleiben gefährdet, und Ausbeutung findet in freier Wildbahn statt. CISA hat die Schwachstelle nach Beweisen für aktive Angriffe in ihren Katalog der bekannten ausgenutzten Schwachstellen aufgenommen, während Sicherheitsanbieter Zehntausende von Anfragen verzeichnet haben, die versuchen, auf anfällige Staging-Pfade zuzugreifen.
Wie kann ich mich vor CVE-2026-119977 schützen?
Aktualisieren Sie WordPress sofort auf die Version 7.1.4 oder eine spätere unterstützte Veröffentlichung und bestätigen Sie, dass das Update erfolgreich abgeschlossen wurde. Überprüfen Sie Webserver- und WAF-Protokolle auf Anfragen, die auf temporäre Upgrade-Verzeichnisse abzielen, untersuchen Sie die Websites auf unautorisierte PHP-Dateien, Administratorkonten, Plugins oder Konfigurationsänderungen und untersuchen Sie Systeme, die während laufender Exploitation-Versuche aktualisiert wurden. Organisationen sollten auch WordPress- und CISA-Beratungshinweise überwachen, um aktualisierte Details für CVE-2026-119977 zu erhalten, da sich die Exploitation-Landschaft weiterentwickelt.
