wp2shell, die kritische Sicherheitslücke in WordPress: Betroffene Versionen, technische Schäden und was Sie sofort unternehmen sollten

Es ist Freitag, der 17. Juli 2026. WordPress veröffentlicht drei Sicherheitsupdates und aktiviert zusammen mit den neuen Versionen die erzwungenen automatischen Updates auf den betroffenen Websites.

Wenn ein Projekt wie WordPress beschließt, einen Patch auf diese Weise zu veröffentlichen, geht es in der Regel nicht darum, die falsche Farbe einer Schaltfläche zu korrigieren.

In der offiziellen Mitteilung ist die Rede von ein kritisches Problem und ein Problem mit hohem Schweregrad. WordPress empfiehlt eine sofortige Aktualisierung und bestätigt, dass es gerade aufgrund der Schwere der Sicherheitslücke erzwungene Aktualisierungen aktiviert hat.

Es gibt zwei Schwachstellen: CVE-2026-60137, eine SQL-Injection im Kern sowie CVE-2026-63030, ein Problem bei der Verarbeitung von Batch-Anfragen der REST-API. In den neuesten Versionen bilden diese zusammen die sogenannte Kette wp2shell und können zur Ausführung von Code aus der Ferne ohne Authentifizierung führen.

Übersetzt: Auf einer anfälligen Installation muss der Angreifer nicht erst ein Passwort erraten, einen Administrator dazu bringen, auf einen Link zu klicken, oder darauf warten, dass ein bestimmtes Plugin installiert wird. Das Problem liegt im Kern von WordPress.

Dieses Mal sollte das Update nicht auf die Liste der Dinge gesetzt werden, die man erledigt, “wenn gerade Zeit ist”.

Welche WordPress-Versionen sind anfällig für wp2shell?

Die beiden Sicherheitslücken betreffen nicht genau dieselben Versionen. Diese Unterscheidung ist wichtig, da WordPress 6.8 zwar für SQL-Injection anfällig ist, jedoch nicht für die gesamte Kette, die zu RCE führt.

Installierte Version	SQL-Injection	RCE-Kette wp2shell	Korrekte Fassung
6.8.0 – 6.8.5	Ja	Nein	6.8.6
6.9.0 – 6.9.4	Ja	Ja	6.9.5
7.0.0 – 7.0.1	Ja	Ja	7.0.2
7.1 Beta vor Beta 2	Ja	Ja	7.1 Beta 2 oder höher
Vor der Version 6.8	Nein, für diese CVEs	Nein	Das ist jedoch kein Grund, bei einer veralteten Version zu bleiben

Die offizielle WordPress-Quelle stuft die Sicherheitslücke in der REST-API als kritisch ein und bestätigt, dass die Kombination mit einer SQL-Injection zur Ausführung von Code aus der Ferne (Remote Code Execution, RCE) führen kann. Cloudflare fügt eine nützliche Präzisierung hinzu: Die RCE betrifft Installationen ab Version 6.9, bei denen kein persistenter Objekt-Cache verwendet wird – eine in vielen Standardinstallationen übliche Konfiguration.

Die Verwendung von WordPress 6.7 oder einer noch älteren Version bedeutet nicht, dass Ihre Website sicher ist. Es bedeutet lediglich, dass Sie nicht von diesen beiden spezifischen Sicherheitslücken betroffen sind. Eine veraltete Version kann andere Probleme aufweisen, die bereits bekannt sind und schon seit längerem behoben wurden.

Wie funktioniert die Kette, ohne diesen Beitrag in ein Handbuch für Stürmer zu verwandeln

Die erste Schwachstelle betrifft WP_Query, die Klasse, die WordPress zum Erstellen und Verwalten vieler Datenbankabfragen verwendet. Ein Parameter wird nicht ausreichend sicher verarbeitet und kann es ermöglichen, die vorgesehene Abfrage zu verändern. Dies ist der Teil, der die SQL-Injection betrifft.

Die zweite Sicherheitslücke betrifft den Batch-Endpunkt der REST-API. Kurz gesagt kann WordPress den Pfad und die auf eine Anfrage angewendeten Prüfungen durcheinanderbringen, wodurch ein anonymer Benutzer Zugriff auf einen Bereich erhält, der eigentlich geschützt bleiben sollte.

Für sich genommen hat die SQL-Injection einen begrenzteren Wirkungsbereich. Wenn die Route-Confusion die Sperre aufhebt, die anonyme Benutzer davon abhielt, auf das System zuzugreifen, summieren sich die beiden Probleme. Dies kann zum Auslesen der Datenbank, zur Kompromittierung eines Administratorkontos und – bei den von der vollständigen Kette betroffenen Versionen – zur Ausführung von Code im Kontext des Webprozesses führen.

