WordPress 7.1.4: Angreifer zielen auf das Zeitfenster beim Core-Update

WordPress hat am 28. Oktober 2026 Version 7.1.4 veröffentlicht und 22 Sicherheitslücken geschlossen. Eine davon lässt sich ohne Anmeldung ausnutzen, und zwar in den Sekunden, in denen eine Website ihr Core-Update entpackt. Angreifer suchen bereits gezielt danach. Erfolgreiche Einbrüche waren laut Dr. Web am 30. Oktober nicht bekannt. Stand dieses Beitrags ist der 2. November 2026.

Die Lücke öffnet sich nur während eines vollständigen Core-Updates

Bei einem Update mit dem vollständigen Paket entpackt WordPress die neuen Dateien in ein vorhersagbares Verzeichnis, das aus dem Web erreichbar ist. So beschreibt es das Advisory von WordPress. Die Kopie unter wp-content/upgrade enthält auch den Installer. Wer sie im richtigen Moment aufruft, kann laut The Hacker News PHP-Code auf dem Server ausführen.

Ein Konto braucht der Angreifer dafür nicht, wohl aber Timing. Das Verzeichnis existierte in Testumgebungen laut heise online nur Sekunden. Außerdem muss PHP in diesem Verzeichnis öffentlich ausführbar sein, wie SecurityWeek unter Berufung auf Wordfence schreibt.

Zwei Details betreffen deutschsprachige Websites besonders. Übersetzte Installationen bekommen laut Dr. Web nur das vollständige Paket angeboten. Und das Update auf 7.1.4 läuft laut Dr. Web selbst noch mit dem alten Code. Der neue Schutz mit zufälligem Verzeichnisnamen greift also erst bei späteren Updates.

Die Bewertungen gehen weit auseinander

WordPress stuft die Lücke in seinem Advisory als niedrig ein und nennt dort keine CVE-Nummer. Wordfence bewertet sie dagegen mit CVSS 8.1 („hoch“) und hat sie am 31. Oktober als CVE-2026-119977 veröffentlicht. Der CVSS-Vektor der CVE wertet die Folgen als schwer, die Komplexität des Angriffs aber ebenfalls als hoch.

Die Zahlen zu den Angriffsversuchen stammen von Wordfence und unterscheiden sich je nach Bericht. Heise nennt mehr als 18.500 Anfragen in den ersten 21 Stunden nach dem Start der Firewall-Regel. The Hacker News nennt 62.969 blockierte Versuche in 24 Stunden. Die erste Anfrage kam laut SecurityWeek neun Minuten nach dem Start der Regel. Beide Zahlen zählen Versuche, keine Einbrüche.

Diese Versionen enthalten den Fix

Aktuell ist WordPress 7.1.4. Für ältere Zweige gibt es Sicherheitsupdates bis zurück zu 4.7:

• 7.0.8, 6.9.11, 6.8.12 und 6.7.11
• 6.6.11, 6.5.14 und 6.4.14
• weitere Versionen bis 4.7.39

WordPress 4.6 und älter bekommen keine Updates mehr. Aktiv unterstützt wird nur die jeweils neueste Version. Welche Version läuft, sehen Sie im Dashboard unter „Aktualisierungen“. WordPress installiert Updates laut heise standardmäßig automatisch. Prüfen Sie trotzdem, ob das bei Ihrer Website wirklich passiert ist.

Sperren Sie das Upgrade-Verzeichnis im Webserver

Patchstack rät, den Zugriff auf wp-content/upgrade/ im Webserver zu verbieten und zu prüfen, dass sich das Verzeichnis nicht auflisten lässt. Zwischen zwei Updates liegt dort laut Patchstack nur eine index.php.

Auf ein Sicherheits-Plugin allein sollten Sie sich dabei nicht verlassen. Patchstack schreibt, eine PHP-Firewall könne den Zugriff nicht blockieren, weil sie bei dieser Anfrage gar nicht läuft. Die Regel von Wordfence setzt laut Dr. Web die Funktion „Extended Protection“ voraus. Nutzer der kostenlosen Version erhalten sie erst am 27. November.

So suchen Sie nach Spuren eines Angriffs

War Ihre Website nicht rechtzeitig aktualisiert, empfiehlt heise einen Blick auf diese Punkte:

• Anfragen auf PHP-Dateien unter wp-content/upgrade in den Logs des Webservers
• unerwartete PHP-Dateien in diesem Verzeichnis oder an anderen Stellen
• unbekannte Administratorkonten
• Plugins, die niemand installiert hat

Finden Sie Spuren eines Einbruchs, kann der Angreifer laut Dr. Web auf alle Daten der Website zugegriffen haben. Dann ist zu prüfen, ob eine Meldung an die Datenschutzaufsicht binnen 72 Stunden nötig ist (Art. 33 DSGVO). Das ist eine Information, keine Rechtsberatung.

Die übrigen Lücken setzen meist ein Konto voraus

Patchstack ordnet die 22 Lücken 17 Advisories zu. Die meisten sind Stored-XSS-Fehler. Dabei legt jemand Schadcode in Inhalten ab, der später im Browser anderer Nutzer läuft. In der Regel braucht der Angreifer dafür mindestens die Rolle „Mitarbeiter“ (Contributor). Eine weitere Ausnahme ohne Konto ist die Lücke, über die unveröffentlichte Customizer-Änderungen sichtbar werden.

Patchstack empfiehlt deshalb, zu prüfen, wer auf Ihrer Website diese Rolle oder eine höhere besitzt.

Wir halten den Server aktuell, WordPress braucht einen eigenen Verantwortlichen

Bei unseren Managed Servern gehören Sicherheitsupdates dazu. Die Lücke zeigt aber, dass auch die Anwendung und die Regeln im Webserver jemanden brauchen, der sich darum kümmert.

Wenn Sie nicht sicher sind, welche WordPress-Version bei Ihnen läuft oder wer sie pflegt, schreiben Sie uns.