WordPress-Lücke CVE-2026-119977 ausgenutzt: den Core sicher aktualisieren

Am 28. Oktober 2026 hat WordPress die Sicherheitsversion 7.1.4 veröffentlicht, mit Korrekturen für alle älteren Zweige bis zurück zu 4.7. Die wichtigste betrifft CVE-2026-119977: Während eines Core-Updates kann ein Angreifer ganz ohne Konto, der im richtigen Moment zuschlägt, Code auf dem Server ausführen. Am 3. November hat die US-Behörde CISA die Lücke in ihren Katalog ausgenutzter Schwachstellen (KEV) aufgenommen, gestützt auf Hinweise auf aktive Ausnutzung.

Für ein Tessiner KMU mit WordPress-Website ist die praktische Folge einfach: Die Website muss auf der korrigierten Version laufen, und es lohnt sich zu prüfen, ob seit dem 28. Oktober etwas Ungewöhnliches passiert ist. Ein Detail unterscheidet diesen Fall allerdings vom Üblichen: Die Lücke steckt im Update-Prozess selbst.

Was passiert ist

Laut der Sicherheitsmeldung von WordPress (GHSA-4w3m-c66w-69mg, 29. Oktober 2026) entpackte WordPress bei einem Core-Update mit vollständigem Paket die neuen Dateien in einen Ordner mit vorhersehbarem Namen innerhalb von wp-content/upgrade, der aus dem Web erreichbar ist. Wer das «Rennen» gegen dieses Entpacken gewinnt, in den wenigen Augenblicken, in denen die temporäre Kopie existiert, kann bis zur Codeausführung gelangen. Betroffen sind die Versionen 4.7 bis 7.1.3.

Die Einstufungen des Schweregrads gehen auseinander, und es hilft zu verstehen, warum:

• WordPress stuft die Lücke als niedrig ein, weil das nutzbare Zeitfenster sehr kurz ist.
• Wordfence, das die CVE vergeben hat, bewertet sie laut NVD-Datenbank mit CVSS 3.1 8.1 (hoch): Die Angriffskomplexität ist hoch, gelingt der Angriff aber, ist die Wirkung auf den Server total.
• Die CISA betrachtet sie als aktiv ausgenutzt, und das kanadische Zentrum für Cybersicherheit hat am 3. November eine Warnung veröffentlicht.

Laut Wordfence begannen die ersten Versuche am Tag der Veröffentlichung; seine Firewall hat über 240'000 davon blockiert. Wordfence hält fest, dass ein erfolgreicher Angriff in der Praxis schwierig ist: Die wiederholten automatisierten Versuche zielen genau darauf ab, den kurzen Moment des Updates zu erwischen.

Das Detail, das man kennen muss: das letzte Update

Die Korrektur macht den Namen des temporären Ordners zufällig. Das Update, das 7.1.4 installiert, wird aber noch vom alten Code auf der Website ausgeführt: Laut Wordfence öffnet der Wechsel von der verwundbaren zur korrigierten Version das Fenster deshalb ein letztes Mal, für die Dauer des Updates. Danach sind künftige Updates nicht mehr betroffen.

Das ist kein Grund, das Update aufzuschieben: Wordfence empfiehlt, so rasch wie möglich zu aktualisieren. Als zusätzliche Vorsichtsmassnahme rät es, vor dem Update auf Webserver-Ebene den Zugriff auf PHP-Dateien im Ordner /wp-content/upgrade/ zu sperren. WordPress schreibt direkt über das Dateisystem in diesen Ordner; die Sperre des Webzugriffs verhindert das Update also nicht.

Korrigierte Versionen

In der WordPress-Meldung als korrigiert aufgeführte Versionen (Auszug; die vollständige Liste umfasst alle Zweige bis 4.7):

WordPress erinnert daran, dass nur die neueste Version aktiv unterstützt wird: Wer noch auf einem alten Zweig ist, sollte den Wechsel auf 7.1 planen.

Was mit der eigenen WordPress-Website zu tun ist

