Kurz gesagt
Eine Lücke im Kern von WordPress lässt Angreifer ohne Login Code auf den Server bringen, und zwar genau in den Sekunden, in denen die Website ein Update einspielt. Die Sicherheitsfirma Wordfence hat seit dem 28. Oktober über 240 000 Angriffsversuche abgefangen, die US-Behörde CISA führt die Lücke als aktiv ausgenutzt. Geschützt ist, wer WordPress 7.1.4 oder die geflickte Version seines Zweigs installiert hat. In der Schweiz läuft rund jede zweite Website mit bekanntem System auf WordPress.
Die Lücke auf einen Blick
| Name | CVE-2026-119977, Race Condition beim Kern-Update von WordPress (TOCTOU) |
| Folge | Codeausführung auf dem Server ohne Login, während ein Update läuft |
| Betroffen | WordPress 4.7 bis 7.1.3 |
| Behoben in | 7.1.4 sowie Flicken für alle Zweige bis 4.7 (etwa 7.0.8, 6.9.11, 5.9.20, 4.7.39) |
| Veröffentlicht | 28. Oktober 2026 |
| Bewertung | 8,1 von 10 (Wordfence, CVSS 3.1), WordPress selbst: «Low» |
| Aktiv ausgenutzt | ja, im CISA-Katalog seit 3. November 2026 |
| Angriffsversuche | über 240 000 blockiert, Spitze über 74 000 am 30. Oktober (Wordfence) |
| Entdeckt von | Umut Bayram |
Die meisten Inhaber denken an ihre Website zweimal im Jahr: wenn die Rechnung des Webdesigners kommt und wenn ein Kunde meldet, dass das Kontaktformular nicht geht. Dazwischen läuft sie. Genau diese Ruhe nutzen Angreifer gerade aus.
Am 28. Oktober hat das WordPress-Team die Version 7.1.4 veröffentlicht. Sie schliesst mehrere Lücken, die wichtigste trägt die Nummer CVE-2026-119977. Laut dem Sicherheitshinweis von WordPress entpackte das System bei einem vollständigen Update die neuen Dateien in einen vorhersehbaren Ordner, der von aussen erreichbar war. Wer im richtigen Moment eine Anfrage schickt, kann dort ohne Passwort Code ausführen. Betroffen sind alle Versionen von 4.7 bis 7.1.3. Gefunden hat die Lücke der Forscher Umut Bayram.
Seither klopfen Angreifer im grossen Stil an. Wordfence, ein Anbieter von Schutzsoftware für WordPress, hat nach eigenen Angaben über 240 000 Angriffsversuche blockiert. Der Höhepunkt kam am 30. Oktober mit über 74 000 Versuchen an einem einzigen Tag. Die US-Cybersicherheitsbehörde CISA hat die Lücke am 3. November in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen. Amerikanische Bundesstellen mussten bis heute, 6. November, handeln.

Wie gefährlich ist die Lücke wirklich?
Die nüchterne Antwort: weniger, als die Zahl vermuten lässt, aber mehr, als man ignorieren darf. Der Angriff klappt nur in einem kurzen Fenster, nämlich solange ein Update läuft. Wordfence schreibt selbst, ein erfolgreicher Angriff sei «in der Praxis schwierig». Die Angreifer feuern deshalb automatisiert und ununterbrochen auf denselben Ordner, in der Hoffnung, irgendwo genau während eines Updates zu landen. Bei Tausenden Websites trifft irgendwann einer.
Gelingt es, ist der Schaden gross. Der Angreifer schliesst die halbe Installation selbst ab, legt sich ein Administratorkonto an und lädt eigenen Code hoch. Dann gehört ihm die Website: Er kann Seiten verändern, Besucher auf Betrugsseiten umleiten, Formulardaten abgreifen oder eine Hintertür für später einbauen. Wordfence bewertet die Lücke mit 8,1 von 10 Punkten. WordPress selbst stuft sie zurückhaltender ein, weil das Zeitfenster so klein ist.

