WordPress-Sicherheitslücke wp2shell: Sind Sie betroffen?

Was ist wp2shell und warum ist die Lücke so kritisch?

wp2shell ist keine einzelne Schwachstelle, sondern die Verkettung von zweien. CVE-2026-60137 bereinigt den Parameter author__not_in bei WP_Query-Abfragen fehlerhaft, sodass sich eigene Datenbank-Befehle einschleusen lassen: eine SQL-Injection. CVE-2026-63030 verwechselt Routen in der REST-API. Erst beide zusammen ergeben Remote Code Execution, also fremden Programmcode auf dem Server, ohne jede Anmeldung.

Diesmal war es der Core selbst. Laut Cybersicherheitswarnung des BSI betrifft der Sachverhalt „das CMS in seiner Standardinstallation selbst und keine einzelnen Plugins oder Themes“. Das BSI stuft die Kritikalität auf 3 von 4 (Orange) ein: Maßnahmen müssen unverzüglich ergriffen werden. Orange ist die zweithöchste von vier Stufen, nicht die höchste.

Einen einheitlichen Schweregrad gibt es nicht: Die Bewertungen der Einzel-Schwachstellen reichen je nach Stelle von mittel bis kritisch. Das BSI bewertet deshalb die Kette als Ganzes, mit einem CVSS-3.1-Score von 9,8. Beide Schwachstellen stehen im CISA-KEV-Katalog der bekannten ausgenutzten Sicherheitslücken, darunter CVE-2026-63030 im NVD. Das BSI bleibt dabei nüchtern: Der eingeschränkte Versionsbereich, verbreitete Web Application Firewalls und aktive automatische Updates senken die Wahrscheinlichkeit einer sehr breiten Angriffswelle.

Bin ich betroffen? Diese WordPress-Versionen sind verwundbar

Verwundbar sind WordPress 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1, abgesichert sind 6.8.6, 6.9.5 und 7.0.2. Die entscheidende Nuance steht in der zweiten Zeile: WordPress 6.8.x ist nur von der SQL-Injection betroffen, nicht von der vollständigen Angriffskette. Version 6.8.6 schließt CVE-2026-60137; CVE-2026-63030 betrifft 6.8.x nicht. Aus dieser Kette droht bei 6.8.x also keine Fernübernahme des Servers, auslesbar bleiben aber die Passwort-Hashes aus der Tabelle wp_users. Aktualisieren, ja. In Panik verfallen, nein. Versionen älter als WordPress 6.8 sind laut BSI von keiner der beiden Schwachstellen betroffen.

Wie finde ich heraus, welche WordPress-Version ich habe?

Mit Login führt der beste Weg über Dashboard → Aktualisierungen. Dieser Screen zeigt die installierte Version und zugleich, ob automatische Updates greifen. Alternativ steht sie im Widget „Auf einen Blick“ oder unten rechts im Admin-Footer. Ohne Login hilft der Quelltext der Startseite, dort steht die Version im Meta-Tag generator. Wichtig: Viele Sicherheits-Plugins entfernen diese Angabe, und ihr Fehlen ist kein Beweis dafür, dass alles in Ordnung ist. Über genau diese sichtbare Angabe finden Angreifer verwundbare Ziele automatisiert.

Das BSI verweist zusätzlich auf einen Webseiten-Checker von Searchlight Cyber unter der Domain wp2shell.com. Zum Zeitpunkt meiner Recherche wies die Seite allerdings keine sichtbare Datenschutzerklärung aus und legte ihre Prüfmethode nicht offen, deshalb bleibt der Dashboard-Weg der empfohlene.

Was sollten Sie jetzt sofort tun?

Vier Schritte, in dieser Reihenfolge:

