Am 28.10.2026 ist WordPress 7.1.4 erschienen, ein reines Sicherheitsupdate. Es schließt 22 Sicherheitslücken. Die wichtigste: Während WordPress sich selbst aktualisiert, können Angreifer ohne Anmeldung Schadcode einschleusen und ausführen. Die Lücke ist mit CVSS 8.1 als hoch eingestuft. Kurz nach dem Update hat der Sicherheitsanbieter Wordfence erste Angriffsversuche beobachtet.
Für JTL-Händler wichtig: Der JTL-Shop und JTL-Wawi sind nicht betroffen. Betroffen ist jede WordPress-Seite, zum Beispiel ein Blog oder eine Firmenseite neben dem Shop oder ein WooCommerce-Shop mit JTL-Anbindung.
Unsere Lösung: Wir prüfen, ob Ihre WordPress-Seite auf dem aktuellen Stand ist, suchen nach Spuren eines Angriffs und sperren das Update-Verzeichnis passend für Ihren Server, ohne dass Updates oder der Shop danach hängen. Termin buchen
Auf einen Blick
| Punkt | Details |
|---|---|
| Lücke | CVE-2026-119977: Schadcode über das Update-Verzeichnis wp-content/upgrade, während ein Update läuft |
| Risiko | CVSS 8.1 (hoch), keine Anmeldung nötig |
| Betroffen | Alle Versionen vor 7.1.4 ohne passenden Backport. Laut Patchstack stammt der Fehler aus WordPress 2.8. |
| Sicher ab | 7.1.4 sowie Backports 7.0.8 · 6.9.11 · 6.8.12 · 6.7.11 · 6.6.11 · 6.5.14 … bis 4.7.39 |
| Kein Update | WordPress 4.6 und älter |
| Angriffe | Laut Wordfence Angriffsversuche kurz nach Erscheinen des Updates. Von erfolgreichen Angriffen berichten unsere Quellen bisher nicht. |
| Nicht betroffen | JTL-Shop, JTL-Wawi |
Was steckt hinter der Lücke?
Wenn WordPress sich mit dem vollständigen Paket aktualisiert, entpackt es dieses für einige Sekunden in den Ordner wp-content/upgrade. Dieser Ordner ist aus dem Internet erreichbar. Wer genau in diesem Moment die richtige Adresse aufruft, kann dort Schadcode zum Laufen bringen.
Das klingt nach Glücksspiel, denn das Zeitfenster ist kurz. Angreifer fragen solche Adressen aber automatisiert und über viele Stunden immer wieder ab. Laut heise hat Wordfence in den ersten 21 Stunden nach Einführung einer Schutzregel über 18.500 solcher Anfragen gezählt.
Neben dieser Lücke schließt 7.1.4 eine Reihe weiterer Fehler, vor allem eingeschleusten Code in Beiträgen und Blöcken (Fachbegriff: Stored XSS). Die meisten davon setzen ein Benutzerkonto ab der Rolle „Mitarbeiter“ voraus.
Wer muss was tun?
| Ihre WordPress-Seite … | Was zu tun ist |
|---|---|
| aktualisiert sich automatisch | Prüfen, ob 7.1.4 (oder der passende Backport) wirklich installiert ist, danach auf Spuren eines Angriffs schauen. |
| wird von Hand aktualisiert | Sofort unter Dashboard › Aktualisierungen auf 7.1.4 aktualisieren. |
| läuft mit WordPress 4.6 oder älter | Es gibt kein Update. Die Seite muss auf eine aktuelle Version gebracht oder abgeschaltet werden. |
| wird von einer Agentur betreut | Nachfragen, ob 7.1.4 eingespielt und die Seite auf Angriffsspuren geprüft wurde. |
Schritt für Schritt
- Version prüfen: Im WordPress-Backend unten rechts oder unter Dashboard › Aktualisierungen.
- Aktualisieren: Unter Dashboard › Aktualisierungen auf „Jetzt aktualisieren“ klicken. Vorher eine Sicherung anlegen, wie bei jedem Update.
- Spuren suchen: Der Ordner
wp-content/upgradesollte zwischen Updates leer sein oder nur eineindex.phpenthalten. Andere PHP-Dateien dort sind ein Alarmzeichen. - Benutzer prüfen: Unter Benutzer nach Administrator-Konten suchen, die Sie nicht kennen.
- Plugins prüfen: Gibt es Plugins, die niemand installiert hat?
- Rollen aufräumen: Wer braucht wirklich ein Konto ab „Mitarbeiter“? Nicht mehr benötigte Konten löschen.
Finden Sie verdächtige Dateien oder Konten, löschen Sie nicht einfach nur diese. Wer einmal Schadcode ausführen konnte, hat oft weitere Hintertüren hinterlassen. Dann gehört die Seite gründlich untersucht und Passwörter (WordPress, Datenbank, FTP) geändert.
Update-Verzeichnis sperren: nicht auf eigene Faust
Sicherheitsforscher empfehlen zusätzlich, den Ordner wp-content/upgrade für Aufrufe aus dem Internet zu sperren. Wie das geht, hängt vom Server ab (Apache, Nginx, LiteSpeed, CDN). Eine falsche Regel kann dazu führen, dass Updates nicht mehr durchlaufen oder Teile der Seite nicht mehr laden. Deshalb veröffentlichen wir hier bewusst keine Vorlage zum Kopieren. Wir richten die Sperre passend für Ihren Server ein und testen danach Updates und Shop.
So unterstützen wir Sie
Wir prüfen Version und Update-Einstellungen Ihrer WordPress-Seite, spielen 7.1.4 ein, suchen nach Spuren eines Angriffs und sperren das Update-Verzeichnis passend für Ihren Server. Bei WooCommerce-Shops mit JTL-Anbindung testen wir danach auch den Abgleich mit der Wawi.
Häufige Fragen
Ist mein JTL-Shop betroffen?
Nein. Die Lücke steckt in WordPress, nicht im JTL-Shop. Betroffen sind WordPress-Seiten, also zum Beispiel ein Blog, eine Firmenseite oder ein WooCommerce-Shop, der mit JTL-Wawi verbunden ist.
Welche Versionen sind sicher?
WordPress 7.1.4 und für ältere Zweige die Backports, zum Beispiel 7.0.8, 6.9.11, 6.8.12, 6.7.11 und so weiter bis 4.7.39. Für WordPress 4.6 und älter gibt es keinen Fix.
WordPress aktualisiert sich doch automatisch. Muss ich etwas tun?
Prüfen Sie, ob das Update wirklich angekommen ist. Bei vielen Seiten sind automatische Updates abgeschaltet oder scheitern unbemerkt. Ausgerechnet das Update selbst ist der Moment, in dem die Lücke greift. Deshalb lohnt sich danach ein Blick auf Spuren eines Angriffs.
Hilft ein Sicherheits-Plugin wie Wordfence?
Nur teilweise. Wordfence hat eine Firewall-Regel ausgeliefert. Laut Patchstack werden die beim Update entpackten Dateien aber außerhalb der normalen Plugin-Umgebung aufgerufen, sodass Firewalls auf PHP-Ebene den Angriff nicht zuverlässig stoppen. Das Update auf 7.1.4 ist der eigentliche Schutz.
Woran erkenne ich, ob meine Seite angegriffen wurde?
Verdächtig sind unerwartete PHP-Dateien im Ordner wp-content/upgrade, unbekannte Administrator-Konten, Plugins, die niemand installiert hat, und PHP-Dateien, die Sie nicht selbst abgelegt haben. Zwischen zwei Updates ist wp-content/upgrade leer oder enthält nur eine index.php.
Quellen
- WordPress.org: WordPress 7.1.4 Security Release (28.10.2026, Liste der behobenen Lücken)
- heise online: WordPress: Exploit-Versuche beobachtet, Update stopft Schadcode-Lücke (30.10.2026, ergänzt 04.11.2026; CVE und Zahlen von Wordfence)
- Patchstack: WordPress 7.1.4 Security Release (Analyse, betroffene Versionen, Abhilfen)