Das bedeutet nicht automatisch Root-Zugriff auf den Server. Es bedeutet jedoch, dass die Website und alles, was der PHP-Prozess lesen oder ändern kann, als gefährdet anzusehen sind. Bei Hosting-Lösungen mit schwacher Isolierung, zu weitreichenden Berechtigungen oder gemeinsam genutzten Geheimnissen kann sich der Schaden ausweiten. Dies ist zwar nicht garantiert, aber technisch denkbar.

Der technische Schaden beschränkt sich nicht nur auf die veränderte Startseite

Das „Defacement“, also die sichtbare Veränderung der Inhalte einer Website, ist fast schon die harmloseste Form des Problems. Es sorgt für Aufsehen und wird schnell entdeckt. Die lästigsten Angriffe versuchen hingegen, dauerhaft zu bleiben.

1. Datenbank gelesen oder bearbeitet

Die Datenbank kann Benutzer, Passwort-Hashes, Inhalte, Konfigurationen, von Formularen erfasste Daten, WooCommerce-Bestellungen sowie von Plugins und Integrationen gespeicherte Informationen enthalten. Der genaue Inhalt variiert von Website zu Website, doch das Prinzip ist einfach: Die Datenbank enthält nicht nur die Blog-Beiträge.

2. Administratorkonten und kompromittierte Sitzungen

Ein Angreifer kann versuchen, Administratorrechte zu erlangen oder zu schaffen, E-Mail-Adressen zu ändern, Rollen anzupassen oder eine gültige Sitzung aufrechtzuerhalten. Durch ein Update des Kerns wird die Sicherheitslücke geschlossen, jedoch wird ein böswilliger Administrator, der vor dem Patch angelegt wurde, dadurch nicht entfernt.

3. Hintertüren in Dateien, Plugins oder geplanten Aufgaben

Der Schadcode kann sich in einem scheinbar harmlosen Plugin, in einem Theme, in einer PHP-Datei in einem ungewöhnlichen Ordner oder in einem geplanten Ereignis befinden. Er kann auch bestehende Dateien verändern, um seine Persistenz weniger auffällig zu machen. Die Website funktioniert nach dem Update wieder normal, doch die Hintertür bleibt offen.

4. Weiterleitungen, Phishing, Malware und SEO-Spam

Eine kompromittierte Website kann Suchmaschinen unterschiedliche Seiten anzeigen, JavaScript einschleusen, nur bestimmte Besucher umleiten oder betrügerische Inhalte hosten. Dies kann die Indizierung beeinträchtigen, Sicherheitswarnungen im Browser auslösen, den Ruf der Domain schädigen und die Bereinigung zu einer wesentlich zeitaufwendigeren Aufgabe machen als das Aufspielen eines Patches.

5. Token und integrierte Funktionen

Viele WordPress-Websites kommunizieren mit CRM-Systemen, E-Mail-Systemen, Zahlungsgateways, Automatisierungsdiensten und externen APIs. Das bedeutet nicht, dass wp2shell automatisch alle diese Systeme kompromittiert. Es bedeutet vielmehr, dass die von der Website lesbaren Anmeldedaten und Tokens möglicherweise widerrufen und neu generiert werden müssen, falls die Installation kompromittiert wurde.

Der Patch schließt die Sicherheitslücke. Er lässt die Zeit nicht zurückdrehen.

Dies ist der Punkt, der bei der klassischen Aufforderung “Bitte sofort aktualisieren” leicht untergehen könnte.

Das Update ist zwingend erforderlich, da es weitere Angriffe auf Basis dieser Kette verhindert. Sollte die Website jedoch weiterhin angreifbar gewesen sein, muss auch geprüft werden, ob sich jemand bereits vor der Installation des Patches Zugang verschafft hat. Ausnutzungsversuche wurden kurz nach der Veröffentlichung in der Praxis beobachtet, und VulnCheck hatte bis zum 19. Juli bereits mehr als zwei Dutzend öffentliche Proof-of-Concept-Angriffe verifiziert.

Also: Erst den Patch installieren, dann sofort überprüfen.

Was ist nun zu tun – der Reihe nach

Überprüfen Sie die tatsächlich installierte Version, ohne davon auszugehen, dass die automatische Aktualisierung erfolgreich war.
Einen Snapshot oder ein überprüfbares Backup erstellen vor dem Eingriff. Sollten bereits verdächtige Anzeichen vorliegen, sichern Sie bitte auch Protokolle und Belege, bevor Sie die Daten löschen.
Auf den richtigen Zweig aktualisieren: 6.8.6, 6.9.5, 7.0.2 oder eine neuere Version, die die Korrekturen enthält.
Bitte überprüfen Sie, ob das Update tatsächlich installiert wurde und die Integrität der Core-Dateien zu überprüfen.
Führen Sie eine Überprüfung nach dem Update durch zu Anmeldung, Formularen, Checkout, API, Webhooks, Automatisierungen und benutzerdefinierten Funktionen.
Nach Anzeichen einer Kompromittierung suchen vom Expositionsfenster bis zum Zeitpunkt der Patch-Verabreichung.