Der Haken liegt in einem Detail: Ausgerechnet das Update, das schützt, öffnet das Fenster ein letztes Mal. Wer von 7.1.3 auf 7.1.4 wechselt, durchläuft noch einmal den alten, verwundbaren Ablauf. Ab der geflickten Version sind künftige Updates sicher. Aufschieben macht es deshalb nicht besser, sondern verlängert nur die Zeit, in der jede automatische Aktualisierung zum Risiko wird.
Welche WordPress-Version ist sicher?
Sicher ist nicht nur 7.1.4. WordPress hat den Flicken für alle Zweige bis zurück zu 4.7 nachgeliefert. Massgebend ist, ob Ihre Version mindestens die geflickte Nummer Ihres Zweigs erreicht.
| Ihr Zweig | Sicher ab | Ihr Zweig | Sicher ab |
|---|---|---|---|
| 7.1 | 7.1.4 | 5.9 | 5.9.20 |
| 7.0 | 7.0.8 | 5.8 | 5.8.19 |
| 6.9 | 6.9.11 | 5.7 | 5.7.21 |
| 6.8 | 6.8.12 | 5.6 | 5.6.23 |
| 6.7 | 6.7.11 | 5.5 | 5.5.24 |
| 6.6 | 6.6.11 | 5.4 | 5.4.25 |
| 6.5 | 6.5.14 | 5.3 | 5.3.27 |
| 6.4 | 6.4.14 | 5.2 | 5.2.30 |
| 6.3 | 6.3.14 | 5.1 | 5.1.28 |
| 6.2 | 6.2.15 | 5.0 | 5.0.31 |
| 6.1 | 6.1.16 | 4.9 | 4.9.35 |
| 6.0 | 6.0.18 | 4.8 / 4.7 | 4.8.34 / 4.7.39 |
Was heisst das für Schweizer Firmen?
WordPress ist das Betriebssystem des Schweizer KMU-Webs. Laut dem Messdienst W3Techs läuft die Hälfte aller .ch-Websites, deren System bekannt ist, auf WordPress, genau 50,8 Prozent. Weltweit sind es 39,5 Prozent aller Websites. Dahinter stehen der Malerbetrieb mit Offertformular, die Treuhandkanzlei mit Kundenportal, der Onlineshop mit Zahlungsanbindung.
Viele dieser Seiten werden nicht von einer IT-Abteilung betreut, sondern von einer Agentur, einem Freelancer oder dem Neffen des Inhabers. Und viele laufen auf alten Ständen. Nach W3Techs nutzen 68,2 Prozent der WordPress-Websites die Hauptversion 7, ein Viertel noch Version 6, weitere 6,6 Prozent Version 5 oder 4. Auch für diese alten Zweige gibt es geflickte Versionen, etwa 6.9.11 oder 5.9.20. Sie kommen aber nur an, wenn automatische Hintergrund-Updates eingeschaltet sind oder jemand sie einspielt.

Dazu kommt das Schweizer Recht. Das Datenschutzgesetz verlangt in Artikel 8, dass eine Firma Personendaten mit angemessenen technischen Massnahmen schützt. Wird eine Website gekapert, über die Kontaktformulare, Bewerbungen oder Bestellungen laufen, ist das eine Verletzung der Datensicherheit. Führt sie voraussichtlich zu einem hohen Risiko für die Betroffenen, muss die Firma sie nach Artikel 24 «so rasch als möglich» dem Eidgenössischen Datenschutzbeauftragten melden. Ein bekanntes, seit Tagen verfügbares Update nicht eingespielt zu haben, ist dabei ein schlechtes Argument.
Wir haben schon im Oktober über zwei kritische Lücken in PHP und WordPress berichtet. Das Muster wiederholt sich, und es wird schneller: Zwischen Patch und Angriff liegen oft nur noch Stunden, wie der Fall der sechs geknackten Firefox-Versionen gezeigt hat. Bei WordPress begannen die Angriffe am Tag der Veröffentlichung.

Wie finde ich die Version ohne Zugang zum Backend?
Viele Inhaber haben gar kein Login für ihre eigene Website, das liegt bei der Agentur. Ein erster Hinweis lässt sich trotzdem in zwei Minuten finden, mit jedem Browser:
- Läuft die Seite überhaupt auf WordPress? Öffnen Sie die Startseite, drücken Sie Ctrl+U (Mac: Cmd+Option+U) für den Quelltext und suchen Sie mit Ctrl+F nach «wp-content». Taucht das Wort auf, ist es WordPress.
- Generator-Angabe suchen. Suchen Sie im selben Quelltext nach «generator». Steht dort etwa «WordPress 7.1.4», ist die Version sichtbar.
- Newsfeed prüfen. Hängen Sie «/feed/» an Ihre Adresse, etwa ihrefirma.ch/feed/. Im Feed steht oft eine Zeile «generator» mit der Versionsnummer.
- Nichts gefunden? Viele Sicherheits-Plugins verstecken die Nummer absichtlich. Das ist gut, sagt aber nichts über den Patch-Stand. Dann hilft nur die Nachfrage beim Betreuer.