1. Version feststellen: im Dashboard unter Aktualisierungen ablesen, welcher Zweig läuft.
2. Vorher sichern: Legen Sie ein vollständiges Backup von Dateien und Datenbank an. Wie das geht, zeigt meine Anleitung WordPress-Backup erstellen.
3. Auf die abgesicherte Version aktualisieren: je nach Zweig mindestens auf 6.8.6, 6.9.5 oder 7.0.2. Damit schließen Sie diese Lücke. Besser gleich auf den aktuellen Stand des Zweigs: 6.8.7, 6.9.6 oder 7.0.3.
4. Wenn das Update nicht durchläuft: Meist blockiert ein inkompatibles Plugin oder eine veraltete PHP-Version. Finden Sie die Ursache nicht in wenigen Minuten, geben Sie an Ihren Hoster oder Dienstleister ab.

Wer nicht sofort aktualisieren kann, findet beim BSI zwei Workarounds: „Blockieren von Aufrufen zu /wp-json/batch/v1 sowie mit dem Parameter ?rest_route=/batch/v1 mit Hilfe einer Web Application Firewall (WAF)“ und „Die Installation eines Plugins zur Blockierung von Anonymous-Anmeldungen an der REST-API“.

Die Sperre ohne WAF: eine Regel in der .htaccess

Eine gebuchte Web Application Firewall braucht es dafür nicht zwingend. Läuft die Website auf einem Apache-Server, erledigt diese Regel dasselbe für den Batch-Endpunkt. Sie gehört in die .htaccess im Stammverzeichnis, und zwar vor den Block # BEGIN WordPress:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-json/batch/v1 - [F,L]
RewriteCond %{QUERY_STRING} (^|&)rest_route=/?batch/v1 [NC]
RewriteRule ^ - [F,L]
</IfModule>

Der Server beantwortet die beiden Aufrufwege damit mit einem 403, PHP startet gar nicht erst. Vier Punkte gehören dazu: Die Regel wirkt nur auf Apache — läuft die Seite hinter nginx, gehört die Sperre in die Server-Konfiguration. Sie muss oberhalb des WordPress-Blocks stehen, weil der alles Weitere an die index.php übergibt. Der Batch-Endpunkt wird vom Block- und Site-Editor für Sammel-Operationen genutzt, prüfen Sie das Backend nach dem Einbau also einmal kurz. Und eine echte WAF leistet mehr: Sie erkennt auch URL-kodierte Schreibweisen desselben Aufrufs. Diese Regel deckt die zwei Wege ab, die das BSI ausdrücklich benennt.

Das BSI führt den Workaround als Ergänzung zum Update, nicht als Ersatz dafür. Er verschafft Zeit, bis aktualisiert werden kann — mehr nicht.

Warum reicht ein Update allein noch nicht?

WordPress.org hat wegen der Schwere erzwungene Updates über das Auto-Update-System für betroffene Versionen ausgelöst, nachzulesen im Sicherheitsrelease WordPress 7.0.2. Die erzwungenen Auto-Updates greifen jedoch nicht überall: Das BSI benennt deaktivierte automatische Updates und Szenarien, in denen sie an Dateiberechtigungen scheitern. Dazu kommen verwaiste Installationen, die niemand mehr betreut. Betreiber, deren Websites nicht am Tag der Veröffentlichung automatisch aktualisiert wurden, sollten deshalb zusätzlich auf eine bereits stattgefundene Kompromittierung prüfen.

Der Grund liegt in der Zeitachse: Das Sicherheitsupdate erschien am 17. Juli 2026, am Wochenende darauf kursierten öffentliche Machbarkeitsnachweise für die vollständige Kette. Das BSI warnte unmittelbar nach dem Update und aktualisierte die Warnung am 20. Juli 2026, weil die veröffentlichten Machbarkeitsnachweise Angriffe ohne Anmeldung ermöglichten.

Woran erkennen Sie, ob Ihre Website bereits angegriffen wurde?

Diese vier Punkte können Sie selbst im Dashboard prüfen:

• ✓ Neue oder unbekannte Administrator-Konten
• ✓ Administrator-Konten mit Mailadressen auf @wp2shell.invalid oder @wp2shell.shellcode.lol
• ✓ Benutzernamen mit den Präfixen wp2_ oder w2s_
• ✓ Plugins, die Sie nie installiert haben

