TL;DR. CVE-2026-119977 steht im CISA-KEV-Katalog, Wordfence blockiert Zehntausende Angriffsversuche. Aktualisieren Sie jetzt und prüfen Sie Ihre Website.
| Punkt | Stand 6. November 2026 |
|---|---|
| Schwachstelle | CVE-2026-119977, CVSS 8.1, Race Condition (TOCTOU, CWE-367) im WordPress Core |
| Wirkung | Unauthentifizierte Codeausführung während eines Core-Upgrades |
| Betroffen | WordPress 4.7 bis 7.1.3 |
| Behoben in | 7.1.4 (28.10.2026), Backports 7.0.8, 6.9.11, bis 4.7.39 |
| Ausnutzung | Bestätigt. Laut Wordfence mehr als 240.000 blockierte Versuche bis 05.11.2026, Spitze über 74.000 am 30.10.2026, 18.500+ Requests in den ersten 21 Stunden |
| Neu seit 3. November | Aufnahme in den CISA-KEV-Katalog, Frist für US-Bundesbehörden 6. November 2026 |
| Gilt die Frist in Deutschland | Nein, aber DSGVO Art. 32 verlangt Stand der Technik |
| Sofortmaßnahme | Auf 7.1.4 oder den passenden Backport aktualisieren, Zugriff auf wp-content/upgrade/ sperren, auf Kompromittierung prüfen |
Veröffentlicht: 06.11.2026 · Zuletzt aktualisiert: 06.11.2026, 06:40 Uhr
Unsere Artikelserie zu CVE-2026-119977
- Die Analyse: Was WordPress 7.1.4 im Code ändert
- Die Prüfanleitung: So kontrollieren Sie wp-content/upgrade
- Die Lage: Angriffszahlen, CISA-KEV und Rechtslage für DACH-Betreiber (dieser Beitrag)
Was ist passiert
Die US-Behörde CISA hat CVE-2026-119977 am 3. November 2026 in ihren Known Exploited Vulnerabilities Catalog aufgenommen, den Katalog bekannt ausgenutzter Schwachstellen. Wordfence hat bis zum 05.11.2026 mehr als 240.000 Angriffsversuche gegen diese Lücke im WordPress Core blockiert.
Der Patch ist seit dem 28. Oktober 2026 verfügbar, die Lücke steckt in WordPress 4.7 bis 7.1.3. Neu ist die behördliche Bestätigung der aktiven Ausnutzung, die Betreiber jetzt in ihrer Risikobewertung berücksichtigen sollten. Für Website-Verantwortliche in Deutschland, Österreich und der Schweiz stellen sich damit drei Fragen: Wie belastbar sind die Zahlen, gilt die CISA-Frist auch hier, und was ist heute konkret zu tun? Die Patch-Analyse und die vollständige Prüfanleitung finden Sie in unseren beiden früheren Artikeln, auf die wir an den passenden Stellen verweisen.
Die Zahlen zur Angriffswelle
Wordfence hat bis zum 05.11.2026 mehr als 240.000 Angriffsversuche auf CVE-2026-119977 blockiert, mit einem Spitzenwert von über 74.000 Versuchen am 30.10.2026. Diese Werte belegen anhaltende Angriffsversuche gegen WordPress-Websites seit dem 28. Oktober 2026, jedoch keine bestätigten Kompromittierungen.
Mehr als 240.000 blockierte Versuche
Die Summe von mehr als 240.000 blockierten Versuchen hat Wordfence am 05.11.2026 veröffentlicht. Daneben weist Wordfence auf der Datenbankseite zur Schwachstelle jeweils die Summe der letzten 24 Stunden aus, die Zahl ändert sich also laufend. Die bekannten Stände im Überblick:
- Mehr als 18.500 Requests auf gestagete setup-config.php-Pfade in den ersten 21 Stunden (Wordfence-Blog, 29.10.2026)
- 62.969 blockierte Angriffe in 24 Stunden (Wordfence, wiedergegeben von The Hacker News, 30.10.2026)
- Mehr als 74.000 blockierte Versuche am Spitzentag 30.10.2026 (Wordfence-Tageswert, Wordfence-Blog, 05.11.2026)
- 12.632 blockierte Angriffe in 24 Stunden (Wordfence, wiedergegeben von The Hacker News, 04.11.2026)
- Mehr als 240.000 blockierte Versuche seit Bekanntwerden der Lücke (Wordfence-Blog, 05.11.2026)
- 17.294 blockierte Angriffe in 24 Stunden (Wordfence-Datenbankseite, abgerufen am Morgen des 06.11.2026)
Was die Zahlen nicht sagen
Wordfence zählt Angriffsversuche, nicht erfolgreiche Einbrüche, und betont selbst, dass die hohe Zahl keine große Zahl erfolgreich angegriffener Websites bedeutet. Eine belastbare Zahl tatsächlich kompromittierter WordPress-Websites ist nach unserem Kenntnisstand vom 06.11.2026 nicht veröffentlicht. Auch Security Affairs weist darauf hin, dass die Werte Ausnutzungsversuche dokumentieren.
Die Werte lassen sich außerdem nicht addieren. Die Quellen decken unterschiedliche Zeitfenster ab, und die rollierenden 24-Stunden-Werte können sich überschneiden. Sie bilden zudem nur ab, was Wordfence auf den eigenen geschützten Websites sieht, nicht das gesamte Internet. Wordfence schränkt selbst ein, dass nicht jeder Request den exakt verwundbaren Pfad traf. Auch die drei Ausnutzungsversuche, die der Honeypot-Betreiber Previdian am 30.10.2026 von einer IP-Adresse mit Geolokation Großbritannien aufzeichnete, sind eine eigene Messung und mit den Wordfence-Werten nicht vergleichbar.
Für die Einordnung wichtig ist auch die hohe Angriffskomplexität. CVSS 8.1 ergibt sich aus der schweren möglichen Folge, nicht aus einfacher Ausnutzbarkeit. Laut Wordfence blieb das verwundbare Staging-Verzeichnis in Laborumgebungen normalerweise nur Sekunden verfügbar, die erfolgreiche Ausnutzung sei in der Praxis schwierig. Wiederholtes automatisiertes Abfragen erhöht die Chancen jedoch.
Wie schnell die Angreifer waren
Der erste Treffer der neuen Wordfence-Firewallregel kam neun Minuten nach deren Deployment. Wordfence hatte die Regel am 28.10.2026 um 20:30 UTC ausgerollt, rund drei Stunden nach der Ankündigung des Security-Releases.
Zwei der größten Quellen fragten laut Wordfence über rund 14,5 Stunden wiederholt kleine Gruppen von Websites ab. Wordfence wertet dieses Verhalten als Versuch, das kurze Upgrade-Fenster zu treffen. Andere Quellen testeten viele Varianten von Staging-Verzeichnissen und Versionsnamen. Daraus zieht Wordfence den Schluss, dass Angreifer die Race Condition schnell verstanden haben.
Warum der Update-Vorgang selbst der Angriffsvektor ist
Der Update-Vorgang ist bei CVE-2026-119977 der Angriffsvektor, weil WordPress bei einem vollständigen Core-Upgrade kurzzeitig eine auf vielen Servern öffentlich erreichbare Kopie seiner selbst anlegt. Bis Version 7.1.3 entpackt WordPress die neuen Dateien dafür in ein vorhersagbares Staging-Verzeichnis unter wp-content/upgrade/.
In diesem Zeitfenster ist auf vielen Servern auch das mitgelieferte Installationsskript erreichbar. Es kann an eine vom Angreifer kontrollierte Datenbank gebunden werden. Laut Wordfence kann der Angreifer so die Installation abschließen, ein Administratorkonto anlegen und PHP-Code hochladen. Der Angreifer braucht dafür kein Benutzerkonto, muss aber das Wettrennen gegen den Update-Vorgang gewinnen.
CISA beschreibt die Ursache im Katalogeintrag so: „predictable, web-accessible staging paths used during full-package core upgrades“. Auf Deutsch: vorhersagbare, aus dem Web erreichbare Staging-Pfade, die bei Core-Upgrades mit vollständigem Paket verwendet werden.
Die technischen Änderungen im Code beschreibt unsere Diff-Analyse zu WordPress 7.1.4.
Wer ist betroffen
Betroffen sind alle WordPress-Installationen von 4.7 bis 7.1.3, die noch nicht auf einer Version mit Fix laufen. Ausnutzbar ist die Lücke laut Wordfence nur während eines Core-Updates mit vollständigem Paket, wenn der Staging-Pfad öffentlich erreichbar ist.
Versionen und Branches
Den Fix enthält WordPress 7.1.4 vom 28.10.2026, für ältere Branches stehen Backports bereit. Dazu gehören 7.0.8, 6.9.11, 6.8.12, 6.7.11 und 6.6.11 bis hinunter zu 4.7.39. Die vollständige Versionsmatrix finden Sie in unserer Prüfanleitung. Laut Wordfence sollten die meisten Websites das Security-Release über automatische Hintergrund-Updates erhalten. Prüfen Sie das trotzdem, statt es anzunehmen.
Wer durch die Wordfence-Regel geschützt ist und wer nicht
Kunden von Wordfence Premium, Care und Response erhielten die Firewallregel am 28. Oktober 2026, Nutzer der kostenlosen Version erhalten sie erst am 27. November 2026. Für Betreiber ohne gewartetes Setup ist das der kritische Punkt: Die Standardverzögerung von 30 Tagen fällt in die Phase aktiver Angriffsversuche.
Auch die Regel allein genügt nicht. Laut Wordfence ruft der Angriff direkt eine gestagete PHP-Datei auf, ohne WordPress zu laden. Die Firewall muss deshalb mit Extended Protection optimiert sein, damit sie vor solchen direkten PHP-Aufrufen greift. Wordfence betont zudem, dass die Regel das Update nicht ersetzt. Schließen können Sie die Lücke nur mit dem Update. Einen Überblick über die Schutzebenen finden Sie auf unserer Seite zur WordPress-Sicherheit.
Besonderes Risiko bei Websites ohne betreuten Update-Prozess
Das höchste Restrisiko tragen Websites, die noch ungepatcht sind und bei denen niemand für Core-Updates zuständig ist. Dazu zählen Installationen mit deaktivierten automatischen Updates, aber auch Kampagnenseiten und Microsites, die nach dem Launch nicht mehr aktiv betreut werden.
Solche Websites bleiben verwundbar: Ausnutzbar ist die Lücke beim nächsten Core-Update mit vollständigem Paket, und oft kontrolliert dann niemand Update und Logs. Agenturen mit vielen Kundeninstallationen stehen vor dem gleichen Problem in größerem Maßstab: Bei 50 oder 200 Websites zählt die Übersicht, welche Installation auf welcher Version steht. Wie sich das für mehrere Kundenprojekte organisieren lässt, beschreiben wir unter Lösungen für Agenturen.
Gilt die CISA-Frist auch für Websites in Deutschland
Nein, die Frist zum 6. November 2026 gilt für Websites in Deutschland nicht. Sie bindet nur US-Bundesbehörden der zivilen Exekutive, den KEV-Katalog hat CISA dafür mit der Binding Operational Directive 22-01 eingeführt.
Der KEV-Eintrag zu dieser CVE verweist für die Umsetzung auf die neuere Binding Operational Directive 26-04. Für Betreiber im DACH-Raum begründet auch das keine Frist. Der Katalog ist für private Unternehmen dennoch ein nützliches Signal, denn er belegt, dass eine Lücke tatsächlich angegriffen wird.
Für Betreiber in Deutschland und Österreich ist die DSGVO der maßgebliche Rahmen. Verarbeitet Ihre Website personenbezogene Daten, etwa über Kontaktformulare, Kundenkonten, einen Shop oder Server-Logs mit IP-Adressen, verlangt DSGVO Art. 32 geeignete technische und organisatorische Maßnahmen unter Berücksichtigung des Stands der Technik, der Kosten und des Risikos. Eine bekannt ausgenutzte Schwachstelle mit verfügbarem Patch über Tage offen zu lassen, ist vor diesem Hintergrund schwer zu rechtfertigen. Eine feste Frist in Tagen nennt die DSGVO allerdings nicht, entscheidend ist das Risiko im Einzelfall.
Kommt es zu einer Kompromittierung mit Personenbezug, greift DSGVO Art. 33: Der Verantwortliche meldet eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, der zuständigen Aufsichtsbehörde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Agenturen, die als Auftragsverarbeiter tätig sind, müssen ihren Auftraggeber unverzüglich informieren, bei hohem Risiko sind nach Art. 34 auch die Betroffenen zu benachrichtigen. Für die Schweiz gilt statt der DSGVO das Datenschutzgesetz, sofern die DSGVO nicht im Einzelfall zusätzlich anwendbar ist.
Eine Stellungnahme des BSI zu CVE-2026-119977 ist uns zum 06.11.2026 nicht bekannt. Dieser Abschnitt ist eine allgemeine Einordnung und keine Rechtsberatung. Ob und welche Pflichten in Ihrem Fall bestehen, klären Sie bitte im Einzelfall mit Ihrer Rechtsberatung oder Ihrem Datenschutzbeauftragten.
Timeline
Von der Veröffentlichung des Patches bis zur CISA-Frist für US-Bundesbehörden vergingen neun Tage. Für Nutzer der kostenlosen Wordfence-Version dauert es 30 Tage bis zur Firewallregel.
- 28.10.2026: WordPress 7.1.4 und Backports veröffentlicht, Wordfence rollt die Firewallregel an zahlende Kunden aus (Quelle: Wordfence)
- 30.10.2026: Honeypot-Betreiber Previdian beobachtet drei Ausnutzungsversuche von einer IP mit Geolokation Großbritannien (Quelle: The Hacker News)
- 30.10.2026: The Hacker News berichtet über 62.969 blockierte Angriffe in 24 Stunden (Quelle: Wordfence via The Hacker News)
- 03.11.2026: CISA nimmt CVE-2026-119977 in den KEV-Katalog auf (Quelle: CISA)
- 04.11.2026: Internationale Berichterstattung, 12.632 blockierte Angriffe in den letzten 24 Stunden (Quelle: The Hacker News)
- 05.11.2026: Wordfence veröffentlicht Angriffsdaten: mehr als 240.000 blockierte Versuche insgesamt, Spitze am 30.10.2026, IP-Liste (Quelle: Wordfence)
- 06.11.2026: CISA-Frist für US-Bundesbehörden (Quelle: CISA)
- 27.11.2026: Wordfence-Regel für kostenlose Nutzer (Quelle: Wordfence)
Sofortmaßnahmen
Betreiber sollten heute auf eine Version mit Fix aktualisieren, das Staging-Verzeichnis sperren und ihre Website auf Spuren eines Angriffs prüfen. Wer Zugriff auf die Serverkonfiguration hat, setzt die Sperre aus Punkt 2 möglichst vor dem Update, denn laut Wordfence durchläuft auch das Update auf die gepatchte Version ein letztes Mal den verwundbaren Vorgang. Wer die Sperre nicht sofort setzen kann, aktualisiert trotzdem umgehend, Wordfence empfiehlt ausdrücklich, das Update nicht aufzuschieben.
- Prüfen Sie die Core-Version und aktualisieren Sie auf 7.1.4 oder den passenden Backport.
- Sperren Sie den öffentlichen Zugriff auf wp-content/upgrade/ auf Server- oder Webserverebene. Der Update-Vorgang arbeitet im Dateisystem und braucht keinen Webzugriff auf dieses Verzeichnis. Die Konfiguration für nginx und Apache steht in unserer Prüfanleitung. Haben Sie keinen Zugriff auf die Serverkonfiguration, wenden Sie sich an Ihren Hoster oder informieren Sie sich über unser Hosting.
- Prüfen Sie, ob Ihre Website im Angriffsfenster kompromittiert wurde. Die Schritte finden Sie in unserer Anleitung zur Prüfung von wp-content/upgrade.
- Durchsuchen Sie die Zugriffslogs nach Requests gegen gestagete setup-config.php-Pfade und andere PHP-Dateien unterhalb von wp-content/upgrade/. Wordfence veröffentlicht dazu eine Liste der zehn auffälligsten IP-Adressen. Ein Treffer allein belegt noch keine Kompromittierung, gerade weil die Lücke breit abgefragt wird. Umgekehrt beweisen fehlende Einträge laut Wordfence auch nicht, dass Ihre Website sauber ist.
- Erneuern Sie bei Verdacht Admin-Konten, Datenbankzugänge und Salts. Bestätigt sich der Verdacht, hilft unser Notfall-Service bei gehackten WordPress-Websites.
- Etablieren Sie automatische Core-Updates und einen definierten Wartungsprozess mit klarer Zuständigkeit und Kontrolle nach jedem Update.
Konkrete IOC-Dateinamen oder Webshell-Namen sind noch nicht öffentlich dokumentiert, öffentlich sind nur Pfade und IP-Adressen. Suchen Sie deshalb nach den von Wordfence genannten Mustern: unerwartete Requests auf PHP-Dateien unter wp-content/upgrade/, Dateireste in diesem Verzeichnis, unbekannte Administratorkonten und unerwartete Plugins.
Einschätzung von CMS ADMINS
Das Besondere an CVE-2026-119977 ist aus Sicht von CMS ADMINS, dass der sichernde Vorgang selbst zum Risiko wird. Ein Update darf deshalb nicht verschoben werden, es muss aber kontrolliert durchgeführt werden.
Üblicherweise ist die Empfehlung bei Sicherheitslücken einfach: aktualisieren. Das gilt auch hier. Doch diese Lücke entsteht ausgerechnet im Upgrade-Fenster, und die Beobachtungen von Wordfence sprechen dafür, dass Angreifer gezielt auf dieses Fenster zielen. Wer Zugriff auf den Server hat, sollte die Reihenfolge deshalb bewusst wählen: erst das Verzeichnis sperren, dann aktualisieren, danach prüfen. Wer diesen Zugriff nicht hat, sollte trotzdem nicht warten: Das letzte verwundbare Update dauert nur kurz, und künftige Updates sind laut Wordfence nicht mehr betroffen.
Ebenso aufschlussreich ist der Unterschied im Zeitablauf. Bezahlte Wordfence-Kunden hatten die Firewallregel rund drei Stunden nach dem Release. Gewartete Installationen sind in dieser Größenordnung versorgt, weil jemand das Update zeitnah einspielt und prüft. Wer dagegen nur auf die kostenlose Wordfence-Version setzt und das Update nicht im Blick hat, steht bis zum 27. November ohne dieses Firewall-Netz da. Der Abstand von 30 Tagen ist keine Nachlässigkeit, sondern das Standardmodell dieses Produkts. Betreiber sollten ihn aber kennen und einplanen.
Die Zahlen sind ein Grund zum Handeln, nicht zur Panik. Bislang belegen sie breite Versuche, keine Welle bestätigter Einbrüche, und das Spitzenvolumen lag laut Wordfence zwischen dem 29.10. und dem 01.11.2026. Wichtiger als die einzelne Lücke ist für uns die Frage, ob für Ihre Website jemand zuständig ist, wenn das nächste Security-Release erscheint. Wenn Sie diese Aufgabe abgeben möchten, finden Sie unser Angebot unter WordPress-Wartung.
Häufige Fragen
Wird CVE-2026-119977 wirklich aktiv ausgenutzt?
Ja, CISA führt CVE-2026-119977 seit dem 03.11.2026 im Katalog bekannt ausgenutzter Schwachstellen. Wordfence blockierte bis zum 05.11.2026 mehr als 240.000 Angriffsversuche, am 30.10.2026 allein über 74.000. Das sind Versuche, keine bestätigten Kompromittierungen.
Meine Website läuft auf WordPress 7.1.4, bin ich sicher?
Ja, gegen CVE-2026-119977 ist WordPress 7.1.4 gepatcht, eine frühere Kompromittierung beseitigt das Update aber nicht. Prüfen Sie deshalb auch den Zeitraum vor Ihrem Update, besonders wenn es erst nach dem 28.10.2026 lief. Was 7.1.4 im Code ändert, zeigt unsere Analyse zu WordPress 7.1.4.
Woran erkenne ich, dass meine Website im Angriffsfenster kompromittiert wurde?
Sicher erkennen Sie das nur durch eine Prüfung von Logs, Dateien und Konten. Wordfence nennt als Warnzeichen Requests auf PHP-Dateien unter wp-content/upgrade/, Dateireste dort, unbekannte Administratorkonten und unerwartete Plugins. Konkrete IOC-Dateinamen sind noch nicht öffentlich dokumentiert. Die Schritte stehen in unserer Prüfanleitung.
Muss ich die CISA-Frist vom 6. November 2026 in Deutschland einhalten?
Nein, die Frist vom 06.11.2026 bindet nur US-Bundesbehörden. Unabhängig davon verlangt DSGVO Art. 32 risikoangemessene Maßnahmen unter Berücksichtigung des Stands der Technik, wenn Ihre Website personenbezogene Daten verarbeitet. Bei einer Datenschutzverletzung gilt zudem Art. 33 mit der Meldung möglichst binnen 72 Stunden. Ob das auf Sie zutrifft, ist im Einzelfall zu prüfen.
Reicht ein Sicherheitsplugin wie Wordfence als Schutz aus?
Nein, ein Sicherheitsplugin ersetzt das Update nicht, das betont auch Wordfence selbst. Die Firewallregel erhalten Nutzer der kostenlosen Version erst am 27.11.2026. Zudem braucht die Regel Extended Protection, weil der Angriff direkt eine PHP-Datei aufruft, ohne WordPress zu laden.
Was passiert, wenn meine Website noch auf einer älteren WordPress-Version läuft?
Dann ist sie verwundbar, sofern dort eine Version von 4.7 bis 7.1.3 ohne den Backport ihrer Branch läuft. Backports gibt es für alle Branches bis 4.7.39, zum Beispiel 7.0.8 oder 6.9.11. Laut Wordfence erhalten WordPress 4.6 und älter keine Sicherheitsupdates mehr und sollten auf eine unterstützte Version gehoben werden.
Fazit
CVE-2026-119977 wird angegriffen, und das Update bleibt der entscheidende Schritt. Die CISA-Frist bindet Sie nicht, die Pflichten aus der DSGVO können Sie aber betreffen. Prüfen Sie deshalb noch heute Ihre WordPress-Version, aktualisieren Sie auf 7.1.4 oder den passenden Backport, sperren Sie wp-content/upgrade/ und kontrollieren Sie Ihre Logs. Finden Sie Hinweise auf eine Kompromittierung, handeln Sie sofort und nutzen Sie bei Bedarf unsere Hilfe für gehackte WordPress-Websites.
Quellen
- CISA: CISA Adds One Known Exploited Vulnerability to Catalog
- Wordfence: WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE
- Wordfence: Attackers Actively Probing for Upgrade-Window RCE Vulnerability in WordPress Core
- The Hacker News: CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades
- The Hacker News: WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours
- Wordfence Intelligence: Datenbankeintrag zu CVE-2026-119977
- Security Affairs: U.S. CISA adds WordPress flaw to its Known Exploited Vulnerabilities catalog
