Ausnutzung von Schwachstellen
WordPress-Core-Sicherheitslücke während des Patch-Vorgangs
Angreifer loten CVE-2026-119977 aus, eine WordPress-Core-Sicherheitslücke, die nur während eines Core-Updates auftritt und die Ausführung von Remote-Code ohne Authentifizierung erlaubt. Was ist passiert und wie kann man seine Websites schützen.
Save to Folio
Wichtige Erkenntnisse
- CVE-2026-119977, eine Schwachstelle im WordPress-Kern (Versionen 4.7 bis 7.1.3), erlaubt die Ausführung von Remote-Code ohne Authentifizierung.
- Die Schwachstelle besteht nur während der Aktualisierung einer Website. Bei einem vollständigen Core-Update entpackte WordPress die neue Version – einschließlich des Installationsprogramms – in einen vorhersehbaren Ordner, auf den der Webserver zugreifen konnte. Ein Angreifer, der dieses Installationsprogramm anfordert, bevor der Update-Vorgang abgeschlossen ist, kann Code auf dem Server ausführen.
- Das Zeitfenster ist schwer zu treffen. Aus diesem Grund stuft WordPress das Problem als „niedrig“ ein, während der von Wordfence zugewiesene CVE-Eintrag es als „hoch“ ansieht (CVSS 3.1: 8,1). Angreifer gleichen die geringen Erfolgschancen durch die Menge ihrer Angriffe aus.
- Der Schwachstellenbericht von Wordfence wies in den 24 Stunden bis zum 3. November 13.835 abgewehrte Angriffe aus, ein Rückgang gegenüber den 62.969 gemeldeten Angriffen in den 24 Stunden bis zum 30. Oktober.
- Führen Sie ein Update auf 7.1.4 oder die korrigierte Version Ihres Zweigs durch.
Am 28. Oktober 2026 veröffentlichte WordPress die Version 7.1.4, ein Sicherheits-Update, das 22 Sicherheitslücken behebt. Für die meisten möglichen Angriffe darauf ist ein authentifiziertes Konto erforderlich. Doch eine Lücke sticht hervor, da sie die Art und Weise betrifft, wie Kern-Updates bereitgestellt werden, für die keine Authentifizierung nötig ist. Am 29. Oktober folgte der Sicherheitshinweis von WordPress, in dem die behobenen Versionen für jeden unterstützten Zweig von 7.0.8 bis zurück zu 4.7.39 aufgeführt wurden. Die CVE-Nummer CVE-2026-119977 wurde von Wordfence vergeben und am 31. Oktober veröffentlicht.
Angreifer reagierten schneller als die meisten Website-Betreiber. Wordfence stellte am 28. Oktober, etwa drei Stunden nach der Veröffentlichung, eine Firewall-Regel für seine zahlenden Kunden bereit, die bereits neun Minuten später die erste Anfrage abfing. In den ersten 21 Stunden wurden mehr als 18.500 Anfragen an inszenierte „setup-config.php“-Installationspfade verzeichnet. Die beiden größten Quellen sondierten etwa 14,5 Stunden lang kleine Gruppen von Websites und warteten auf ein Update, um das Angriffsfenster zu öffnen. Andere probierten zahlreiche Varianten von Staging-Ordnern und Versionsnamen aus. Nicht jede Anfrage verwendete genau den anfälligen Pfad, doch die Sondierungsversuche zeigen, dass die Angreifer die Sicherheitslücke schnell durchschaut hatten.
Das Volumen ist nun rückläufig. The Hacker News berichtete von 62.969 Angriffen, die von Wordfence in den 24 Stunden bis zum 30. Oktober blockiert wurden; die Schwachstellenstatistik von Wordfence wies in den 24 Stunden bis zum 3. November 13.835 Angriffe aus. Diese Zahlen umfassen nur die von Wordfence geschützten Websites, sodass die tatsächliche Zahl höher liegt.
Die TrendAI™-Telemetrie zeigt das gleiche Muster. Seit die Bereitstellung unserer Netzwerk- und Serverregeln für diese Schwachstelle am 30. und 31. Oktober, wurden Tausende von Ausnutzungsversuchen gegen Kundenumgebungen registriert, und die Zahl steigt weiterhin an. Keiner davon hat zu einer bestätigten Kompromittierung geführt: Bei jeder Endpunktwarnung handelte es sich um ein legitimes WordPress- oder Plugin-Update. TrendAI™-Kunden finden in diesem Knowledge-Base-Eintrag Informationen zu verfügbaren Lösungen und zur Abhilfe für diese Schwachstelle.
Funktionsweise der Schwachstelle
WordPress kann seine Core-Dateien auf zwei Arten aktualisieren: über ein Teilpaket, das nur geänderte Dateien enthält, oder über ein Komplettpaket mit der gesamten Version. Bei Verwendung des Komplettpakets extrahierten betroffene Versionen die neue Version in einen Arbeitsordner unter wp-content/upgrade/ mit einem vorhersehbaren Namen. Dieser Ordner befindet sich im Web-Root-Verzeichnis, sodass auf vielen Servern jeder eine Datei daraus abrufen kann.
Die Staging-Kopie enthält den WordPress-Installer. Auf einer Live-Website weigert sich der Installer, zu laufen, da bereits eine Konfigurationsdatei („wp-config.php“) vorhanden ist. Die Staging-Kopie verfügt über keine Konfigurationsdatei. Solange der Ordner also existiert, läuft der Installer für jeden, der ihn aufruft. Von dort aus kann ein Angreifer die Staging-Installation auf eine von ihm kontrollierte Datenbank verweisen und Code auf dem Server unter dem Konto des Webservers ausführen.
Vier Bedingungen müssen laut Wordfence für einen Missbrauch erfüllt sein:
- Die Website führt ein vollständiges Core-Update durch.
- Der Staging-Ordner ist öffentlich erreichbar und der Webserver führt darin PHP aus.
- Der Angreifer kennt oder errät den Ordnerpfad.
- Der Angreifer erreicht das Installationsprogramm, bevor WordPress den Ordner bereinigt.
WordPress 7.1.4 schließt die Sicherheitslücke, indem der Namen des Staging-Ordners zufällig generiert wird, einen Index-Schutz erhält und die unsichere Übernahme von Staging-Konfigurationsdaten verhindert wird. Der Fix wurde auf alle betroffenen Zweige zurückportiert.
Warum die Einstufungen voneinander abweichen
WordPress stuft das Problem als „Low“ ein, während der CVE-Eintrag es gemäß CVSS 3.1 mit 8,1 als „High“ einstuft. Beides ist vertretbar. Der Angriff erfordert keine Anmeldedaten und ermöglicht die vollständige Codeausführung, was die Bewertung in die Höhe treibt. Außerdem muss zum Zeitpunkt der Anfrage ein Update laufen, und in Labortests dauerte dieses Zeitfenster nur Sekunden. Deshalb ist die Komplexität eines Angriffs „hoch“, aber WordPress hält es für unwahrscheinlich, dass er gegen eine einzelne Website erfolgreich ist.
Was die Kriterien für die Einstufung verändert, sind der Umfang und automatische Updates. Die meisten WordPress-Websites erhalten Sicherheitsupdates über automatische Hintergrund-Updates, sodass sie das Update-Fenster nach ihrem eigenen Zeitplan durchlaufen, ohne dass jemand darauf achtet. Ein einzelner Angreifer kann nicht vorhersagen, wann eine bestimmte Website ein Update durchführt, aber automatisierte Tools können alle paar Sekunden Tausende von Websites abfragen und dann warten. Die von Wordfence beobachteten Abfragen entsprechen genau dieser Strategie. Die Wahrscheinlichkeit für eine einzelne Website ist gering, doch im gesamten Internet ist dies nicht der Fall.
Maßnahmen
- Wenn Sie den Webserver kontrollieren, sperren Sie den Staging-Ordner, bevor Sie das Update durchführen. Das Update ist der Moment der Gefährdung, daher sollten Sie Webanfragen an /wp-content/upgrade/ zuerst ablehnen. Fügen Sie die Regel in die Serverkonfiguration, eine Web-Application-Firewall oder eine CDN-Regel ein, nicht in eine Datei innerhalb dieses Ordners (ältere Versionen löschen den Inhalt des Ordners während des Updates, wodurch die Regel entfernt wird). Wenn Sie dies nicht schnell umsetzen können, führen Sie das Update trotzdem durch, da 7.1.4 auch 21 weitere Sicherheitslücken behebt.
- Führen Sie das Update durch und überprüfen Sie die Version. Installieren Sie WordPress 7.1.4 oder die korrigierte Version für Ihren Zweig. Gehen Sie nicht davon aus, dass automatische Updates bereits ausgeführt wurden: Überprüfen Sie die Version auf jeder Website, einschließlich Marketing-, Regional- und Kampagnen-Websites, die nicht unter die zentrale Verwaltung fallen. Websites mit Version 4.6 oder älter verfügen über keinen Patch und müssen aktualisiert oder offline genommen werden.
- Suchen Sie nach Angriffsversuchen und deren Folgen. Durchsuchen Sie die Webserver-Protokolle nach Anfragen an PHP-Dateien unter wp-content/upgrade/, insbesondere nach „setup-config.php“. Eine Anfrage an sich deutet bereits auf einen Angriffsversuch hin, eine 200-Antwort während eines Update-Fensters ist eine Untersuchung wert. Suchen Sie nach PHP-Dateien unter wp-content/upgrade/, die Sie nicht dort abgelegt haben, nach unbekannten Administratorkonten und unerwarteten Plugins.
- Behandeln Sie einen erfolgreichen Zugriff als Kompromittierung. Wenn während eines Updates eine Installationsanfrage erfolgreich war, gehen Sie davon aus, dass Code auf dem Server ausgeführt wurde. Ändern Sie die Anmeldedaten für Datenbank und Administrator und überprüfen Sie die Website auf Webshells.
TrendAI™ kann helfen
- Virtuelles Patching am Endpunkt und im Netzwerk: Das virtuelle Patching schützt vor Versuchen, CVE-2026-119977 direkt im Netzwerk und am Endpunkt auszunutzen, einschließlich physischer und virtueller Server. Im Netzwerk wurde der TrendAI Vision One™ TippingPoint™-Schutz veröffentlicht und ist standardmäßig aktiviert und auf „Blockieren“ eingestellt. Auf den Endgeräten wurde der TrendAI Vision One™ Endpoint Security-Schutz am 31. Oktober veröffentlicht und empfohlene Scans wenden ihn auf die Server an, die ihn benötigen. Er wird im Erkennungsmodus ausgeliefert: Schalten Sie ihn auf „Verhindern“ um, um Versuche während des Updates zu blockieren.
- Erkennung und Reaktion im Netzwerk: TrendAI Vision One™ Network Security erkennt Exploit-Anfragen im Netzwerk.
- Detection and Response: TrendAI Vision One™ verfügt über neue Erkennungsregeln für die Enumeration des Upgrade-Ordners und Änderungen an einer zwischengespeicherten setup-config.php sowie über mehr als 90 bestehende Erkennungsregeln für die nächsten Schritte eines Angreifers auf einem kompromittierten Server, wie z. B. das Starten von Shells durch Webserver-Prozesse, das Schreiben von Web-Shells auf die Festplatte und die Persistenz durch SSH-Schlüssel.
- Exponierung: TrendAI Vision One™ Cyber Risk Exposure Management (CREM) kennzeichnet anfällige WordPress-Installationen und hilft dabei, Prioritäten für die Reihenfolge der Updates zu setzen.
- Hunting: Durchsuchen Sie TrendAI Vision One™ nach den oben genannten Erkennungsregeln auf Ihren Webservern sowie nach Webanfragen an PHP-Dateien im Verzeichnis „wp-content/upgrade/“.