CISA hat am 3. November 2026 eine Sicherheitslücke im WordPress-Kern in ihren Katalog ausgenutzter Schwachstellen aufgenommen. Betroffen sind alle Versionen von 4.7 bis 7.1.3. Für US-Bundesbehörden gilt der 6. November als Frist, für alle anderen Betreiber bleibt der Eintrag eine Warnung ohne Pflicht.
WordPress hat das Sicherheits-Release 7.1.4 am 28. Oktober 2026 veröffentlicht und rät, sofort zu aktualisieren. Das Release schließt außerdem mehrere Fälle von gespeichertem Cross-Site-Scripting (XSS), unter anderem durch präpariertes Block-Markup.
Wie funktioniert der Angriff beim Update?
Bei einem Core-Update mit vollständigem Paket entpackt WordPress die neuen Dateien an einen vorhersehbaren Ort, den der Webserver ausliefert. Gewinnt ein Angreifer ohne Anmeldung den Wettlauf gegen das Entpacken, kann er in diesem Zeitfenster Code auf dem Server ausführen. Fachleute nennen das eine Race Condition (CWE-367).
Wordfence hat die Kennung CVE-2026-119977 vergeben und bewertet den Fehler mit 8,1 von 10 Punkten, also als hoch, bei hoher Angriffskomplexität. WordPress beschreibt den Fehler in der Ankündigung als Schwachstelle im Upgrade-Prozess, die während des Update-Fensters Codeausführung aus der Ferne ermöglichen könnte, und verzichtet auf Kennung und Punktzahl.
Angriffsversuche laufen bereits. Laut XHack zählte Wordfence in den ersten 21 Stunden nach der Aktivierung einer Firewallregel mehr als 18.500 Anfragen an die Installationspfade. Einen erfolgreichen Angriff hat Wordfence demnach bisher nicht gemeldet.
Welche Version schließt den Fehler?
Jede Versionsreihe hat eine eigene korrigierte Version. Die Angaben stammen von XHack, Stand 4. November 2026:
Versionsreihe
Behoben in
7.1
7.1.4
7.0
7.0.8
6.9
6.9.11
6.8
6.8.12
6.7
6.7.11
6.6
6.6.11
6.5
6.5.14
6.4
6.4.14
Auch für ältere Versionsreihen bis 4.7 nennt XHack Korrekturen, zuletzt 4.7.39; für 4.6 und älter erscheinen laut XHack keine Sicherheitsupdates mehr. WordPress selbst schrieb am 28. Oktober, die Korrekturen für ältere Versionsreihen erschienen nach und nach.
Wie aktualisierst du sicher?
Entscheidend ist die Reihenfolge, denn den Update-Vorgang führt noch der alte, verwundbare Code aus. Patchstack rät laut XHack deshalb, den Webzugriff auf wp-content/upgrade vor dem Update zu sperren, in der Serverkonfiguration oder über den Hoster. Ein Sicherheits-Plugin schützt dagegen nur die laufende Seite, nicht die temporäre Kopie der neuen Dateien.
So aktualisierst du in vier Schritten
Reihenfolge für WordPress-Seiten mit einer Version bis 7.1.3, laut Patchstack und XHack
Backupvollständige Sicherung von Dateien und Datenbank
SperreWebzugriff auf wp-content/upgrade im Server sperren
Updateauf 7.1.4 oder die korrigierte Version deiner Versionsreihe aktualisieren
Kontrolleinstallierte Version prüfen, bei Verdacht Logs sichern
Die Serverkonfiguration vor dem Einsatz testen
Quellen: WordPress.org, XHack, CISA
Seiten mit aktivierten automatischen Hintergrundupdates aktualisiert WordPress laut Release-Beitrag selbst. Prüf auch dort, ob 7.1.4 oder die korrigierte Version deiner Versionsreihe tatsächlich installiert ist.
Was das für dich bedeutet
Geh heute alle WordPress-Installationen durch, die du betreust:
Öffne im Dashboard den Bereich Aktualisierungen und vergleiche die Version mit der Tabelle. Liegt die Version unter der korrigierten Version deiner Versionsreihe, aktualisier am besten sofort.
Lass vor dem Update ein Backup erstellen und sperr den Webzugriff auf wp-content/upgrade. Bei Managed Hosting klärst du mit dem Hoster, ob er das schon erledigt hat.
Sichere bei einem Verdacht auf Angriffe zuerst die Server-Logs, bevor du aufräumst. Danach prüfst du Administratorkonten, Plugins und Dateien.
Betreust du Kundenseiten, lohnt sich eine kurze Nachricht an die Kunden: Ein Update mit Backup und gesperrtem Ordner in dieser Woche lässt sich leichter erklären als ein Vorfall.
CISA hat die Schwachstelle am 3. November 2026 in den Katalog aufgenommen.