Eine neue Woche, neue Meldungen über Sicherheitslücken rund um WordPress. Elementor, TranslatePress, andere Plugins, wichtige Sicherheitsupdates. Wer nur die Überschriften liest, kann schnell zu einem einfachen Schluss kommen: Meine Güte, WordPress muss ja eine Katastrophe sein, wenn dort ständig etwas gepatcht werden muss.

Nur ist das genau der falsche Schluss.

Software muss gewartet werden. Jede. WordPress ist da keine Ausnahme. Es ist lediglich ein System, bei dem der Website-Betreiber besonders deutlich sieht, dass diese Wartung stattfindet. Ein Update erscheint, WordPress zeigt es im Dashboard an, und in vielen ganz normalen Fällen besteht der ganze Vorgang aus einem Backup, einem Klick auf “Aktualisieren” und einer kurzen Kontrolle, ob die Website danach korrekt funktioniert.

WebsiteGarage / Leistungen

Entdecke unsere Leistungen.

Der Wechsel von WordPress zu einem anderen CMS, Framework oder einer komplett individuell entwickelten Anwendung lässt diese Pflicht nicht auf magische Weise verschwinden.

Das ist ein bisschen so, als würde man sagen: Nur weil ein Motor einen Ölwechsel braucht, kaufen wir einfach ein anderes Auto oder einen anderen Motor, und dort muss das Öl dann nicht mehr gewechselt werden. Doch, muss es. Vielleicht gibt es nur keine Warnleuchte mehr, die daran erinnert, dass es Zeit ist.

TranslatePress: eine gefährliche Lücke, aber schauen wir uns die ganze Geschichte an

Am 25. August veröffentlichte Wordfence Details zu einer kritischen Sicherheitslücke in TranslatePress, einem beliebten Plugin für mehrsprachige Websites. Unter bestimmten Bedingungen konnte ein nicht angemeldeter Angreifer einen Link erhalten, mit dem sich das Administratorpasswort zurücksetzen und anschließend das Konto übernehmen ließ.

Klingt schlecht, weil es schlecht war.

Interessanter ist jedoch die Chronologie. Der Forscher meldete das Problem am 11. August. Wordfence bestätigte es und leitete es am 12. August an den Hersteller weiter. Einen Tag später veröffentlichte der Hersteller die korrigierte Version 3.3.2. Die öffentliche Beschreibung der Schwachstelle erschien erst am 25. August, als der Fix bereits verfügbar war.

Und damit endet die Geschichte nicht. Das offizielle WordPress-Repository zeigt aktuell TranslatePress 3.3.4. Diese Version behebt eine weitere Schwachstelle, durch die unter bestimmten Bedingungen schädlicher Code in eine Website eingeschleust werden konnte. Das Plugin hat mehr als 400.000 aktive Installationen, also nicht gerade wenige.

Sollte ein Website-Betreiber jetzt CVE-Kennungen studieren, PHP-Code analysieren und sich mit den technischen Details des Angriffs beschäftigen?

Nein.

Wenn du TranslatePress verwendest, prüfe die verfügbaren Updates und installiere die aktuellste Version. Wenn sich jemand anderes um deine Website kümmert, vergewissere dich, dass das Update durchgeführt wurde.

Das ist alles.

Außerdem gab es in WordPress selbst in dieser Woche keine neue Sicherheitskatastrophe. Die offizielle Release-Liste zeigt WordPress 7.1 vom 19. August. Das letzte als Security Release gekennzeichnete Update, WordPress 7.0.4, stammt vom 12. August. WordPress selbst wies Nutzer dabei an, im Dashboard den Bereich Updates zu öffnen und auf Update Now zu klicken.

Es lohnt sich also, zwischen “WordPress hat schon wieder eine Sicherheitslücke” und “in einer von Tausenden Erweiterungen für WordPress wurde eine Sicherheitslücke gefunden” zu unterscheiden. Das ist nicht dasselbe.

Dann werfen wir WordPress eben raus. Sind die Updates jetzt weg?

Nein.

Am 25. August veröffentlichte OpenSSL neue Versionen mehrerer unterstützter Zweige zusammen mit einem Security Advisory. OpenSSL gehört zu den grundlegenden Bausteinen der Internet-Infrastruktur und ist unter anderem für kryptografische Operationen zuständig. Es ist kein WordPress-Plugin und hat nichts damit zu tun, welches CMS du auswählst.

Am selben Tag veröffentlichte Debian ein eigenes Sicherheitsupdate für das OpenSSL-Paket und empfahl Nutzern die Aktualisierung. In derselben Woche erschienen bei Debian außerdem Sicherheitsupdates unter anderem für den Linux-Kernel und weitere Systemkomponenten.

Am 27. August veröffentlichte PHP die Versionen 8.5.10 und 8.4.25. Bei 8.5.10 handelte es sich um ein Bugfix-Release, und das PHP-Team empfahl Nutzern des 8.5-Zweigs die Aktualisierung.

Und damit sind wir beim Kern der Sache.

Du kannst eine Website ohne WordPress bauen. Du kannst eine eigene Anwendung, ein modernes Framework, einen Static-Site-Generator, ein Headless CMS oder etwas völlig anderes verwenden. Du hast trotzdem ein Betriebssystem, einen Server, Bibliotheken, eine Runtime, Pakete und Abhängigkeiten. Auch sie erhalten Updates, Fehlerbehebungen und Sicherheitspatches.

Der Unterschied ist, dass der Website-Betreiber das normalerweise nicht sieht.

Im WordPress-Dashboard gibt es dann keinen roten Kreis mit der Zahl 6.

Jemand muss wissen, dass ein Patch erschienen ist. Jemand muss prüfen, ob er das Projekt betrifft. Jemand muss ihn einspielen. Manchmal muss vorher die Kompatibilität anderer Komponenten geprüft werden. Danach muss die Anwendung getestet und die Änderung in die Produktion gebracht werden.

Wenn niemand das macht, wird die Anwendung dadurch nicht stabil und sicher.

Sie wird einfach nicht gewartet.

Cloudflare hat gerade gezeigt, wie “wir machen es anders” in der Praxis aussieht

Das beste Beispiel dieser Woche lieferte zufällig Cloudflare.

Am 24. August beschrieb das Unternehmen die Migration seines Blogs zu EmDash, einem CMS auf Basis von Astro und Cloudflare-Infrastruktur. Die eigentliche Migration fand bereits am 12. August statt, doch erst jetzt veröffentlichte Cloudflare eine ausführliche Beschreibung des gesamten Prozesses.

Und das ist eine sehr interessante Lektüre für alle, die glauben, dass der Abschied von einem ausgereiften CMS das Leben automatisch einfacher macht.

Während der Tests fand Cloudflare unter anderem Probleme mit der Lokalisierung von Inhalten, SEO, Content Security Policy und dem Redaktionsbereich. Das größte übersehene Problem betraf geplante Veröffentlichungen. Sie funktionierten schlicht nicht, bis das Problem in EmDash 0.19.0 behoben wurde.

Dann stellte sich die Frage, ob die neue Plattform dem Traffic standhalten würde. Cloudflare erstellte eigene Testszenarien, darunter einen plötzlichen Anstieg auf 7.000 Anfragen pro Sekunde.

Und als das System produktionsbereit war, hieß es nicht einfach “deployen und schauen, was passiert”. Es wurde ein Mechanismus gebaut, mit dem Traffic zwischen der alten und der neuen Version verteilt und bei Serverfehlern zur alten Plattform zurückgeschaltet werden konnte. Am Starttag gingen zunächst 1 Prozent des Traffics auf die neue Version, dann 5 Prozent, 15 Prozent und erst nach weiteren Kontrollen 100 Prozent.

Das Ergebnis ist sehr gut. Der neue Blog ist schnell, die Plattform gibt Cloudflare mehr Kontrolle und passt zu den Anforderungen des Unternehmens.

Aber genau darum geht es.

Das ist keine Geschichte nach dem Motto “WordPress ist einfach, also ist Custom schlecht”. Eine individuelle Lösung kann hervorragend sein. EmDash kann ebenfalls hervorragend sein.

Die Geschichte lautet vielmehr: Jede Lösung muss gewartet, getestet und weiterentwickelt werden.

Cloudflare kann sich ein solches Modell leisten, weil das Unternehmen die Leute, die Infrastruktur und das Know-how dafür hat.

Eine durchschnittliche Bäckerei oder Kanzlei, ein Hotel oder ein Onlineshop braucht kein Team, das ein System für die schrittweise Umleitung des Traffics zwischen zwei Versionen der Website baut. Diese Unternehmen brauchen eine funktionierende Website.

Und plötzlich sieht dieser langweilige Button “Aktualisieren” ziemlich attraktiv aus.

Auch bei KI geht es zunehmend um Einstellungen statt um eine magische robots.txt

Im Wochenradar lohnt sich auch ein Blick auf eine Cloudflare-Meldung vom 21. August. Bot Preference Sync wurde damals für die darauffolgende Woche als Funktion für alle Tarife angekündigt.

Cloudflare teilt den Traffic von KI-Bots in drei Anwendungsarten ein: Search, Agent und Training. Website-Betreiber können damit unterschiedliche Entscheidungen für Bots treffen, die helfen, Inhalte auffindbar zu machen, für Agenten, die Aufgaben ausführen, und für Crawler, die Daten zum Training von Modellen sammeln.

