Am 17. September ist WordPress 7.1.1 erschienen. Siebzehn Fehlerkorrekturen im Kern, neunzehn im Block-Editor und elf Sicherheitskorrekturen. Die Korrekturen wurden auf alle noch belieferten Zweige zurückportiert, derzeit hinunter bis 4.7.
Einer der elf Einträge hat es in die Fachmeldungen geschafft. Patchstack hat ihn Click2Shell getauft, und in mehreren deutschsprachigen Berichten steht dazu, die Lücke erlaube Codeausführung ohne Anmeldung.
Das stimmt so nicht. Und weil die Frage, wer einen Angriff auslöst, darüber entscheidet, was man dagegen tut, lohnt sich der Blick in die Originalanalyse.
Was die Analyse tatsächlich sagt
Patchstack schreibt ausdrücklich, der Angriff verlange, dass ein Administrator der Seite die präparierte Adresse selbst öffnet. Ein gewöhnlicher Besucher kann ihn nicht auslösen — und, das ist der bemerkenswerte Teil, auch ein Konto mit Autoren- oder Redakteursrechten nicht.
Es braucht also keine Schwäche im Anmeldeverfahren, sondern einen Klick. Einen Klick der einen Person, die alles darf.
Das macht die Sache nicht harmlos. Es verschiebt nur, wo man ansetzt.
Die Kette, Schritt für Schritt
Der Ablauf ist es wert, ihn ganz zu lesen, weil an drei Stellen etwas passiert, das man nicht erwartet.
Erstens. Die Theme-Verwaltung im Backend gibt den Kurznamen eines Themes über die Adresszeile weiter. Der Kurzname landet ungeprüft in einer Anweisung, mit der die Oberfläche Elemente auf der Seite auswählt. Wer den Kurznamen geschickt baut, bringt die Seite dazu, auf eine Schaltfläche zu drücken, die der Betrachter nie gesehen hat.
Zweitens. Dadurch wird ein Theme installiert. Nicht irgendeines von einer dubiosen Adresse — eines aus dem offiziellen Verzeichnis von WordPress.org. Es wird nicht aktiviert. Es liegt einfach da.
Drittens. Ein zweiter Link öffnet die Vorschau dieses Themes im Customizer. Und hier passiert das, was den ganzen Angriff trägt.
Der Satz, auf den es ankommt
Ein inaktives Theme gilt als ungefährlich. Es tut ja nichts.
Patchstack formuliert es so: Es gebe genau einen Moment, in dem ein «inaktives» Theme eingeschaltet werde — die Vorschau im Customizer. In dieser Vorschau wird die Datei ausgeführt, in der ein Theme seine eigene Programmlogik ablegt.
Das Beispiel-Theme brachte darin eine Funktion mit, die Anfragen von aussen entgegennimmt — ohne Prüfung, ob der Anfragende dazu berechtigt ist, und ohne den üblichen Einmal-Schlüssel gegen untergeschobene Anfragen. Dieser Funktion lässt sich die Adresse einer Plugin-Datei übergeben. WordPress lädt sie herunter und führt sie aus.
Damit steht fremder Code auf dem Server.
«Nicht aktiv» ist also keine Sicherheitsstufe. Es ist ein Zustand, aus dem ein Theme durch eine Vorschau herausgeholt werden kann.
Warum der übliche Rat hier nicht greift
Bei Themes und Plugins lautet die Standardempfehlung seit Jahren: nur aus vertrauenswürdigen Quellen installieren, keine Fundstücke aus Foren, keine «nulled» Versionen aus zweifelhaften Sammlungen.
Dieser Rat ist richtig, und er hilft hier nicht. Das Theme kam aus dem offiziellen Verzeichnis. Es ist dort weder versteckt noch als schädlich markiert — es ist schlicht ein Theme mit einer schlecht abgesicherten Funktion, wie es Tausende gibt.
Wir haben im August über eine WordPress-Lücke geschrieben, die zwei Bedingungen gleichzeitig braucht. Hier sind es drei, und jede einzelne davon wirkt für sich unauffällig. Genau das ist das Muster, das solche Ketten so schwer zu bemerken macht: Keiner der Beteiligten hat etwas offensichtlich falsch gemacht.
Was zu tun ist
Prüfen Sie die Version. Im Backend unter «Dashboard, Aktualisierungen» muss 7.1.1 stehen. Bei den meisten Installationen ist sie längst da: WordPress verteilt solche Korrekturen als Hintergrundaktualisierung, und wir haben im August beschrieben, warum dieser Mechanismus greift. Verlassen Sie sich trotzdem nicht darauf, sondern sehen Sie nach — Hintergrundaktualisierungen lassen sich abschalten, und gelegentlich ist genau das passiert.
Löschen Sie Themes, die Sie nicht benutzen. Nicht deaktivieren — löschen. Auf einer gewachsenen Installation liegen oft drei, vier Themes aus früheren Versuchen herum. Sie gelten als harmlos, weil sie nicht aktiv sind. Nach dem heutigen Stand sind sie es nicht. Ein einziges Standard-Theme als Rückfallebene genügt.
Und der Punkt, der über diese eine Lücke hinausgeht: Der Angriff braucht einen angemeldeten Administrator, der einem Link folgt. Wer mit dem Administratorkonto dauerhaft angemeldet bleibt und nebenher Mails und Suchergebnisse anklickt, macht sich zum fehlenden Stück in solchen Ketten. Für die tägliche Arbeit an Inhalten genügt ein Redakteurskonto — und mit dem hätte dieser Angriff nicht funktioniert.
Eine Einstellung, die hilft — aber nicht überall
In der Konfigurationsdatei lässt sich das Installieren von Themes und Plugins über das Backend ganz unterbinden. Patchstack weist darauf hin, dass der Schaden dann begrenzt bleibt: Ein Angriff wäre weiterhin möglich, aber er könnte keine neuen Themes oder Plugins mehr nachladen.
Der Haken steht in der WordPress-Dokumentation: Dieselbe Einstellung blockiert auch Aktualisierungen von Themes und Plugins über das Backend. Auf einem selbst gepflegten Auftritt wäre das eine Verschlimmbesserung — man würde eine Angriffskette erschweren und dafür alle künftigen Sicherheitsupdates ausbremsen.
Sinnvoll ist die Einstellung dort, wo Aktualisierungen ohnehin von aussen eingespielt werden. Bei uns betreuten Installationen ist das der Fall; wer seine Seite selbst pflegt, lässt besser die Finger davon.
Was wir nicht wissen
Weder die Veröffentlichung von WordPress noch die Analyse von Patchstack sagt etwas darüber, ob diese Lücke bereits ausgenutzt wird. Wir haben keine Belege dafür und behaupten deshalb nichts.
Was sich sagen lässt: Die Analyse ist öffentlich und ausführlich genug, dass der Weg nachvollziehbar ist. Das war bei der Angriffswelle im August der Punkt, an dem es schnell ging.
Am Rande, aber bemerkenswert
In der Danksagungsliste zu 7.1.1 stehen die üblichen Namen von Sicherheitsforschern und aus dem WordPress-Sicherheitsteam. Bei zwei der elf Einträge steht als Melder schlicht ein KI-Unternehmen.
Wir haben im August über KI-gestützte Schwachstellensuche geschrieben — damals vor allem über das Rauschen, das sie bei freien Projekten verursacht. Vier Wochen später stehen zwei Funde davon in den Release Notes des meistgenutzten Redaktionssystems der Welt. Das ist eine Verschiebung, und wir kommen darauf zurück.
Wenn Sie unsicher sind
Wer seine WordPress-Installation bei uns hat, muss nichts tun — die Version ist aktuell, und die Theme-Bestände sehen wir uns im Rahmen der Wartung ohnehin an.
Bei allen anderen sind es zehn Minuten: Version prüfen, ungenutzte Themes löschen, schauen wer alles ein Administratorkonto hat. Wenn Sie bei einer der drei Fragen unsicher sind, sehen wir gern mit Ihnen nach.