1. Version prüfen. Im Dashboard unter Aktualisierungen oder beim Anbieter nachfragen. Angezeigt werden muss 7.1.4 oder die korrigierte Version des eigenen Zweigs. Automatische Hintergrund-Updates haben sie in der Regel bereits installiert, aber das sollte geprüft werden: Sie gelingen nicht immer.
2. Ist die Website noch nicht aktualisiert: Dateien und Datenbank sichern, beim Serverbetreiber die Sperre des Webzugriffs auf PHP-Dateien in /wp-content/upgrade/ veranlassen und sofort aktualisieren.
3. Seit dem 28. Oktober nach Anzeichen einer Kompromittierung suchen. In den Zugriffslogs des Servers erfolgreiche Anfragen an /wp-content/upgrade/; im Dashboard unbekannte Administratorkonten; auf dem Server unerwartete PHP-Dateien oder ungeplante Änderungen an wp-config.php. Für die eigenen Behörden verlangt die CISA genau für diese Lücke eine forensische Prüfung.
4. Bei Hinweisen: Die Website als kompromittiert betrachten, isolieren, Zugangsdaten ändern (Administratoren, Datenbank, API-Schlüssel), aus einem sauberen Backup von vor dem 28. Oktober wiederherstellen und den Server analysieren lassen. Das Update allein entfernt nicht, was ein Angreifer bereits installiert haben könnte.
5. Plugins, Themes und PHP. Die Gelegenheit nutzen, um auch Plugins und Themes zu aktualisieren und die PHP-Version zu prüfen: Im Oktober wurden auch kritische PHP-Lücken und mehrere WordPress-Plugins korrigiert.

Wir veröffentlichen keine Details zur Ausnutzung der Lücke: Ziel ist, die Exposition zu schliessen und die Systeme zu prüfen.

Wenn die Website kompromittiert wurde: Meldungen

• Datenschutz (revDSG). Enthält die Website oder der Server Personendaten (Kontaktformulare, Kundenkonten, Bestellungen) und führt die Verletzung voraussichtlich zu einem hohen Risiko für die betroffenen Personen, verlangt Artikel 24 des Datenschutzgesetzes eine Meldung an den EDÖB so rasch als möglich. Der Leitfaden des EDÖB erklärt, wie der Fall zu beurteilen und zu melden ist.
• BACS. Für die meisten KMU ist die Meldung eines Cybervorfalls an das BACS freiwillig, aber sinnvoll. Seit dem 1. April 2025 gilt für Betreiberinnen kritischer Infrastrukturen dagegen eine Meldepflicht für Cyberangriffe innert 24 Stunden nach der Entdeckung.
• Finanzieller Schaden. Bei einem Schaden Anzeige bei der Kantonspolizei erstatten.

Häufige Fragen

Unsere Website aktualisiert sich selbst: Müssen wir etwas tun?

Laut Wordfence sollten Websites mit aktivierten automatischen Updates bereits auf einer korrigierten Version sein. Es lohnt sich trotzdem, die installierte Version zu prüfen und die Logs seit dem 28. Oktober anzusehen, denn das letzte Update lief noch über den alten Code.

Warum stuft WordPress sie als niedrig ein und die CISA als ausgenutzt?

Die beiden Einschätzungen betrachten unterschiedliche Dinge: WordPress gewichtet, wie schwer das kurze Update-Fenster zu treffen ist, die CISA das Vorliegen realer Ausnutzungsversuche. Für Website-Betreiber ist die Schlussfolgerung dieselbe: aktualisieren und prüfen.

Unsere Website wird von einer Agentur betreut: Was sollen wir fragen?

Drei Fragen genügen: welche WordPress-Version installiert ist, ob der Webzugriff auf /wp-content/upgrade/ gesperrt ist und ob die Logs seit dem 28. Oktober geprüft wurden. Verlangen Sie eine schriftliche Antwort.

Wir haben eine Firewall oder ein Sicherheits-Plugin: Sind wir geschützt?

Nicht unbedingt. Wordfence erklärt, dass der Angriff auf Dateien zielt, die WordPress nicht laden; ein Sicherheits-Plugin innerhalb der Website sieht sie deshalb nur in bestimmten Konfigurationen. Die Sperre auf Webserver-Ebene und das Update bleiben die wichtigsten Massnahmen.

Unser Ansatz

ElaraTeq Sagl unterstützt KMU und Praxen im Tessin beim Aktualisieren und Prüfen von WordPress-Websites, bei der Konfiguration des Webservers und beim Hosting in der Schweiz (Hosting, Beratung). Für eine Prüfung Ihrer Website können Sie uns kontaktieren.

Quellen

• WordPress, WordPress 7.1.4, 28. Oktober 2026
• WordPress, GHSA-4w3m-c66w-69mg: A race condition during core updates that could lead to remote code execution, 29. Oktober 2026
• NIST NVD, CVE-2026-119977
• CISA, CISA Adds One Known Exploited Vulnerability to Catalog, 3. November 2026
• Canadian Centre for Cyber Security, WordPress security advisory (AV26-1117), 3. November 2026
• Wordfence, Attackers Actively Probing for Upgrade-Window RCE Vulnerability in WordPress Core, November 2026
• BACS, Meldepflicht für Cyberangriffe auf kritische Infrastrukturen
• EDÖB, Leitfaden DataBreach