WordPress-Sicherheitslücke CVE-2026-119977: Wenn das Update selbst zum Einfallstor wird

„Halten Sie WordPress aktuell“ ist der wichtigste Ratschlag für jede Firmenwebsite. Ausgerechnet der Update-Vorgang war aber jahrelang angreifbar: Während WordPress ein Core-Update einspielt, liegen die neuen Dateien für wenige Sekunden in einem vorhersehbaren Verzeichnis, das aus dem Internet erreichbar ist. Wer in diesem Moment die richtige Adresse aufruft, kann ohne Konto eigenen Code auf dem Server ausführen. Die US-Behörde CISA führt die Lücke seit dem 3. November als aktiv ausgenutzt.

Was passiert ist

28. Oktober: WordPress veröffentlichte die Version 7.1.4. Die Release-Notiz nennt eine Schwäche im Upgrade-Prozess, die „während des Upgrade-Fensters“ zu Remote Code Execution führen kann, gemeldet von Umut Bayram (Picus Security). Laut WordPress werden die Korrekturen auf alle Zweige bis 4.7 zurückportiert. Für ältere Zweige nennen Sicherheitsanalysen unter anderem 7.0.8, 6.9.11 und 6.8.12 als korrigierte Stände.

Ende Oktober: Kurz nach der Veröffentlichung begannen die Angriffe. Wordfence zählte in den ersten 21 Stunden mehr als 18.500 Anfragen auf die betroffenen Installer-Pfade. Der Honeypot-Betreiber Previdian sah am 30. Oktober erste Versuche.

3. November: Die CISA nahm CVE-2026-119977 in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) auf. US-Bundesbehörden mussten bis zum 6. November patchen. Für Unternehmen in Deutschland ist das keine Pflicht, aber ein klares Signal: Die Lücke wird nicht nur theoretisch angegriffen.

Wie der Angriff funktioniert

Bei einem vollständigen Core-Update entpackt WordPress das neue Paket zunächst in einen Arbeitsordner unter wp-content/upgrade/. Ab Version 5.9 ist dessen Name laut Ostorlab vorhersehbar, etwa wordpress-7.1.4. Im Paket steckt auch der Installationsassistent wp-admin/setup-config.php. Der verweigert seinen Dienst normalerweise, weil eine wp-config.php existiert. Im Arbeitsordner fehlt diese Datei aber. Ein Angreifer, der den Assistenten dort im richtigen Moment aufruft, kann eine eigene Konfiguration schreiben lassen und so Code ausführen.

Das Zeitfenster ist kurz, im Labor nur Sekunden. Automatisierte Werkzeuge rufen die Pfade aber einfach dauerhaft ab und warten auf den richtigen Moment. Genau das zeigen die Zugriffszahlen von Wordfence.

Warum das KMU besonders betrifft

Viele mittelständische Unternehmen betreiben ihre Website mit WordPress, oft betreut von einer Agentur oder einem Freelancer. Auf demselben Server liegen häufig Kontaktformulare mit Kundendaten, Bewerberportale oder ein Shop. Gerade dort sind automatische Updates eingeschaltet, was sonst richtig ist. Hier bedeutet es aber: Jeder Update-Lauf öffnet das Fenster, ohne dass jemand zuschaut.

Dazu kommt ein organisatorisches Problem. Die Website gilt oft als Marketing-Thema und taucht in keinem Patch- oder Asset-Verzeichnis der IT auf. Das ist riskant: Ein kompromittierter Webserver kann Malware an Kunden ausliefern, für Phishing missbraucht werden oder Daten aus Formularen abfließen lassen.

Was NIS2, ISO 27001 und DSGVO dazu verlangen

Für NIS2-pflichtige Unternehmen gehört die Behandlung von Schwachstellen nach § 30 BSIG zu den Risikomanagement-Maßnahmen, die die Geschäftsleitung billigen und überwachen muss. Das gilt auch für die Website, wenn sie Teil Ihrer Dienste ist oder Zugang zu internen Systemen bietet. Ein erheblicher Vorfall löst die Meldepflichten an das BSI aus.

