Kritische WordPress-Lücke: Reicht dein automatisches Update?

Wenn wir eine bestehende Website übernehmen, ist das fast immer die erste Überraschung: Niemand im Unternehmen kann sagen, welche WordPress-Version dort eigentlich arbeitet. Die Seite wurde vor drei Jahren gebaut, seitdem funktioniert sie, also schaut niemand mehr hin. Der Zugang liegt bei der Agentur von damals, das Passwort irgendwo in einer alten E-Mail.

Solange nichts passiert, ist das kein Drama. Bei dieser Meldung schon. Denn anders als bei den Plug-in-Lücken der letzten Wochen kannst du dich nicht damit herausreden, das betroffene Werkzeug gar nicht zu benutzen. Es gibt hier nichts zu prüfen außer einer einzigen Zahl: der Versionsnummer deiner Seite.

Der Fehler sitzt in dem Teil von WordPress, der entscheidet, welche Datei aus deinem Theme eine Seite darstellt. Dieser Teil prüft den übergebenen Namen zu nachlässig. Wer die Anfrage geschickt formuliert, bringt WordPress dazu, statt der gemeinten Theme-Datei eine ganz andere Datei vom Server zu laden – auch eine, die dort eigentlich nichts mit deiner Website zu tun hat.

Ob daraus fremder Code wird, der tatsächlich läuft, hängt davon ab, was auf dem Server deines Hosters sonst noch liegt und wie dein Theme gebaut ist. Das ist der einzige Grund, warum nicht jede Seite sofort übernommen wird. Als Beruhigung taugt es nicht: Welche Dateien auf einem Server herumliegen, finden automatisierte Scans schneller heraus, als die meisten Betreiber ihr Adminpasswort zurücksetzen können.

Ein Login braucht es dafür nicht, und es muss auch niemand auf etwas klicken. Eine einzelne Anfrage an deine öffentlich erreichbare Website genügt.

Beruhigend daran: Du musst keinen großen Versionssprung wagen. Für jeden gepflegten Zweig gibt es ein eigenes Update. Wer aus gutem Grund noch auf 6.8 steht – etwa wegen eines älteren Plug-ins –, bleibt dort und geht auf 6.8.10.

Sicherheitsupdates für den WordPress-Kern spielt WordPress normalerweise von selbst ein. Viele Seiten sind deshalb längst versorgt, ohne dass jemand etwas getan hätte. Nur: In der Praxis ist diese Automatik häufiger stillgelegt, als Betreiber ahnen – und sie meldet sich nicht, wenn sie es ist.

Die üblichen Verdächtigen aus unserer Arbeit: eine Zeile in der wp-config.php, die jemand vor Jahren gesetzt hat, um ein Update-Chaos zu stoppen. Ein Wartungs- oder Sicherheits-Plug-in, das Updates „kontrolliert“ ausrollen soll und sie faktisch blockiert. Fehlende Schreibrechte im Dateisystem nach einem Server-Umzug. Oder eine Installation, die über Git oder Composer verwaltet wird – dort sind automatische Updates bewusst abgeschaltet, weil sie den Bereitstellungsprozess durcheinanderbringen würden.

Deshalb reicht „läuft ja automatisch“ als Antwort nicht. Die Gegenprobe dauert zwei Minuten:

• ✓Im Adminbereich unter „Dashboard › Aktualisierungen“ nachsehen, welche Version dort steht.
• ✓Liegt sie unter 7.1.2 – beziehungsweise unter 6.8.10, 6.9.9 oder 7.0.6 im jeweiligen Zweig –, jetzt aktualisieren.
• ✓Wird seit Tagen eine neue Version angeboten, ohne dass etwas passiert, hängt die Automatik. Dann von Hand aktualisieren und anschließend klären, woran es lag – sonst verpasst du das nächste Update genauso.
• ✓Wenn du gar nicht in den Adminbereich kommst: Das ist das eigentliche Problem. Kläre zuerst, wer die Zugänge hat.

Zwischen Veröffentlichung des Updates und den ersten Angriffsversuchen lagen nur Stunden. Das ist inzwischen der Normalfall: Sobald ein Sicherheitsupdate erscheint, lässt sich daraus ablesen, was es repariert – und damit, wie der Angriff funktioniert. Wer erst eine Woche später aktualisiert, hat eine Woche lang eine offene Tür gehabt, an der nachweislich gerüttelt wurde.

Das Update schließt die Tür, räumt aber nicht auf, falls schon jemand drin war. Sinnvoll ist deshalb ein Blick auf: neue Benutzerkonten mit Administratorrechten, PHP-Dateien im Uploads-Ordner oder in temporären Verzeichnissen, veränderte Startdateien deines Themes und geplante Aufgaben, die du nicht selbst angelegt hast. In den Server-Logs fallen Anfragen auf, die auffällig viele „../“ im Pfad enthalten.

Und der Punkt, den bei Sicherheitsvorfällen fast alle zu spät bedenken: Ein Backup rettet dich nur, wenn es älter ist als der Einbruch. Sicherst du erst nach dem Vorfall, sicherst du die Hintertür gleich mit.

Du weißt nicht, welche Version deine Seite fährt, oder kommst gar nicht erst in den Adminbereich? Wir schauen nach: Wir kontrollieren, ob dein WordPress in einem angreifbaren Stand steckt, und spielen bei Bedarf das schließende Update ein. Du erhältst eine klare Rückmeldung, ob Handlungsbedarf besteht. Eine forensische Suche nach bereits erfolgten Angriffen ist bewusst nicht Teil dieser Prüfung.