Eine Checkliste zum Abhaken, samt Mail-Vorlage für Agentur oder Hoster, hat die Zürcher Agentur Meit zusammengestellt, die wie Leitgrad zu Herausgeber Merag Shahzad gehört: WordPress-Lücke ohne Panik: Was Inhaber jetzt in zwei Minuten prüfen.
Wer keinen Zugang hat, schreibt seinem Betreuer. Die Mail zum Kopieren:
Betreff: WordPress-Sicherheitsupdate CVE-2026-119977
Guten Tag, bitte bestätigen Sie mir bis morgen schriftlich: 1. Welche WordPress-Version läuft auf unserer Website? 2. Ist es 7.1.4 oder die geflickte Version des Zweigs? 3. Sind automatische Sicherheitsupdates eingeschaltet? 4. Haben Sie die Server-Protokolle auf Zugriffe unter /wp-content/upgrade/ geprüft? Besten Dank.
Was sollten Sie heute konkret tun?
Die gute Nachricht: Die Arbeit dauert für eine normale Firmenwebsite eine Viertelstunde. Wer die Website nicht selbst pflegt, schickt diese Liste an die Agentur und verlangt eine schriftliche Bestätigung.
- Version prüfen. Im WordPress-Backend unter «Dashboard», «Aktualisierungen» steht die installierte Version. Sicher sind 7.1.4, 7.0.8, 6.9.11 und die entsprechenden Versionen älterer Zweige.
- Ordner sperren, dann updaten. Wordfence rät, vor dem Update den Zugriff auf PHP-Dateien im Ordner /wp-content/upgrade/ auf dem Webserver zu sperren. Das schliesst das Fenster für den letzten verwundbaren Durchlauf. Ihr Hoster oder Ihre Agentur kann das in wenigen Minuten einrichten.
- Automatische Updates einschalten. Laut Wordfence sind Websites mit aktivierten Hintergrund-Updates bereits geschützt. Wer sie abgestellt hat, etwa aus Angst vor Darstellungsfehlern, sollte zumindest Sicherheitsupdates wieder automatisch zulassen.
- Spuren suchen. In den Zugriffsprotokollen des Servers nach Anfragen auf PHP-Dateien unter /wp-content/upgrade/ suchen, besonders auf setup-config.php. Ein normales Update braucht solche Anfragen von aussen nie.
- Benutzer und Plugins kontrollieren. Unbekannte Administratorkonten, neue Plugins und Restdateien im Ordner /wp-content/upgrade/ sind Alarmzeichen. Dann Passwörter ändern, die Website aus einer sauberen Sicherung zurückholen und prüfen, ob eine Meldung an den Datenschutzbeauftragten nötig ist.
Wichtig für Nutzer der Gratisversion von Wordfence: Sie erhalten die passende Firewall-Regel erst am 27. November. Bis dahin schützt nur das Update selbst.