Über WP-CLI können grundlegende Überprüfungen wie folgt gestartet werden:

WP-Kernversion
WP-Kern-Update --minor
WP-Kernversion
WP-Kern-Prüfsummenüberprüfung

Der Aktualisierungsbefehl verändert die Website. In der Produktionsumgebung sollte er nur bei Vorliegen einer Sicherungskopie und unter sofortiger Überprüfung der kritischen Funktionen ausgeführt werden. In einem Sicherheitsnotfall würde ich jedoch einen endlosen Testzyklus nicht als Vorwand dafür nutzen, eine anfällige Version online zu lassen.

Was Sie nach dem Update überprüfen sollten

Anormale Anfragen an /wp-json/batch/v1 e ?rest_route=/batch/v1 in den Protokollen des Webservers, des CDN und des WAF.
Neue Administratoren, Rollenänderungen, geänderte E-Mail-Adressen und Sitzungen, die Sie nicht erkennen.
Kürzlich installierte Plugins oder Themes, die nicht vorgesehen waren.
Geänderte Dateien, PHP in ungewöhnlichen Verzeichnissen, Abweichungen bei den Prüfsummen des Kerns und verschleierter Code.
Unerwartete WP-Cron-Ereignisse, Änderungen an wp_options, geänderte URLs, Weiterleitungen und geänderte Konfigurationen.

Sollten verdächtige Anzeichen auftreten, löschen Sie nicht wahllos Dateien. Isolieren Sie die Website, sichern Sie die Beweismittel, rekonstruieren Sie den Ablauf der Ereignisse und erwägen Sie eine Wiederherstellung aus einer unversehrten Quelle. Ändern Sie anschließend alle Passwörter, Sitzungen, Schlüssel und Tokens, auf die die Website Zugriff hatte.

Eine Anwendungs-Firewall kann das Risiko mindern. Cloudflare hat auch im kostenlosen Tarif spezielle Regeln für den tatsächlich von seiner WAF geproxten Datenverkehr bereitgestellt. Searchlight Cyber empfiehlt darüber hinaus die vorübergehende Sperrung des anonymen Zugriffs auf Batch-Endpunkte als Notfallmaßnahme. Diese ist jedoch, wie bereits erwähnt, nur vorübergehend: Sie kann legitime Funktionen beeinträchtigen und ersetzt den Patch nicht.

Häufig gestellte Fragen zu wp2shell

Nutzt wp2shell Plugins oder Themes von Drittanbietern?

Nein. Die Kette betrifft den Kern von WordPress und kann eine Standardinstallation ohne Plugins betreffen. Vorhandene Plugins können jedoch die möglichen weiteren Angriffspfade erweitern, sobald sich der Angreifer Zugang verschafft hat.

Bin ich gefährdet, wenn ich WordPress 6.8.x verwende?

Die Versionen 6.8.0 bis 6.8.5 sind anfällig für die SQL-Injection-Schwachstelle CVE-2026-60137, jedoch nicht für die vollständige RCE-Kette „wp2shell“. Der Fix für diesen Zweig ist WordPress 6.8.6.

Schützt mich das erzwungene automatische Update?

Die Sicherung ist nur dann wirksam, wenn sie erfolgreich durchgeführt wurde. Dateisystemberechtigungen, Konfigurationen, Verwaltungs-Plugins oder Bereitstellungsverfahren können die Aktualisierung verhindern oder überschreiben. Die tatsächliche Version sollte überprüft werden.

Reicht ein WAF aus, ohne dass ein Update erforderlich ist?

Nein. Der WAF dient als zusätzliche Schutzmaßnahme und vorübergehende Abhilfemaßnahme. Die endgültige Behebung besteht in der Aktualisierung des Kerns auf eine sichere Version.

Muss ich die Website trotzdem überprüfen, wenn ich sie aktualisiert habe?

Ja, insbesondere wenn die Website nach der Bekanntgabe weiterhin mit einer anfälligen Version online war. Der Patch verhindert neue Angriffe, die auf dieser Sicherheitslücke basieren, beseitigt jedoch keine zuvor erstellten Konten, Dateien oder Hintertüren.

Das geschäftliche Problem verdient eine gesonderte Erörterung

Hier habe ich den Schwerpunkt auf die technische Funktionsweise, mögliche Schäden und die durchzuführenden Überprüfungen gelegt. Zu Bei WebWakeUp haben wir uns mit der anderen Seite der Sache befasst: Betriebskontinuität, Daten, Umsatz, Ruf und Verantwortlichkeiten zwischen Unternehmen, Hosting-Anbieter und technischem Dienstleister.