Das Kernteam von WordPress hat am Mittwochabend die Version 7.1.4 veröffentlicht und damit 22 Sicherheitslücken geschlossen. Eine davon steckte im Update-Vorgang selbst und konnte zur Ausführung fremden Codes führen. Rückportierungen für die Zweige 7.0 bis 6.6 sind bereits erschienen.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenUm 18:13 Uhr deutscher Zeit stellte WordPress.org die Version 7.1.4 online und riet, alle Websites sofort zu aktualisieren. Seiten mit automatischen Hintergrund-Updates spielen die neue Version selbst ein.[1] Für den Zweig 7.1 ist 7.1.4 das vierte Sicherheitsupdate seit dem 17. September, nach 7.1.1, dem Notfall-Patch 7.1.2 und Version 7.1.3.
Das Wichtigste in Kürze
- WordPress 7.1.4 schließt 22 Sicherheitslücken, die meisten davon Cross-Site-Scripting.
- Ein Zeitfenster während des Updates konnte zur Ausführung fremden Codes führen.
- Acht Einträge im Sicherheitshinweis setzen nur ein Konto mit der Rolle Mitarbeiter voraus.
- Die Versionen 7.0.8, 6.9.11, 6.8.12, 6.7.11 und 6.6.11 sind erschienen, ältere Zweige bis 4.7 folgen.
Wie wird ausgerechnet das Update zum Einfallstor?
Den schwersten Fund meldete der Sicherheitsforscher Umut Bayram: eine Race Condition beim Update des WordPress-Kerns, also ein Zeitfenster, in dem fremder Code zur Ausführung kommen konnte.[2] WordPress.org nennt keine Details, der Vergleich der Quelltexte von 7.1.3 und 7.1.4 zeigt aber die Stelle.[3]
WordPress entpackt jedes Update in einen Arbeitsordner unter wp-content/upgrade, der über das Web erreichbar ist. Bisher ergab sich der Name des Ordners aus dem Paketnamen und war damit vorhersagbar; eine index.php gegen das Auflisten des Verzeichnisses fehlte. Version 7.1.4 hängt 16 zufällige Zeichen an den Namen und legt die index.php selbst an. Außerdem kopiert das Update keine wp-config.php mehr aus dem Arbeitsordner ins Hauptverzeichnis. Laut Kommentar im Code könnte dort eine fremde Datei liegen. Als wp-config.php liefe die Datei bei jedem Seitenaufruf mit.
Ohne jede Anmeldung ließen sich zudem unveröffentlichte Änderungen im Customizer, dem Werkzeug zur Design-Anpassung, abrufen, gemeldet von Antonio Lorensius Silaban.[2] Vorbereitete Relaunches konnten so vorab nach außen dringen.
Welche Lücken setzen ein Konto voraus?
Sechs Einträge im Sicherheitshinweis betreffen die Interactivity API, die Schnittstelle für interaktive Blöcke. Über präparierte Direktiven ließen sich Skripte einschleusen, etwa per javascript:-Link.[2] Acht der 17 Einträge setzen nur ein Konto mit der Rolle Mitarbeiter voraus, der niedrigsten Rolle mit Schreibrecht. Ein Mitarbeiter-Konto genügte zuletzt auch bei der Sicherheitslücke in Rank Math.
Zwei Meldungen stammen von Anthropic. Eine davon betrifft ausgerechnet die Löschanfragen, über die Betreiber das Recht auf Löschung nach Art. 17 DSGVO abwickeln: In präparierten Anfragen ließ sich dort Schadcode verstecken, nötig war ein Konto ab der Rolle Redakteur.[2] Zusammen mit drei Funden in 7.1.3 und zwei in Version 7.1.1 hat das KI-Unternehmen seit September sieben Lücken im WordPress-Kern gemeldet.
Fast jeder zweite Eintrag im Sicherheitshinweis braucht nur ein Mitarbeiter-Konto, die Benutzerliste gehört deshalb zur Update-Routine.
Michael Dobler, Herausgeber Dr. Web
Welcher Zweig welches Update bekommt
Was sollten Betreiber jetzt tun?
Prüfen Sie im Dashboard unter „Aktualisierungen“, ob 7.1.4 läuft. Für ältere Zweige liegen Rückportierungen bis 6.6.11 bereit, die Versionen für 6.5 bis 4.7 folgen nach und nach.[1] Ein frisches Backup vor dem Update spart im Ernstfall Stunden; passende Werkzeuge zeigt der Vergleich der Backup-Plugins für WordPress.
Danach lohnt der Blick in die Benutzerliste. Verwaiste Zugänge mit den Rollen Mitarbeiter und Autor gehören gelöscht, Gastautoren erhalten ihr Konto nur für die Dauer des Auftrags.
Das Update tauscht außerdem die mitgelieferte Liste der Wurzelzertifikate, mit der WordPress ausgehende HTTPS-Verbindungen prüft, etwa zu den Update-Servern. Nach dem Widerruf der eMudhra-Zertifikate fehlen darin drei emSign-Wurzelzertifikate, darunter emSign ECC Root CA G3.[3] WordPress 7.1.3 vertraute diesem Wurzelzertifikat noch und damit auch Zertifikaten, die mit dem geknackten eMudhra-Schlüssel signiert sind. Wie zuverlässig Hoster solche Updates einspielen, zeigt der WordPress-Hosting-Vergleich.
Quellen
3 Quellen anzeigenQuellen ausblenden
- WordPress.orgWordPress 7.1.4
- WordPress.org DocumentationVersion 7.1.4
- WordPress.orgQuelltext von WordPress 7.1.4 im Subversion-Archiv, verglichen mit Version 7.1.3 (class-wp-upgrader.php, update-core.php, ca-bundle.crt)
Mehr Newshunger?
- Prime Slider mit über 100.000 Installationen: Schwere Sicherheitslücke öffnet die Kommentarspalte für Schadcode
- Royal Addons for Elementor mit über 600.000 Installationen: Sicherheitslücke legt Formulareinsendungen offen
- Essential Addons for Elementor mit über 1 Million Installationen: Sicherheitslücke legt private Zusatzfelder offen
- Kirki mit über 500.000 Installationen: Schwere Sicherheitslücke macht Abonnenten zu Administratoren
- WordPress 7.2 Beta 1 ist da, die finale Version folgt am 8. Dezember
- WordPress-Kern: Neue Path-Traversal-Lücke führt unter Bedingungen zur Codeausführung