Wer trägt die Verantwortung für die Website?
Die eigentliche Lehre geht über diese eine Lücke hinaus. Eine Website ist kein Prospekt, den man einmal druckt, sondern Software, die gewartet werden muss wie eine Maschine in der Werkstatt. Wer sie an eine Agentur auslagert, lagert die Arbeit aus, nicht die Verantwortung. Ein Wartungsvertrag mit klarer Frist für Sicherheitsupdates, etwa 48 Stunden, kostet wenig im Vergleich zu einer gekaperten Seite, die Kunden auf Betrugsseiten schickt. Fragen Sie Ihren Dienstleister diese Woche, wer bei Ihnen Updates einspielt, wie schnell und wer es kontrolliert. Wenn die Antwort zögert, haben Sie Ihre nächste Aufgabe gefunden.
Häufige Fragen
Was ist CVE-2026-119977?
CVE-2026-119977 ist eine Lücke im Kern von WordPress, die am 28. Oktober 2026 mit Version 7.1.4 geschlossen wurde. Während eines vollständigen Updates legte WordPress Installationsdateien in einen vorhersehbaren, öffentlich erreichbaren Ordner. Wer diesen Moment trifft, kann ohne Login Code auf dem Server ausführen.
Welche WordPress-Version ist sicher?
7.1.4 und die geflickten Versionen der älteren Zweige, etwa 7.0.8, 6.9.11, 6.8.12, 5.9.20 oder 4.7.39. Die vollständige Liste steht in der Tabelle oben.
Wie prüfe ich die Version ohne Admin-Zugang?
Im Quelltext der Startseite nach «generator» suchen oder den Newsfeed unter /feed/ öffnen. Viele Websites verstecken die Nummer, dann hilft nur eine schriftliche Nachfrage bei Agentur oder Hoster.
Sind Websites mit automatischen Updates geschützt?
Laut Wordfence ja: Websites mit eingeschalteten Hintergrund-Updates sollten bereits auf einer geflickten Version laufen. Prüfen lohnt sich trotzdem, weil Agenturen Auto-Updates oft abschalten.
Ist meine Website betroffen, wenn sie auf WordPress läuft?
Betroffen sind alle Versionen von 4.7 bis 7.1.3, sofern sie nicht schon die geflickte Version ihres Zweigs haben. Ein Blick unter «Dashboard», «Aktualisierungen» zeigt den Stand.
Wurde meine Website schon angegriffen, wenn sie nicht aktualisiert ist?
Nicht zwingend. Der Angriff gelingt nur während eines laufenden Updates. Ein Blick in die Server-Protokolle auf Anfragen unter /wp-content/upgrade/ gibt Hinweise, eine Garantie sind fehlende Einträge aber nicht.
Reicht ein Sicherheits-Plugin als Schutz?
Nur bedingt. Weil der Angriff Dateien trifft, die WordPress gar nicht laden, braucht etwa die Wordfence-Firewall einen erweiterten Modus. Nutzer der Gratisversion erhalten die Regel erst am 27. November. Das Update bleibt der verlässliche Schutz.
Muss ich einen Angriff melden?
Wenn über die Website Personendaten laufen und eine Verletzung voraussichtlich ein hohes Risiko für Betroffene bedeutet, verlangt das Datenschutzgesetz eine Meldung an den Eidgenössischen Datenschutzbeauftragten, so rasch als möglich.

Zum Mitnehmen
- Heute prüfen. Läuft Ihre Website auf WordPress 7.1.4 oder der geflickten Version ihres Zweigs? Wenn nicht, sofort aktualisieren lassen.
- Fenster schliessen. Vor dem Update den Ordner /wp-content/upgrade/ für PHP-Aufrufe sperren, danach Benutzer, Plugins und Protokolle kontrollieren.
- Verantwortung klären. Im Wartungsvertrag eine Frist für Sicherheitsupdates festhalten. Die Agentur macht die Arbeit, haften tut die Firma.
Quellen
- WordPress: Sicherheitshinweis GHSA-4w3m-c66w-69mg, «A race condition during core updates that could lead to remote code execution», 28.10.2026.
- Wordfence: «Attackers Actively Probing for Upgrade-Window RCE Vulnerability in WordPress Core», November 2026.
- NIST, National Vulnerability Database: CVE-2026-119977, mit Eintrag im CISA-Katalog Known Exploited Vulnerabilities (aufgenommen 3.11.2026, Frist 6.11.2026).
- W3Techs: Usage Statistics of WordPress und Content Management Systems for .ch, Stand 6.11.2026.
- Bundesgesetz über den Datenschutz (DSG, SR 235.1), Art. 8 und Art. 24.
- Meit: «WordPress-Lücke ohne Panik», Checkliste und Mail-Vorlage, 7.11.2026.
Erschienen am 6. November 2026, 20:30 Uhr. Aktualisiert am 7. November 2026, 14:16 Uhr. Jede Zahl prüfen wir an der Primärquelle. Fehler gefunden? Hinweis an die Redaktion
Die Redaktion ordnet jeden Werktag die Meldungen ein, die Inhaber und Kader betreffen. Zahlen nur mit Primärquelle.
Wie Leitgrad arbeitetZur RedaktionLeitgrad Morgen-Briefing: jeden Werktag das Wichtigste für Ihre Firma. Lesen · Anhören · Per Mail



