Am 28. Oktober hat WordPress die Version 7.1.4 rausgebracht, mit einem Fix für eine Lücke, die ich so auch noch nicht hatte. Die steckt nämlich im Update selbst. Während WordPress sich aktualisiert, entpackt es die neuen Dateien in einen Ordner, dessen Name vorhersehbar ist und der auf vielen Servern von außen erreichbar ist. Wer in den paar Sekunden die richtige Datei aufruft, kann laut Wordfence ohne Anmeldung eigenen Code auf dem Server ausführen (The Hacker News). Betroffen sind alle Versionen von 4.7 bis 7.1.3, die offizielle Ankündigung rät, sofort zu aktualisieren (WordPress.org).

Und es wird schon fleißig probiert. Wordfence hat nach eigener Aussage neun Minuten, nachdem die eigene Schutzregel live war, die erste passende Anfrage gesehen und in den ersten 21 Stunden mehr als 18.500 Anfragen auf genau diese Pfade gezählt (Rescana). Die US-Behörde CISA hat die Lücke am 3. November in ihre Liste der aktiv ausgenutzten Schwachstellen aufgenommen (The Hacker News). Fairerweise muss man dazusagen, dass bisher keine bestätigte Übernahme einer Seite gemeldet ist, es sind Versuche.

Warum diese WordPress-Sicherheitslücke so unangenehm ist

Bei den meisten Lücken ist die Antwort ja einfach. Update machen und gut. Hier ist ausgerechnet das Update der Moment, in dem die Tür kurz offen steht. Und WordPress aktualisiert sich bei Wartungs- und Sicherheitsversionen standardmäßig von selbst, das steht so auch in der offiziellen Doku (WordPress Developer). Das ist grundsätzlich auch gut so. Aber es heißt halt auch, dass das Update irgendwann läuft, wenn keiner hinguckt, und die Angreifer haben laut Wordfence einzelne Seiten über Stunden immer wieder abgefragt, bis sie das Fenster treffen.

Was mich an der Sache ehrlich gesagt am meisten irritiert, ist die Einstufung. WordPress selbst bewertet die Lücke in der eigenen Sicherheitsmeldung als niedrig (GitHub), Wordfence gibt ihr 8,1 von 10. Kann man beides irgendwie nachvollziehen. Das Zeitfenster ist kurz, und der Angriff ist nicht ganz einfach. Nur steht sie jetzt halt trotzdem auf der Liste der ausgenutzten Lücken. Wer sich bei Updates nach der Einstufung richtet, hätte hier wahrscheinlich gewartet.

Noch ein Punkt, den ich wichtig finde. Ein Sicherheitsplugin hilft hier nur bedingt. Laut Wordfence geht die Anfrage direkt an eine Datei im Update-Ordner, ohne dass WordPress überhaupt geladen wird (Rescana). Ein Plugin, das in WordPress läuft, kriegt davon also im Zweifel gar nichts mit. Doof, aber ist so. Die eigene Firewall-Regel von Wordfence greift für die kostenlose Version laut Rescana erst ab dem 27. November.

Was wir bei WordPress gelernt haben

Wir bauen gerade selbst WordPress-Plugins, eins liegt inzwischen im offiziellen Verzeichnis. Getestet wird das bei uns in einer eigenen Umgebung mit echtem WordPress, die wir jedes Mal frisch hochziehen. Und dabei fällt halt auf, wie viel bei so einer Seite im Hintergrund passiert, was keiner sieht. Updates laufen, Ordner entstehen und verschwinden wieder. Ob der Server so einen Ordner nach außen zeigt, liegt dabei gar nicht an WordPress. Das ist eine Einstellung beim Hoster.

Unsere eigene Seite lief früher übrigens auch mal auf WordPress. Und ich glaube, bei den meisten ist das so, die Seite läuft, und wo welche Einstellung sitzt, weiß keiner so genau. Ist auch völlig okay, solange klar ist, wer es weiß.

So prüft ihr eure WordPress-Seite

1. Version nachsehen. Im Admin-Bereich unter Dashboard, Aktualisierungen, da steht die installierte Version. 7.1.4 hat den Fix, für ältere Reihen gibt es eigene Versionen, zum Beispiel 7.0.8, 6.9.11 oder 6.8.12 (GitHub). Alles von 4.6 abwärts bekommt keinen Fix mehr.
2. Auf derselben Seite schauen, ob automatische Updates für Sicherheitsversionen an sind. Manche Agenturen schalten die ab, damit nichts unkontrolliert passiert. Kann man so machen. Dann muss aber jemand die Updates zeitnah von Hand einspielen, und da würde ich mal nachfragen, wer das eigentlich ist.
3. Beim Hoster oder der Agentur schriftlich fragen, ob der Ordner wp-content/upgrade von außen gesperrt ist. Wichtig ist, dass die Sperre in der Serverkonfiguration steht und nicht als Datei in dem Ordner selbst, weil ältere Versionen den Ordner vor jedem Update leeren und die Regel dann mit weg wäre (Rescana).
4. Unter Benutzer nachsehen, ob es Administratoren gibt, die ihr nicht kennt. Und unter Plugins, ob da etwas liegt, das keiner installiert hat. Fällt etwas auf, erst mal Hoster oder Agentur Bescheid geben. Selbst rumlöschen macht es meistens schlimmer.
5. Den Hoster bitten, in die Zugriffsprotokolle zu gucken, ob um die Zeit der letzten Updates Aufrufe auf Dateien in wp-content/upgrade kamen. Das ist der Hinweis, den Wordfence als Spur nennt.
6. Alle anderen WordPress-Seiten mitdenken. Die zweite Domain, die alte Kampagnenseite, die Testseite der Agentur. Bei denen hat oft keiner mehr die Updates im Blick.

Plugins und Themes übrigens nicht vergessen. Die automatischen Updates im Kern von WordPress kümmern sich standardmäßig nur um WordPress selbst, Plugins muss man dafür extra freischalten.

Updates sind ein Ablauf

Was ich aus der Geschichte mitnehme, ist eigentlich ganz einfach. „Läuft automatisch“ ist keine Zuständigkeit. Irgendwer muss wissen, ob es gelaufen ist, und irgendwer muss wissen, was der Server nach außen zeigt. Bei vielen kleinen Firmen sind das drei verschiedene Leute. Die Agentur, der Hoster und der, der die Rechnung bezahlt. Und so richtig hat keiner das Ganze im Blick. Wisst ihr, wer bei euch gerade nachgeguckt hat, ob 7.1.4 drauf ist?

Wer so einen Ablauf bei sich mal sortiert anschauen will, kann das mit dem Prozess-Check machen.