Wichtig dabei: Diese Liste deckt die bekannten Spuren ab, nicht alle denkbaren. Ein unauffälliges Dashboard ist ein gutes Zeichen, aber kein Nachweis. Die folgenden Punkte gehören deshalb in die Hände Ihres Hosters oder Entwicklers:

• POST-Requests auf /wp-json/batch/v1 in den Server-Logs, laut BSI besonders bei erhöhter Anfragemenge
• Requests mit dem Parameter ?rest_route=/batch/v1
• Auffälligkeiten in oembed_cache und customize_changeset
• Neu erstellte PHP-Dateien seit dem 16. Juli 2026, etwa als getarntes Plugin-Verzeichnis, also eine Backdoor (Eye Security)
• Ungewöhnliche Shell-Befehle auf dem Server sowie ungewöhnliche ausgehende Verbindungen, beides laut BSI

An die Protokolle kommen Sie über WordPress Error-Logs finden und lesen. Die Sicherheitsfirma Eye Security warnt: Fehlende Log-Einträge sind kein Beweis für Sicherheit, die entscheidenden Schritte laufen im POST-Body.

Bei Verdacht müssen alle Passwörter der Nutzerkonten zurückgesetzt werden, weil die SQL-Injection CVE-2026-60137 sämtliche Passwort-Hashes aus der Tabelle wp_users auslesen kann und diese sich offline knacken lassen. Das BSI empfiehlt zusätzlich, das System zu isolieren, Beweise zu sichern und aktive Sitzungen zu beenden. Der „Compromise Scanner for wp2shell“ von Eye Security im Plugin-Verzeichnis ändert laut den Entwicklern nichts an der Website und behebt die Schwachstelle nicht.

Wird der Verdacht auf Malware konkret: Website gehackt: Malware finden und entfernen, Website aus einem Backup wiederherstellen, kostenlose Malware-Scanner für Websites sowie Google-Blacklist nach einem Hack entfernen. Sind personenbezogene Daten abgeflossen, gehört die Frage nach Meldepflichten zu einem Rechtsanwalt oder Datenschutzbeauftragten.

Was verrät dieser Fall über die Zukunft?

Die Schwachstellenkette wurde von Adam Kues von der Sicherheitsfirma Searchlight Cyber KI-gestützt gefunden. Die vollständige Exploit-Kette entstand in rund zehn Stunden zu Kosten von etwa 25 US-Dollar; das BSI verweist in seiner Warnung ausdrücklich darauf. Zum Vergleich: Exploit-Broker zahlen für eine WordPress-Lücke dieser Art sechsstellige Summen.

Aus meiner Entwicklerperspektive verschiebt das die Rechnung für kleine Unternehmen. Die Zeit zwischen „Lücke bekannt“ und „Lücke ausgenutzt“ schrumpft weiter, und keine manuelle Update-Routine ist schnell genug für dieses Fenster. Automatische Updates aktiviert zu lassen ist deshalb keine Bequemlichkeit mehr, sondern eine der wenigen Maßnahmen, die mit diesem Tempo mithalten. Was darüber hinaus sinnvoll ist, steht im Ratgeber Website-Sicherheit für Unternehmen. Wenn niemand darauf achtet, ob die Updates auch wirklich ankommen: In meiner WordPress-Wartung prüfe ich jede Woche, ob WordPress, Plugins und Themes aktuell sind, und spiele fehlende Updates nach einem Backup ein.

Ein Update ist allerdings nicht auf jeden Vorfall die Antwort. Beim Lieferkettenangriff auf die Elementor-Addons von BdThemes, den Wordfence am 8. August 2026 öffentlich machte, kam der Schadcode über einen nachgeladenen Datenstrom des Herstellers statt über den Plugin-Code — dort hätte auch ein aktuelles Plugin nicht geschützt. Bei wp2shell schließt das Update die Lücke, bei einem vergifteten Zulieferer greift dieser Hebel nicht. Auch bei der PHP-Sicherheitslücke PHP2Shell im Oktober 2026 half kein WordPress-Update, weil der Fehler in PHP selbst steckte; geschlossen hat sie erst die gepatchte PHP-Version.