Sicherheitsrelease WordPress 7.1.4: was Agenturen heute tun sollten

Update, 5. November 2026: Wordfence zählt inzwischen mehr als 240.000 blockierte Versuche gegen diese Lücke seit dem 28. Oktober, mit einer Spitze von über 74.000 am 30. Oktober. CISA hat CVE-2026-119977 am 2. November in den Katalog Known Exploited Vulnerabilities aufgenommen. Wordfence hält einen erfolgreichen Angriff in der Praxis weiterhin für schwierig, weil er nur in den Sekunden funktioniert, in denen ein Update läuft. Ihr Rat ist derselbe wie unserer: Aktualisieren Sie jetzt auf 7.1.4 oder den Backport Ihres Versionszweigs, und blockieren Sie PHP-Dateien in wp-content/upgrade/ auf dem Webserver, bevor Sie aktualisieren. Nutzer der kostenlosen Wordfence-Version erhalten die Firewall-Regel am 27. November. Quelle: Wordfence, 5. November 2026.

Update, 31. Oktober 2026: die Angriffe nehmen zu. Wordfence meldet jetzt fast 59.000 blockierte Versuche in 24 Stunden gegen die temporären Installationsdateien in wp-content/upgrade/ (nach 18.500 in den ersten 21 Stunden). Weiterhin keine bestätigten Einbrüche. Ist eine Kunden-Website noch nicht auf 7.1.4 oder dem Backport ihres Zweigs, aktualisieren Sie sie heute und sperren Sie den Upgrade-Ordner auf dem Server; warten Sie nicht bis Montag.

WordPress 7.1.4 erschien am 28. Oktober 2026 als Sicherheitsrelease. Es behebt 22 Sicherheitslücken in 17 Hinweisen, und dieselben Korrekturen wurden in jeden unterstützten Zweig bis hinunter zu 4.7.39 zurückportiert. Eine davon ist ungewöhnlich: eine Lücke im Update-Prozess des Kerns selbst, für die kein Login nötig ist. Sie ist schwer auszunutzen, aber Angreifer begannen innerhalb eines Tages danach zu suchen, und es ist das einzige Problem in diesem Release, das eine Plugin-Firewall nicht stoppen kann. Hier lesen Sie, was das für die Kunden-Websites bedeutet, die Sie betreuen, und was heute zu tun ist.

Was behoben ist

• Codeausführung ohne Login während eines Updates. Vor 7.1.4 hatte der Ordner, in den WordPress Updates entpackt, innerhalb von wp-content/upgrade/, einen vorhersehbaren Namen, und die Bereinigung entfernte die index.php , die das Auflisten des Verzeichnisses verhindert. Ein Angreifer, der die wenigen Sekunden trifft, in denen ein Update läuft, auf einer Website, auf der dieser Ordner über das Web erreichbar ist, konnte Code ausführen. Patchstack stuft die Angriffskomplexität als hoch ein und hält eine Ausnutzung nicht für praktikabel. Weil die entpackte Kopie die Plugins Ihrer Website nicht lädt, kann ein Firewall-Plugin auf PHP-Ebene diese Anfrage nicht blockieren.
• Gespeichertes XSS ab Konten mit der Rolle Mitarbeiter, vor allem in der Interactivity API (7 der 17 Hinweise) und in mehreren Kernblöcken.
• Customizer: unveröffentlichte Änderungssätze konnten von nicht angemeldeten Besuchern gesehen werden.

Wer betroffen ist

Jede Website mit einer Version unter 7.1.4 oder unter dem passenden Backport (7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 und so weiter, bis hinunter zu 4.7.39). Websites mit 4.6 oder älter bekommen gar keine Korrektur. Die XSS-Probleme wiegen am schwersten auf Websites, auf denen Kunden, Autoren oder Gastautoren Konten mit der Rolle Mitarbeiter oder höher haben.

Eine Website in zwei Minuten prüfen

1. Version: gehen Sie in wp-admin zu Dashboard → Aktualisierungen, oder führen Sie aus: wp core version. Alles unter 7.1.4 (oder dem Backport Ihres Zweigs) braucht das Update.
2. Upgrade-Ordner: öffnen Sie https://example.com/wp-content/upgrade/ in einem privaten Fenster. Ein 403 oder 404 ist das, was Sie wollen. Eine Dateiliste oder eine leere 200-Seite bedeutet, dass der Ordner über das Web erreichbar ist.
3. Konten: filtern Sie unter Benutzer nach Mitarbeiter, Autor und Redakteur. Entfernen Sie die Konten, die niemand nutzt.

Was jetzt zu tun ist

1. Kern aktualisieren auf 7.1.4 oder den Backport für Ihren Zweig. Kleine Sicherheitsreleases installieren sich normalerweise selbst; prüfen Sie, ob das passiert ist, denn Hoster und manche Plugins schalten automatische Kern-Updates ab. Sorgen Sie zuerst für ein frisches Backup, und prüfen Sie danach Startseite, ein Formular und den Checkout.
2. Webzugriff auf den Upgrade-Ordner sperren auf dem Webserver, nicht in einem Plugin. Unter Apache eine .htaccess -Datei in wp-content/upgrade/ mit Require all denied. Unter nginx: location ^~ /wp-content/upgrade/ { deny all; }. WordPress schreibt weiterhin über PHP in den Ordner, Updates funktionieren also weiter. Bei Managed Hosting, wo Sie den Server nicht ändern können, bitten Sie Ihren Hoster darum.
3. Websites mit 4.6 oder älter: planen Sie jetzt den Umstieg auf eine unterstützte Version. Für sie wird es keine Korrektur geben.

Angreifer suchen nach dieser Lücke, aber erfolgreiche Einbrüche sind nicht bestätigt, daher braucht eine aktualisierte Website mit gesperrtem Upgrade-Ordner allein wegen dieses Releases keine Wiederherstellung und keine neuen Schlüssel. Sehen Sie aber unbekannte Dateien in wp-content/upgrade/ oder neue Administratorkonten, behandeln Sie es als Kompromittierung: Stellen Sie aus einem Backup von vor dem Auftauchen dieser Dateien wieder her und ändern Sie dann Passwörter und Salts. Unsere Routine für den Tag einer Sicherheitslücke enthält alle Schritte.

Wie Verploy hilft

Jedes Update wird geprüft. Riskante Updates werden zuerst auf einer Kopie getestet. Der WordPress-Kern gilt immer als riskant: Er wird auf einer privaten Kopie der Website getestet, bevor sich die Live-Website ändert, und schlägt nach dem Livegang eine Prüfung fehl, wird die Website automatisch zurückgesetzt. Nächtliche verschlüsselte Backups in der EU geben Ihnen einen sauberen Punkt zum Zurückkehren, und bekannte Sicherheitslücken erscheinen pro Website mit einem Link zur Quelle.

Quelle: Patchstack, „WordPress 7.1.4 Security Release“, 28. Oktober 2026, patchstack.com. Warnung von Wordfence vor Ausnutzung, 29. Oktober 2026, wie berichtet von SecurityOnline; 24-Stunden-Zahl wie berichtet von CyberPress, 31. Oktober 2026. Geprüft am 31. Oktober 2026.