In ISO 27001 sind vor allem A.8.8 (Umgang mit technischen Schwachstellen), A.8.9 (Konfigurationsmanagement) und A.5.22 (Überwachung von Lieferantenleistungen) einschlägig, wenn eine Agentur die Seite betreut. Wurden über die Website personenbezogene Daten abgegriffen, prüfen Sie mit Ihrem Datenschutzbeauftragten eine Meldung nach Art. 33 DSGVO binnen 72 Stunden.

Fünf Maßnahmen für Ihre WordPress-Website

1. Version prüfen

Prüfen Sie im Dashboard oder mit wp core version, welcher Stand läuft. Ziel ist 7.1.4 oder die korrigierte Version Ihres Zweigs. Mit wp core verify-checksums erkennen Sie veränderte Core-Dateien. Vergessen Sie Test-, Staging- und Kampagnenseiten nicht.

2. Upgrade-Ordner sperren

Sperren Sie den Webzugriff auf /wp-content/upgrade/ in der Serverkonfiguration, bei nginx etwa mit location ^~ /wp-content/upgrade/ { deny all; }, bei Apache zum Beispiel mit RedirectMatch 403 ^/wp-content/upgrade/ in der zentralen .htaccess. Eine .htaccess im Upgrade-Ordner selbst hilft nicht, weil der Updater dessen Inhalt löscht. Bei Managed Hosting fragen Sie Ihren Anbieter, ob er das bereits sperrt.

3. Nach Spuren suchen

Durchsuchen Sie die Zugriffsprotokolle seit Ende Oktober nach Aufrufen von PHP-Dateien unter wp-content/upgrade/, besonders setup-config.php. Prüfen Sie den Ordner auf unerwartete PHP-Dateien, die Benutzerliste auf unbekannte Administratoren und die Plugin-Liste auf Unbekanntes. Bei Treffern behandeln Sie den Server als kompromittiert und starten Ihren Notfallplan.

4. Zuständigkeit klären

Legen Sie schriftlich fest, wer Updates einspielt, wer Sicherheitsmeldungen verfolgt und wie schnell kritische Lücken geschlossen werden. Bei externen Dienstleistern gehört das in den Vertrag. Unser Beitrag zum Patch-Management unter NIS2 zeigt, wie ein solcher Prozess aussieht.

5. Website in die Schwachstellenprüfung aufnehmen

Die Website gehört in Ihr Asset-Verzeichnis und in die regelmäßige Prüfung. Ein externer Schwachstellenscan zeigt veraltete Versionen und offene Pfade, die kostenlosen TSMONDO Check-Tools geben einen ersten Blick auf Ihre Außensicht. Ein aktuelles Backup vor jedem Update gehört ohnehin dazu.

Fazit

CVE-2026-119977 ist kein Grund, automatische Updates abzuschalten. Ohne Updates wäre die Website schnell deutlich angreifbarer. Die Lücke zeigt aber, dass „läuft automatisch“ keine Sicherheitsstrategie ist. Wer den Upgrade-Ordner sperrt, die Version prüft und die Protokolle einmal durchsieht, hat das Thema in einer Stunde erledigt. Wer nicht weiß, wer die Website eigentlich betreut, hat eine wichtigere Baustelle gefunden.

Quellen: WordPress.org, Release-Notiz „WordPress 7.1.4“ (28.10.2026); The Hacker News zur KEV-Aufnahme mit Zahlen von Wordfence und Previdian (04.11.2026); Ostorlab-Analyse zu CVE-2026-119977 (31.10.2026, aktualisiert 07.11.2026); AICybr zu betroffenen und korrigierten Versionen (02.11.2026). Versionsangaben je Zweig stammen aus diesen Analysen und wurden nicht gegen das GitHub-Advisory abgeglichen. Stand: 10.11.2026. Dieser Beitrag ersetzt keine Rechtsberatung.

Weiterlesen