Sicherheitsnews

WordPress 7.1.4 schließt eine Race Condition im Updater: so blockiert Hive sie

30. Oktober 2026 · Patrick Schlesinger

WordPress 7.1.4 schließt eine Race Condition im Core-Updater, über die ein Angreifer ohne Konto eine Website in den wenigen Sekunden eines Updates übernehmen konnte. Angreifer scannen bereits danach, und ReportedIP Hive blockiert diese Anfragen auf jeder Installation.

Aktualisieren Sie zuerst WordPress. Der Rest dieses Beitrags erklärt die Lücke, warum die meisten Plugin-Firewalls den Angriff nicht sehen und was Hive dagegen tut.

Was ist die Race Condition im Updater von WordPress 7.1.4?

Bei einem vollständigen Core-Update entpackt WordPress das ganze Paket in einen Ordner unter wp-content/upgrade/. Vor 7.1.4 hatte dieser Ordner einen vorhersagbaren Namen: den Paketnamen plus ein kurzes zufälliges Suffix. Beim Aufräumen wurde außerdem die index.php entfernt, die den Ordner sonst schützt.

Für einige Sekunden liegt in diesem Ordner eine vollständige, lauffähige Kopie von WordPress. Wer in diesem Zeitfenster die dort abgelegte wp-admin/setup-config.php oder install.php aufruft, kann die Kopie mit einer eigenen Datenbank verbinden und am Ende eigenen Code auf dem Server ausführen. Dafür braucht es weder einen Login noch eine Aktion eines Nutzers.

Gemeldet hat die Lücke Umut Bayram. Der Release-Beitrag zu WordPress 7.1.4 beschreibt sie als Schwachstelle im Update-Prozess, die während des Update-Fensters zur Ausführung von Code aus der Ferne führen kann. Eine CVE-Nummer gibt es zum Zeitpunkt dieses Beitrags noch nicht.

Welche WordPress-Versionen sind betroffen, welche beheben die Lücke?

Punkt	Angabe
Betroffen	WordPress 4.7 bis 7.1.3
Wann eine Website angreifbar ist	Nur solange bei einem Update ein vollständiges Core-Paket entpackt ist
Behoben in	7.1.4, 7.0.8, 6.9.11, 6.8.12
Ältere Versionszweige	Backports bis hinunter zu 4.7.39
Gemeldet von	Umut Bayram
CVE	Zum Zeitpunkt dieses Beitrags noch keine vergeben

Der Fix ändert drei Dinge. Der Name des Entpack-Ordners endet jetzt auf 16 zufällige Zeichen. Die schützende index.php bleibt erhalten. Und wp-config.php wird nicht mehr aus dem Arbeitsordner kopiert. Patchstack und HOL gehen den Patch im Detail durch.

Scannen Angreifer schon nach der Update-Lücke?

Die Scans begannen direkt nach dem Release. Wordfence zählte in den ersten 21 Stunden mehr als 18.500 Anfragen auf entpackte Installer-Pfade, wie GBHackers berichtet. Die Scanner fragen wahrscheinliche Ordnernamen immer wieder ab und warten darauf, dass eine Website ein Update startet.

Warum übersehen gewöhnliche WordPress-Firewalls diesen Angriff?

Die entpackte Kopie startet aus ihren eigenen Dateien. Eine Anfrage an wp-content/upgrade/…/wp-admin/setup-config.php lädt nie das eigentliche WordPress der Website, also läuft dabei auch keines ihrer Plugins. Eine Firewall in einem Plugin kann keine Anfrage blockieren, die sie nie zu sehen bekommt. Patchstack und Wordfence sagen das Gleiche über Firewalls auf PHP-Ebene.

Wie schützt ReportedIP Hive vor der Race Condition im Updater?

Wir schützen unsere Kunden. Die Hive-WAF blockiert diese Anfragen, und das Hive-Update 3.0.6 ist ausgerollt und schließt das Update-Fenster auf Apache.

Eine neue WAF-Signatur im Regel-Feed

Der Regel-Feed, den jede Hive-Installation bekommt, enthält eine Signatur für diesen Angriff. Sie greift bei jeder Anfrage nach einer PHP-Datei unter wp-content/upgrade/ oder wp-content/upgrade-temp-backup/. Keine legitime Anfrage lädt dort jemals PHP, deshalb stört die Regel normale Updates nicht.

