Am 28. Oktober ist WordPress 7.1.4 erschienen. Es schliesst über ein Dutzend Sicherheitslücken, darunter eine im Update-Vorgang selbst, über die sich fremder Code ausführen lässt. Dazu kommen zahlreiche Lücken, über die sich Schadcode in Beiträge, Blöcke oder Benutzernamen einschleusen lässt. Die WordPress-Entwickler empfehlen, sofort zu aktualisieren.
Für die meisten Websites erledigt sich das von selbst. WordPress spielt kleine Versionen wie diese automatisch ein. Wir wollten wissen, wie gut das funktioniert, und haben am Abend auf einem unserer Server nachgesehen.
Was wir gemessen haben
27 Websites liefen am Abend bereits auf 7.1.4. Sie hatten sich zwischen 18:28 und 20:04 Uhr selbst aktualisiert, ohne dass jemand etwas tun musste. So soll es sein.
Vier Websites liefen noch auf einer älteren Version. Bei allen vier ist das automatische Update eingeschaltet. Bei einer stand die nächste Prüfung schlicht noch aus, sie kommt mit Verspätung. Bei zwei anderen gibt WordPress selbst Auskunft, warum nichts passiert:
«Die automatische Aktualisierung ist seit 3 Monaten überfällig. Es gibt möglicherweise ein Problem mit WP-Cron.»
Und bei der zweiten: seit 1 Jahr überfällig. Der älteste liegengebliebene Auftrag dieser Website stammt vom November 2024. Sie läuft auf WordPress 6.8.1. Die Korrekturen, die seither für diesen Versionszweig erschienen sind, reichen bis 6.8.10. Keine davon ist angekommen.
Eingeschaltet heisst nicht, dass es läuft
WordPress hat keinen eigenen Taktgeber. Geplante Aufgaben wie die Suche nach Updates erledigt es nebenbei, wenn jemand die Website aufruft. Das System heisst WP-Cron. Bei einer Website mit regelmässigem Besuch fällt das nicht auf. Bleibt der Anstoss aus, etwa weil kaum jemand die Seite besucht oder weil ein Zwischenspeicher die Besucher bedient, ohne WordPress zu wecken, bleiben die Aufgaben liegen. Auch die Updates.
Die Einstellung zeigt dabei weiter «automatisch». Niemand bekommt eine Fehlermeldung. Das Problem ist dasselbe wie bei den Kernel-Updates, die eingespielt, aber nie in Betrieb waren: Was eingeschaltet ist, wird nicht mehr geprüft.
Und die Kopien daneben
Bei der Messung sind uns zwei weitere WordPress-Installationen aufgefallen, die niemand mehr betreut: ein Sicherungsordner mit WordPress 6.3.11 und eine alte Unterdomain mit 6.7.2. Beide waren in unserem Fall von aussen nicht erreichbar. Das war Glück, kein Plan. Eine alte Kopie, die über eine Adresse aufrufbar ist, bekommt kein Update, weil sich niemand für sie zuständig fühlt, und sie liegt neben der echten Website auf demselben Speicherplatz. Was wir über abgeschaltete, aber nicht entfernte Software geschrieben haben, gilt hier genauso.
Was jetzt zu tun ist
Die Version nachsehen. Im WordPress-Backend unter «Dashboard», «Aktualisierungen». Steht dort 7.1.4, ist alles in Ordnung. Ältere Versionszweige bekommen die Korrekturen ebenfalls, die Nachlieferung läuft noch.
Auf die Meldung achten. Auf derselben Seite zeigt WordPress den Satz «Die automatische Aktualisierung ist seit … überfällig», wenn WP-Cron nicht läuft. Wer ihn sieht, hat ein Problem, das nicht erst seit gestern besteht. Die saubere Lösung ist ein echter Zeitplan auf dem Server, der WP-Cron in festen Abständen anstösst, unabhängig vom Besuch.
Nach Kopien suchen. Ordner wie «alt», «backup» oder «test» im Webspace und Unterdomains wie old. oder dev. gehören gelöscht, wenn sie niemand mehr braucht. Eine Sicherung gehört in die Sicherung, nicht neben die Website.
Bei der Agentur nachfragen. Wer die Website betreuen lässt, kann eine einfache Frage stellen: Läuft bei uns 7.1.4? Eine gute Antwort kommt mit der Versionsnummer.