Am 17. Juli hat WordPress die Versionen 7.0.2 und 6.9.5 veröffentlicht, und dieser Patch ist keine Routineangelegenheit. Er schließt eine kritische Sicherheitslücke, die inzwischen unter dem Namen wp2shell kursiert und die ohne Anmeldung und ohne verwundbares Plugin ausnutzbar ist, allein über eine gewöhnliche HTTP-Anfrage an eine unveränderte Standardinstallation. Für ein Content-Management-System, das nach aktuellen Zahlen einen Anteil von rund 40 Prozent aller Websites weltweit hat, ist das keine Randnotiz. Es betrifft mit hoher Wahrscheinlichkeit auch die eine oder andere Firmenwebsite, die Sie oder Ihre Geschäftspartner gerade betreiben.

Was hinter wp2shell steckt

Die Lücke verbindet zwei Schwachstellen im WordPress-Kern selbst, nicht in einem Drittanbieter-Plugin. Die eine steckt in der REST-API-Verarbeitung von Batch-Anfragen, die andere ermöglicht eine SQL-Injection über einen Parameter der internen Abfrage-Funktion. Verkettet erlauben beide Lücken zusammen eine Codeausführung ohne jede Authentifizierung. Betroffen sind die Versionsreihen 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1 mit beiden Schwachstellen, die Reihe 6.8.0 bis 6.8.5 zumindest mit der SQL-Injection. Wer eine Version vor 6.8 einsetzt, ist von wp2shell selbst nicht betroffen, was allerdings eher an veralteter Software liegt als an Sicherheit, und genau das bringt seine eigenen Probleme mit sich.

Wegen des Schweregrads hat WordPress für betroffene Installationen die automatischen Hintergrund-Updates aktiv erzwungen. Das klingt beruhigend, ist es aber nur bedingt. Diese automatischen Updates laufen im Hintergrund und schlagen in der Praxis gelegentlich fehl, etwa wegen Dateiberechtigungen, eines eingeschränkten Hosting-Setups oder eines Konflikts mit einem Plugin. Ob die eigene Seite den Patch tatsächlich erhalten hat, sieht man nicht automatisch. Das muss man prüfen.

Wie ernst die Lage ist

Bereits am 18. Juli tauchten öffentlich einsehbare Proof-of-Concept-Exploits auf, und Sicherheitsforscher berichteten von ersten Hinweisen auf tatsächliche Ausnutzung in freier Wildbahn. Die deutsche Fachpresse hat das Thema in den Tagen danach ebenfalls als dringlich eingestuft. Die veröffentlichten Exploits demonstrieren bislang vor allem den SQL-Injection-Teil, mit dem sich etwa Passwort-Hashes von Administratorkonten auslesen lassen. Der volle Sprung zur Codeausführung, wie ihn WordPress selbst in seinem eigenen Advisory beschreibt, verlangt je nach Konfiguration noch weitere Schritte. Das macht die Lücke nicht harmlos, es bedeutet nur, dass die praktische Angriffskette in freier Wildbahn noch nicht überall vollständig öffentlich dokumentiert ist. Wer wartet, bis das der Fall ist, wartet zu lange.

Was Sie als Website-Betreiber jetzt konkret prüfen sollten

Der erste Schritt ist simpel und oft vernachlässigt: im WordPress-Backend unter Dashboard und Updates nachsehen, welche Version tatsächlich läuft, nicht nur, welche laut Hosting-Anbieter installiert sein sollte. Steht dort noch eine Version unter 6.9.5 oder 7.0.2, muss von Hand aktualisiert werden, am besten sofort und nicht erst beim nächsten geplanten Wartungstermin.

Der zweite Schritt betrifft die Frage, ob in der Zwischenzeit schon etwas passiert ist. Ein Blick in die Zugriffsprotokolle des Servers auf ungewöhnliche Anfragen an die REST-API, ein Abgleich der Administratorkonten auf unbekannte Zugänge und eine Prüfung, ob neue, nicht selbst installierte Plugins oder Dateien aufgetaucht sind, gehören dazu. Bei einem Shop auf WooCommerce-Basis kommt die Frage nach möglicherweise abgeflossenen Kundendaten hinzu, und das ist dann auch ein Thema für die eigene DSGVO-Dokumentation.

Der dritte Schritt ist der unbequemste, aber langfristig wichtigste. Eine Website, die ausschließlich über automatische Updates und das Vertrauen auf schnelle Patches abgesichert ist, bleibt strukturell verwundbar für die nächste Lücke dieser Art, und eine wird kommen. Wer eine gewachsene WordPress-Installation mit vielen Plugins betreibt, deren Herkunft und Pflegezustand niemand mehr genau kennt, sollte diesen Vorfall zum Anlass nehmen, die Angriffsfläche grundsätzlich zu verkleinern. Das kann eine Bereinigung um ungenutzte Plugins sein, ein Update-Prozess mit fester Verantwortlichkeit, oder je nach Anforderung auch der Umstieg auf eine schlankere, individuell entwickelte Lösung, die nicht von der Update-Disziplin eines riesigen Plugin-Ökosystems abhängt.

wp2shell wird nicht die letzte kritische WordPress-Lücke sein, und sie ist auch kein Grund für Panik. Sie ist aber ein guter Anlass, einmal ehrlich zu prüfen, wie gut die eigene Website tatsächlich gewartet wird, und nicht nur, wie gut sie aussieht.