wp2shell: Kritische WordPress-Lücke erlaubt Fernzugriff — was jetzt zu tun ist
Zwei Schwachstellen im WordPress-Kern lassen sich zu einer Angriffskette verbinden, die ohne Anmeldung fremden Code ausführt. Das BSI warnt, Angriffe laufen bereits. Welche Versionen betroffen sind und wie Sie Ihre Seite prüfen.
Das BSI hat eine Warnung der Stufe Orange veröffentlicht: Zwei Schwachstellen im WordPress-Kern lassen sich zu einer Angriffskette verbinden, die einem Angreifer ohne jede Anmeldung die Ausführung von fremdem Code auf Ihrem Webserver erlaubt. Die Kette hat den Namen wp2shell bekommen.
Das Besondere daran: Es geht nicht um ein einzelnes Plugin, das man eben deaktivieren könnte. Betroffen ist WordPress selbst — in der Standardinstallation. Und es wird bereits aktiv ausgenutzt.
Die Kurzfassung
| Merkmal | Angabe |
|---|---|
| Betroffen | WordPress 6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0–7.0.1, 7.1 beta |
| Behoben in | 6.8.6, 6.9.5, 7.0.2, 7.1 beta2 |
| Nicht betroffen | Versionen älter als 6.8 |
| CVEs | CVE-2026-60137, CVE-2026-63030 |
| Bewertung der Kette | CVSS 9.8 (kritisch) |
| Status | Angriffe laufen, Exploits sind öffentlich |
Wenn Ihre Seite in diesem Versionsbereich liegt und noch nicht aktualisiert wurde: Das ist der Punkt, an dem Sie den Artikel unterbrechen und zuerst aktualisieren sollten. Der Rest lässt sich danach in Ruhe lesen.
Was steckt technisch dahinter?
Die Angriffskette besteht aus zwei Lücken, die einzeln nur begrenzt gefährlich sind — zusammen aber die volle Kontrolle ermöglichen.
CVE-2026-60137 liegt in der Datenbankabfrage WP_Query. Der Parameter author__not_in wird nicht sauber bereinigt und lässt sich für eine SQL-Injection missbrauchen. Damit kann ein Angreifer die Datenbank auslesen — unter anderem die Tabelle wp_users mit allen Passwort-Hashes.
CVE-2026-63030 steckt in der REST-Schnittstelle von WordPress. Für sich genommen wird sie als mittelschwer eingestuft.
Verbindet man beide, entsteht daraus die Ausführung beliebigen Codes aus der Ferne — ohne Zugangsdaten, ohne Benutzerkonto, ohne Mitwirkung eines Administrators.
Warum die Bewertungen so weit auseinandergehen
Wenn Sie zu den CVE-Nummern recherchieren, werden Ihnen unterschiedliche Werte begegnen. Die WordPress-Community stuft CVE-2026-60137 mit 5.3 als mittelschwer ein, andere Stellen mit 9.1 als kritisch. Bei CVE-2026-63030 schwanken die Angaben zwischen 7.5 und 9.8.
Der Grund: Die Bewertungen unterscheiden sich darin, wie aufwendig ein Angriff eingeschätzt wird und welche Folgen unterstellt werden. Für die Praxis zählt die Kette — und die wird mit 9.8 bewertet. Lassen Sie sich von einer niedrigen Einzelbewertung also nicht in Sicherheit wiegen.
Warum dieser Fall anders liegt als üblich
Die meisten WordPress-Sicherheitsmeldungen betreffen Plugins oder Themes. Man prüft, ob man das betroffene Plugin einsetzt, und ist im Zweifel gar nicht betroffen.
Hier ist das anders — und darin liegt die eigentliche Brisanz:
Es trifft den Kern. Jede WordPress-Installation im genannten Versionsbereich ist betroffen, unabhängig davon, welche Plugins oder Themes laufen.
Die Zeit bis zum Angriff war extrem kurz. WordPress hat die Updates am 17. Juli veröffentlicht. Nur wenige Stunden später kursierten die ersten funktionsfähigen Exploits, kurz darauf gab es Berichte über tatsächliche Angriffe. Das Zeitfenster zwischen „Lücke bekannt” und „Lücke wird ausgenutzt” schrumpft seit Jahren — dieser Fall zeigt es besonders deutlich.
Automatisierte Angriffe sind wahrscheinlich. In Deutschland laufen mehrere Millionen WordPress-Seiten. Verwundbare Installationen werden typischerweise nicht gezielt gesucht, sondern maschinell abgegrast. Was danach installiert wird, reicht von Cryptominern über Hintertüren bis zu Erpressungstrojanern.
Eine Einordnung, die zeigt, welcher wirtschaftliche Druck dahintersteckt: Für eine WordPress-Lücke dieser Art zahlen Exploit-Händler nach Angaben der Entdecker Beträge im sechsstelligen Bereich.
Eine bemerkenswerte Randnotiz
Gefunden wurde die Schwachstellenkette vom Sicherheitsunternehmen Searchlight Cyber — mithilfe eines KI-Modells. Das ist kein Detail am Rande, sondern ein Hinweis darauf, wohin sich die Sicherheitsforschung bewegt: Werkzeuge, die Quellcode systematisch nach solchen Verkettungen durchsuchen, stehen künftig beiden Seiten zur Verfügung. Die Zeit zwischen Veröffentlichung und Ausnutzung dürfte weiter sinken.
Sind Sie betroffen?
Ihre WordPress-Version finden Sie im Adminbereich unter Dashboard → Aktualisierungen, oder rechts unten auf der Übersichtsseite.
Achten Sie auf einen Sonderfall: Bei der Zweig-Version 6.8.x schließt das Update auf 6.8.6 nur CVE-2026-60137. Von CVE-2026-63030 ist dieser Zweig ohnehin nicht betroffen — mit 6.8.6 sind Sie dort also vollständig abgesichert.
Die Sicherheitsforscher stellen unter wp2shell.com zusätzlich eine Prüfseite bereit, mit der sich die Verwundbarkeit einer Seite testen lässt.
Was jetzt zu tun ist
1. Aktualisieren — und zwar prüfen, ob es geklappt hat
WordPress installiert Sicherheitsupdates in der Regel automatisch. Verlassen Sie sich diesmal aber nicht darauf, sondern kontrollieren Sie es.
Automatische Updates scheitern häufiger, als vielen bewusst ist: Sie wurden irgendwann bewusst deaktiviert, die Dateiberechtigungen auf dem Server verhindern das Schreiben, oder ein früherer Fehlschlag hat den Mechanismus stillgelegt. In all diesen Fällen müssen Sie die abgesicherte Version von Hand installieren.
2. Wenn Sie nicht sofort aktualisieren können
Falls ein Update kurzfristig nicht möglich ist — etwa weil erst getestet werden muss —, gibt es zwei Notbehelfe:
- Über eine Web Application Firewall (WAF) Aufrufe von
/wp-json/batch/v1sowie den Parameter?rest_route=/batch/v1blockieren. - Ein Plugin einsetzen, das anonyme Anmeldungen an der REST-Schnittstelle unterbindet.
Beides sind Übergangslösungen. Sie ersetzen das Update nicht, verschaffen aber Zeit.
3. Prüfen, ob Sie bereits getroffen wurden
Das ist der Punkt, den viele überspringen — zu Unrecht. Wenn Ihre Seite nicht direkt am Tag der Veröffentlichung aktualisiert wurde, gab es ein Zeitfenster, in dem sie angreifbar war.
Prüfen Sie Ihre Server- und Zugriffsprotokolle auf diese Spuren:
- POST-Anfragen an
/wp-json/batch/v1— besonders eine auffällig hohe Anzahl - Aufrufe mit
?rest_route=/batch/v1 - Anmeldeversuche mit Benutzernamen nach dem Muster
wp2_*oderw2s_* - Administratorkonten mit E-Mail-Adressen auf
@wp2shell.invalidoder@wp2shell.shellcode.lol - Veränderungen in den Datenbanktabellen
oembed_cacheundcustomize_changeset - Neue oder veränderte Dateien, Plugins und Konten — insbesondere zusätzliche Administratoren
- Ungewöhnliche Prozesse oder Shell-Befehle auf dem Webserver
- Ungewöhnliche ausgehende Verbindungen
4. Im Ernstfall
Wenn sich der Verdacht erhärtet, reicht ein Update nicht mehr aus — der Angreifer ist dann bereits im System.
Setzen Sie alle Passwörter zurück. Über die SQL-Injection konnten sämtliche Passwort-Hashes aus wp_users abgeflossen sein. Diese lassen sich in Ruhe offline knacken. Jedes Konto, das dieses Passwort auch woanders nutzt, ist mitbetroffen.
Isolieren Sie das System und sichern Sie Beweise, bevor Sie aufräumen. Beenden Sie aktive Sitzungen.
Ziehen Sie eine Neuinstallation in Betracht. Bei bestätigter Codeausführung ist ein sauberer Neuaufbau aus einem geprüften Backup verlässlicher als der Versuch, Hintertüren einzeln zu finden.
Prüfen Sie verbundene Systeme. Ein kompromittierter Webserver ist oft nur der erste Schritt — Datenbankserver, Mailkonten und angebundene Dienste gehören mit auf die Liste.
Was wir daraus mitnehmen
Zwei Dinge sind an diesem Fall lehrreich, unabhängig von den konkreten Nummern:
Automatische Updates sind kein Nice-to-have. Der eingeschränkte Versionsbereich und die standardmäßig aktivierten Updates haben die Angriffsfläche spürbar verkleinert. Entscheidend war, ob sie tatsächlich funktioniert haben. Prüfen Sie das bei Gelegenheit für alle Ihre Seiten — nicht nur heute.
Eine WAF verschafft Ihnen Zeit. Sie ersetzt keine Updates, aber sie kann ein Angriffsmuster abwehren, während Sie noch testen. Für Webseiten mit wichtigen Funktionen ist das eine Überlegung wert.
Unsicher, ob Ihre Seite betroffen ist?
Wir übernehmen die Prüfung für Sie — Version, Protokollanalyse auf die genannten Spuren und, falls nötig, die Bereinigung. Für Kunden mit Wartungsvertrag ist das bereits erledigt.
Schreiben Sie uns — im Zweifel lieber einmal zu viel nachgesehen.
Quelle: BSI-Cybersicherheitswarnung BITS-H Nr. 2026-271984-1132, Version 1.1 vom 20.07.2026. Die technischen Details stammen aus der Veröffentlichung von Searchlight Cyber.