Kaffee läuft. Wir auch. Noch bis 18:00 Uhr erreichbar.

WordPress-Lücke im Update: Jetzt 7.1.4 prüfen

·

Blogger Bernhard

Ausgerechnet das Update ist der heikle Moment: Bei WordPress 4.7 bis 7.1.3 kann die Lücke CVE-2026-119977 genau dann ausgenutzt werden, wenn eine Seite ein vollständiges Core-Update einspielt (S3). WordPress hat am 28. Oktober 2026 die Version 7.1.4 als Sicherheitsrelease veröffentlicht und empfiehlt, sofort zu aktualisieren (S1). Was ist belegt, wie ernst ist es, und was sollten Sie tun?

Was WordPress selbst schreibt

Das Release behebt mehrere Probleme. Eines davon ist eine Schwäche im Upgrade-Prozess, die während des Upgrade-Fensters zu Remote Code Execution führen kann (S1). Das Hilfeportal nennt es eine Race Condition bei Core-Updates (S2). Wer automatische Hintergrund-Updates aktiv hat, bekommt das Update von selbst (S1).

Die Korrekturen wurden auf alle Zweige zurückportiert, die Sicherheitsfixes erhalten, aktuell bis 4.7 (S1). Bei unserem Abruf am 2. November 2026 bot die Update-Schnittstelle von WordPress.org unter anderem 7.1.4, 7.0.8, 6.9.11 und 4.7.39 an (S6). Welche Version zu Ihrem Zweig gehört, sehen Sie also im Dashboard.

Was die Lücke bedeutet

Der NVD-Eintrag beschreibt vorhersehbare, per Web erreichbare Zwischenpfade bei vollständigen Core-Updates. Angreifer ohne Anmeldung können damit während des Upgrade-Fensters Code auf dem Server ausführen (S3). Dieses Fenster ist kurz: Im Labor existierte der Zwischenordner laut ThreatDefence nur wenige Sekunden (S5). Der Angriff braucht also Timing. Man kann sich das wie einen Einbrecher vorstellen, der vor dem Haus wartet, bis beim Umzug die Tür offen steht.

Die Bewertungen gehen auseinander. Der Eintrag nennt CVSS 8.1 (High) bei hoher Angriffskomplexität (S3). Laut Ostorlab und ThreatDefence stuft WordPress die Lücke selbst nur als „Low“ ein (S4, S5). Der Unterschied liegt laut ThreatDefence in der Angriffskomplexität, nicht in den Folgen (S5). Der NVD-Eintrag war beim Abruf noch nicht analysiert („Received“) und seine Werte stammen von Wordfence als Vergabestelle (S3). Eine unabhängige Zweitprüfung ist das nicht.

Angriffsversuche gibt es: ThreatDefence berichtet unter Berufung auf Wordfence mehr als 18.500 Anfragen nach dem Installer im Zwischenordner in den ersten 21 Stunden (S5). Das sind Versuche, keine bestätigten Übernahmen. Höhere Zahlen aus Pressemeldungen nennen wir nicht, weil sie laut ThreatDefence im Wordfence-Beitrag fehlen (S5). Den Wordfence-Beitrag selbst konnten wir nicht abrufen. Im CISA-Katalog bekannter ausgenutzter Schwachstellen (Version 2026.10.30) fanden wir die Nummer nicht (S7). Das ist eine Momentaufnahme und keine Entwarnung.

Was Sie jetzt tun sollten

  1. Version prüfen. Im Dashboard unter „Aktualisierungen“ oder per WP-CLI mit wp core version (S4).
  2. Aktualisieren. Auf 7.1.4 oder die Korrekturversion Ihres Zweigs (S1, S6). Ostorlab rät vorher zu einem Backup von Seite und Datenbank (S4).
  3. Prüfen, ob die Automatik gelaufen ist. Seiten mit abgeschalteten Auto-Updates, Composer-Verwaltung oder Distributionspaketen folgen laut ThreatDefence einem eigenen Zeitplan (S5).
  4. Wenn Sie nicht sofort updaten können: den Webzugriff auf /wp-content/upgrade/ sperren. Ostorlab nennt für Apache RedirectMatch 403 ^/wp-content/upgrade/ (S4). Das deckt nur diese eine Lücke ab (S4).
  5. Logs ansehen. Anfragen an PHP-Dateien unter wp-content/upgrade sind verdächtig. Ein einzelner Treffer ist ein Hinweis, kein Beweis (S4).

Dazu eine DGH-IT-Empfehlung, die nicht in den Quellen steht: Wenn Ihre Seite bei einem Hoster läuft, fragen Sie dort nach, ob das Update durch ist. Für Ihre eigene Version brauchen Sie das Dashboard, nicht die Auskunft des Anbieters.

Grenzen und offene Punkte

  • Stand dieses Beitrags: 2. November 2026. Die Lage kann sich ändern.
  • Die Angaben zum Angriffsablauf und zur Korrektur im Code stammen aus Sekundärquellen (S4, S5). Wir haben nichts nachgestellt und keine Seite selbst getestet.
  • Die Wirkung der Webserver-Sperre haben wir nicht selbst geprüft. Menüpunkte und Konfigurationswege hängen von Ihrem Hosting ab.
  • Das Release enthält weitere Korrekturen, zum Beispiel gegen Cross-Site-Scripting (S1). Sie sind hier nicht Thema.

Fazit: Das Update selbst ist der riskante Moment

Kein Grund zur Panik, aber einer, die Version nicht liegen zu lassen: auf 7.1.4 oder die Korrekturversion Ihres Zweigs bringen und nachsehen, ob es wirklich passiert ist.

Betreiben Sie eine WordPress-Seite und wissen nicht, welche Version läuft oder ob die Updates durchgehen? DGH-IT sieht sich das gern mit Ihnen an, ohne Verkaufsdruck.

Weiterführend: PHP-Lücke PHP2Shell: Was Website-Inhaber jetzt prüfen sollten.

Quellen & weiterführende Informationen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert