Hast du dein WordPress in den letzten zwei Wochen aktualisiert? Falls nicht, lohnt sich ein Blick ins Dashboard – und zwar jetzt, nicht morgen.
Am 28. Oktober 2026 hat WordPress die Version 7.1.4 veröffentlicht. Offiziell klingt das nach einem von vielen Routine-Updates – 22 behobene Fehler, darunter eine einzelne sicherheitsrelevante Lücke [webhosting.today]. Tatsächlich steht genau diese eine Lücke seit Tagen im Visier von Angreifern, die binnen 24 Stunden zehntausende Mal versucht haben, sie auszunutzen [The Hacker News].
Kurz zusammengefasst: WordPress 7.1.4 (28.10.) schließt eine kritische Race-Condition-Lücke im Core-Update-Prozess (CVE-2026-119977, CVSS 8,1). Betroffen sind alle Versionen von 4.7 bis 7.1.3. Seit dem Patch laufen zehntausende automatisierte Angriffsversuche. Bislang keine bestätigten Kompromittierungen – aber nur, wenn du jetzt aktualisierst.
WordPress 7.1.4: Was ist passiert
Die Lücke trägt inzwischen die Kennung CVE-2026-119977 (vergeben am 31. Oktober) und steckt nicht in einem Plugin, sondern im WordPress-Kern selbst – genauer: im Update-Mechanismus [Wordfence, zitiert via windows-faq.de]. Betroffen sind alle Versionen von WordPress 4.7 bis 7.1.3, also praktisch jede Installation, die seit dem 28. Oktober nicht aktualisiert wurde.
Wordfence bewertet die Lücke mit einem CVSS-Wert von 8,1 (hoch). WordPress selbst stuft sie in der eigenen Einschätzung niedriger ein – aus einem nachvollziehbaren Grund, wie der nächste Abschnitt zeigt [windows-faq.de].
Wie die Lücke funktioniert – einfach erklärt
Wenn WordPress ein vollständiges Core-Update einspielt, entpackt es die neuen Dateien kurzzeitig in einen Ordner namens wp-content/upgrade. Dieser Ordner lag bislang an einem vorhersehbaren Pfad und war über den Browser erreichbar – inklusive des WordPress-Installers, der sich darin befindet [The Hacker News].
Wer genau in diesem kurzen Zeitfenster zugreift, kann über den Installer eigenen Code auf dem Server ausführen. „Kurz“ ist hier wörtlich zu nehmen: Wordfence hat das Zeitfenster in eigenen Labortests auf wenige Sekunden geschätzt [The Hacker News]. Das erklärt auch, warum WordPress die Lücke selbst niedriger einstuft als Wordfence – unter normalen Umständen ist sie schwer zu treffen. Nur: Bei Millionen von WordPress-Seiten, die alle ungefähr zur gleichen Zeit automatische Updates ausführen, reicht ein kleines Zeitfenster für automatisierte Angreifer locker aus.
Mit 7.1.4 hat WordPress das Problem an der Wurzel behoben: Der Staging-Ordner bekommt jetzt einen zufälligen, nicht vorhersehbaren Namen, das Verzeichnislisting ist blockiert, und Konfigurationsdaten werden nicht mehr unsicher aus dem Staging-Bereich übernommen [windows-faq.de].
Wie massiv wird die Lücke angegriffen
Die Zahlen schwanken je nach Quelle und Messfenster, zeichnen aber ein eindeutiges Bild. Wordfence zählte in den ersten 21 Stunden nach Aktivierung der eigenen Firewall-Regel über 18.500 Anfragen an die verwundbaren Staging-Pfade [webhosting.today]. The Hacker News berichtete am 30. Oktober von 62.969 blockierten Angriffen binnen 24 Stunden [The Hacker News]. Die beiden Zahlen sind nicht direkt vergleichbar, weil sie unterschiedliche Zeitfenster und Messgrundlagen verwenden – aber beide zeigen: Hier wird nicht vereinzelt, sondern automatisiert und in großem Stil nach verwundbaren Seiten gesucht.
Die gute Nachricht bisher: Weder Wordfence noch die anderen ausgewerteten Quellen berichten von bestätigten erfolgreichen Kompromittierungen [webhosting.today]. Das kann sich ändern – und ändert nichts daran, dass ungepatchte Seiten weiterhin ein offenes Ziel sind.
Was du jetzt tun solltest
- Version prüfen. Im WordPress-Dashboard unter „Dashboard → Aktualisierungen“ oder per Konsolenbefehl
wp core versionnachsehen, ob 7.1.4 (oder der passende Backport, z. B. 7.0.8, 6.9.11, 6.8.12) tatsächlich installiert ist. Automatische Updates laufen nicht immer zuverlässig – lieber einmal zu viel nachsehen. - Auch Staging- und Alt-Installationen prüfen. Gerade Testumgebungen und vergessene alte WordPress-Installationen werden bei solchen Checks oft übersehen, sind aber genauso angreifbar.
- Webzugriff auf
wp-content/upgrade/sperren. Zusätzlich zum Update, nicht statt dem Update – etwa per Nginx-Regel (location ^~ /wp-content/upgrade/ { deny all; }) oder einer entsprechenden Regel beim Hoster. - Logs kontrollieren. Zugriffe auf PHP-Dateien unter
wp-content/upgradein den Logs der letzten Woche sind ein Hinweis auf einen Angriffsversuch – nicht automatisch auf einen erfolgreichen. - Bei Verdacht: Admin-Konten, Plugins und Dateien prüfen. Unbekannte Administrator-Benutzer, Plugins, die niemand installiert hat, oder fremde PHP-Dateien sind Alarmzeichen. Im Zweifel die Seite isolieren und aus einem sauberen Backup vor dem Vorfall wiederherstellen.
- Wordfence-Nutzer: Die „Extended Protection“-Regel ist für zahlende Kunden seit dem 28. Oktober aktiv, für die kostenlose Version laut Wordfence erst ab dem 27. November. Bis dahin ersetzt sie bei Free-Nutzern nicht das Update [webhosting.today].
Warum eine Core-Lücke anders ist als eine Plugin-Lücke
In den letzten Monaten haben wir hier öfter über Plugin-Sicherheitslücken geschrieben – etwa bei LatePoint, Amelia oder dem Backup-Plugin „All-in-One WP Migration“. Das hier ist etwas anderes: Eine Lücke im WordPress-Kern selbst betrifft nicht eine einzelne Erweiterung, sondern grundsätzlich jede WordPress-Seite, unabhängig davon, welche Plugins oder welches Theme installiert sind. Das passiert selten – die letzten Core-Sicherheitsupdates (7.0.2, 7.1.1, 7.1.2) kamen jeweils ohne eine vergleichbar breite, aktiv ausgenutzte Lücke.
Ich sehe in der Praxis immer wieder Seiten, bei denen automatische Updates zwar aktiviert sind, aber aus irgendeinem Grund – ein Hosting-Limit, ein Konflikt mit einem Plugin, eine fehlgeschlagene Aktualisierung, die niemand bemerkt hat – seit Monaten nicht mehr gelaufen sind. Genau diese Seiten sind jetzt das Ziel. Wer das bei sich selbst nicht regelmäßig kontrolliert, für den biete ich die laufende Prüfung und Aktualisierung im Rahmen der WordPress-Wartung an – inklusive einer Benachrichtigung, wenn wirklich mal Handlungsbedarf besteht, so wie hier.
Häufige Fragen
Muss ich sofort handeln, wenn ich automatische Updates aktiviert habe?
Prüfen ja, in Panik verfallen nein. Automatische Updates sind kein Garant dafür, dass sie auch wirklich durchgelaufen sind – ein kurzer Blick auf die Versionsnummer im Dashboard schafft Klarheit.
Ist meine Seite schon kompromittiert, wenn ich noch nicht aktualisiert habe?
Nicht automatisch. Bislang gibt es keine bestätigten erfolgreichen Kompromittierungen über diese Lücke. Ein Blick in die Zugriffslogs auf Anfragen unter wp-content/upgrade seit dem 28. Oktober schafft zusätzliche Sicherheit.
Reicht eine Firewall wie Wordfence als Ersatz für das Update?
Nein. Patchstack weist ausdrücklich darauf hin, dass die reguläre WordPress-Firewall hier nicht greift, weil die Staging-Kopie eigene Dateien ausführt und damit an der normalen Firewall-Prüfung vorbeiläuft. Eine Firewall-Regel kann zusätzlich schützen, ersetzt das Update aber nicht.
Betrifft das auch gemanagtes Hosting, zum Beispiel bei einem Managed-WordPress-Anbieter?
Kommt darauf an, ob der Hoster automatische Core-Updates zentral übernimmt oder das dem Seitenbetreiber überlässt. Im Zweifel beim Hoster nachfragen oder selbst in wp-admin die Versionsnummer prüfen – schadet in keinem Fall.
Ich hoffe, das hilft dir, deine eigene Seite schnell einzuschätzen. Falls du unsicher bist, ob deine WordPress-Version wirklich aktuell ist oder sich schon mal jemand die Logs angeschaut hat: Ich schaue mir das gern mit dir an.
Mehr zum Thema laufende Pflege findest du auf der Seite zur WordPress-Wartung, oder du schreibst mir direkt. Frühere Sicherheitsupdates wie WordPress 7.1.2 und 7.1.1 findest du ebenfalls im Blog.
Quellen
- The Hacker News: „WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in One Day“ (30.10.2026)
- webhosting.today: „WordPress update flaw draws tens of thousands of attack attempts“ (02.11.2026)
- windows-faq.de: „WordPress 7.1.4 – CVE-2026-119977 Sicherheitslücke“ (02.11.2026)
- WordPress.org: Version 7.1.4 (Changelog)