• Sie ist in allen Tarifen aktiv, auch in Free.
• Websites im Modus Community Network erhalten sie automatisch. Niemand muss eine Einstellung ändern.
• Bei einem Treffer antwortet Hive mit 403 und sperrt die IP schon bei der ersten Anfrage.
• Die IP geht an das Community Network, so landen scannende IPs für jede verbundene Website auf der gemeinsamen Blocklist.

Wo die Anfrage WordPress erreicht, blockiert Hive sie

Eine WAF innerhalb von WordPress kann nur Anfragen bearbeiten, die WordPress erreichen. Auf Apache landen Anfragen an nicht vorhandene Entpack-Pfade bei WordPress, also werden Scanner, die falsche Ordnernamen raten, dort erkannt und gesperrt. Websites mit eingeschaltetem Erweitertem Schutz starten die Firewall vor WordPress und sind deshalb auch geschützt, während ein Update entpackt wird.

Hive 3.0.6 schließt das Update-Fenster auf Apache

Offen bleibt der Ordner, der während eines Updates tatsächlich existiert. Hive 3.0.6 löst das je nach Webserver:

• Apache: Hive schreibt automatisch eine Rewrite-Regel in die .htaccess im Hauptverzeichnis der Website. Sie leitet jede PHP-Anfrage unter wp-content/upgrade/ an WordPress, wo die WAF sie blockiert, auch mitten in einem Update.
• nginx: nginx liest keine .htaccess. Die Firewall-Einstellungen von Hive zeigen einen fertigen Abschnitt für den Server-Block: location ^~ /wp-content/upgrade/ { rewrite ^ /index.php last; }
• Local Shield: Die Regel steckt auch in der mitgelieferten Basis-Regelsammlung, Websites ohne Feed-Verbindung bekommen sie also mit dem Update.

Das Update kommt über die normale Update-Seite von WordPress, wie schon das Release Hive 3.0.5.

Was sollten Betreiber von WordPress-Websites jetzt tun?

1. Aktualisieren Sie WordPress auf die gepatchte Version Ihres Versionszweigs: 7.1.4, 7.0.8, 6.9.11, 6.8.12 oder den Backport für einen älteren Zweig.
2. Durchsuchen Sie die Access-Logs nach Anfragen an setup-config.php oder install.php unter /wp-content/upgrade/.
3. Prüfen Sie, dass wp-content/upgrade/ nichts außer index.php enthält.
4. Suchen Sie nach unbekannten Administrator-Konten und nach PHP-Dateien in wp-content/uploads/.

Ohne Hive können Sie den Ordner auf Server-Ebene sperren. Die Regeln unten weisen jede Anfrage an ihn ab:

# nginx, im server-Block
location ^~ /wp-content/upgrade/ { deny all; }

# Apache, in der .htaccess im Hauptverzeichnis
RedirectMatch 403 ^/wp-content/upgrade/

Beide Regeln passen gut zur Checkliste zur WordPress-Härtung, mit oder ohne Hive.

FAQ zum Sicherheitsrelease WordPress 7.1.4

Müssen Hive-Nutzer etwas tun?

Hive-Nutzer müssen nur WordPress selbst aktualisieren. Die WAF-Signatur erreicht verbundene Websites von allein über den Regel-Feed, und das Hive-Update 3.0.6 schreibt die Apache-Regel automatisch. Auf nginx fügen Sie den Abschnitt aus den Firewall-Einstellungen von Hive ein, um auch dort das Update-Fenster zu schließen.

Ist eine Website gefährdet, wenn gerade kein Update läuft?

Angreifbar ist eine Website nur, solange ein vollständiges Core-Paket entpackt in wp-content/upgrade/ liegt, das dauert pro Update einige Sekunden. Außerhalb dieses Fensters gibt es den entpackten Installer nicht. Websites mit automatischen Core-Updates durchlaufen dieses Fenster von selbst, deshalb ist das Update auf 7.1.4 trotzdem wichtig.

Blockiert die Hive-Regel normale WordPress-Updates?

Die Hive-Regel blockiert keine Updates. WordPress entpackt und kopiert die Dateien direkt auf dem Server und lädt nie PHP aus dem Entpack-Ordner über HTTP. Nur Anfragen von außen nach diesen PHP-Dateien treffen die Regel, und kein legitimer Besucher oder Dienst stellt solche Anfragen.