Bot Preference Sync soll diese Einstellungen mit robots.txt synchronisieren, sodass die in robots.txt veröffentlichten Vorgaben zu den Regeln passen, die Cloudflare tatsächlich durchsetzt. Die Funktion wurde für alle Tarife von Free bis Enterprise angekündigt.

Das ist vor allem deshalb eine wichtige Veränderung, weil die pauschale Antwort “KI-Bot? Alle blockieren” langsam ausgedient hat.

Cloudflare selbst nennt zwei gegensätzliche Beispiele. Ein Onlineshop kann wollen, dass seine Produkte auch für KI-Systeme gut sichtbar sind. Ein Publisher, der mit Seitenaufrufen Geld verdient, kann in der Suche sichtbar bleiben wollen, aber nicht damit einverstanden sein, dass seine Artikel zum Training von Modellen verwendet werden.

Es gibt also nicht die eine richtige Konfiguration für jedes Unternehmen. Zuerst muss klar sein, was wir von der Präsenz unserer Website in der KI-Welt erwarten. Erst danach sollten die Bots entsprechend konfiguriert werden.

Auch beim Login sind Passwörter zunehmend nicht mehr die einzige Option

Am 25. August veröffentlichte das W3C Web Authentication Level 3 als offizielle Recommendation. WebAuthn ist der Standard hinter modernen Anmeldemethoden mit kryptografischen Schlüsseln, darunter Passkeys.

Für den Betreiber einer gewöhnlichen Website bedeutet das heute Morgen keine konkrete Aktion. Es ist aber ein weiteres Signal dafür, dass Anmeldemethoden, bei denen nicht die gesamte Sicherheit an einem Passwort hängt, zu einem normalen Bestandteil des modernen Webs werden.

Wenn eine Website Kundenkonten, ein umfangreiches Dashboard oder besonders wertvolle Administratorkonten hat, lohnt es sich bei der nächsten Modernisierung des Login-Systems, nicht nur nach starken Passwörtern und 2FA zu fragen, sondern auch nach Unterstützung für Passkeys.

Was davon betrifft dich am meisten?

Wenn du WordPress nutzt, brauchst du keinen Doktortitel in IT-Sicherheit. Du brauchst eine aktuelle Website, funktionierende Backups und jemanden, der reagiert, wenn ein Update nicht nur ein einfacher Klick auf einen Button ist. Öffne den Bereich Updates oder frag die Person, die deine Website betreut, ob alles aktuell ist. Wenn du TranslatePress verwendest, prüfe besonders, ob die neueste Version installiert ist.

Wenn du eine individuelle Website hast, stelle genau dieselbe Frage, nur etwas breiter: Wer aktualisiert ihre Abhängigkeiten, PHP oder eine andere Runtime, den Server und das Betriebssystem? Wer erhält Informationen über Sicherheitslücken? Wie sieht der Prozess aus, um einen Patch einzuspielen?

Und wenn die Antwort lautet “keine Ahnung, aber die Website läuft”, dann haben wir das Problem gerade gefunden.

Kommentar von WebsiteGarage

Bei WordPress sind Meldungen über Sicherheitslücken sehr sichtbar. Das ist eine Folge davon, dass es ein riesiges Ökosystem ist, intensiv untersucht wird und es einen ganzen Markt aus Menschen, Unternehmen und Tools gibt, die dort nach Problemen suchen.

Und das ist gut so.

Eine gefundene, dem Hersteller gemeldete und gepatchte Sicherheitslücke ist deutlich weniger interessant als eine Sicherheitslücke, von der niemand weiß.

Die denkbar schlechteste Interpretation solcher Meldungen lautet also: “WordPress hat ständig Updates, deshalb lasse ich etwas Eigenes bauen und habe danach meine Ruhe.”

Wirst du nicht.

Wenn du in ein Auto einen anderen Motor einbaust, muss das Öl trotzdem gewechselt werden. Er muss weiterhin gewartet werden. Irgendetwas wird irgendwann verschleißen oder kaputtgehen.

Der Unterschied ist, dass WordPress sehr oft selbst die Warnleuchte einschaltet und dir den Button “Aktualisieren” zeigt.

Bei einer individuellen Lösung muss diese Warnleuchte erst jemand entwerfen, der daran gedacht hat, dass man sie brauchen wird.

Das eigentliche Problem ist weder WordPress noch eine individuelle Lösung, weder PHP noch irgendein anderer Technologie-Stack.

Das Problem ist Software, um die sich nach dem Start niemand mehr kümmert.

Quellen