Veröffentlicht am 28.07.2026
Stellen Sie sich vor, ein Angreifer übernimmt die vollständige Kontrolle über Ihre WordPress-Website – ohne Passwort, ohne verwundbares Plugin, ohne dass Sie irgendetwas falsch konfiguriert haben. Eine ganz normale, aktuelle WordPress-Installation genügt. Genau das ist die Realität hinter wp2shell, einer kritischen Sicherheitslücke, die seit dem 17. Juli 2026 aktiv ausgenutzt wird. Es ist die erste kritische, unauthentifizierte Remote-Code-Execution-Lücke (Ausführung von Schadcode aus der Ferne) im WordPress-Kern seit fast einem Jahrzehnt. Und wenn Ihre Website noch nicht aktualisiert ist, sollten Sie sie als aktiven Notfall behandeln.
Am 17. Juli 2026 veröffentlichte das WordPress-Sicherheitsteam Notfall-Updates für zwei miteinander verkettete Schwachstellen im WordPress-Kern. Zusammen tragen sie den Namen wp2shell – eine Anspielung auf das Ziel des Angriffs: von WordPress direkt zur „Shell“, also zur vollständigen Kontrolle über den Server.
Die beiden Schwachstellen sind:
Einzeln wären beide unangenehm. In Kombination sind sie verheerend: Ein anonymer Angreifer aus dem Internet kann mit einer einzigen HTTP-Anfrage einen neuen Administrator-Account anlegen und beliebigen Code mit den Rechten des Webservers ausführen. Keine Anmeldung, keine Benutzerinteraktion, kein zusätzliches Plugin nötig.
Entdeckt wurde die Lücke vom Sicherheitsforscher Adam Kues (Assetnote / Searchlight Cyber) – mithilfe eines KI-Modells und für gerade einmal rund 25 US-Dollar an Rechenkosten. Zum Vergleich: Exploit-Broker zahlen laut Kues bis zu 500.000 US-Dollar für einen funktionierenden WordPress-RCE-Exploit. Diese Diskrepanz zeigt, wie stark KI die technische Hürde für die Entwicklung solcher Angriffe gesenkt hat.
Die Angriffskette besteht aus zwei ineinandergreifenden Fehlern. Hier eine vereinfachte Darstellung:
WordPress bietet eine sogenannte Batch-API an – eine Schnittstelle, über die man mehrere Anfragen auf einmal bündeln kann. Der zuständige Programmteil prüft diese Anfragen zuerst (Validierung) und führt sie dann aus. Das Problem: Wenn eine einzelne Teilanfrage bei der Prüfung durchfällt, wird nur eine der beiden internen Listen aktualisiert, die andere nicht. Dadurch verrutscht die Zuordnung – nachfolgende Anfragen werden unter dem falschen „Handler“ ausgeführt, also von einem Programmteil verarbeitet, der gar keine Prüfung der übergebenen Parameter vornimmt. Ben Marr, Security Engineer bei Intruder, beschreibt es so:
„CVE-2026-63030 ist der Einstiegspunkt – ein Route-Confusion-Bug im REST-API-Batch-Endpunkt, der die Authentifizierung umgeht und es einem Angreifer erlaubt, interne Handler ohne jede Berechtigungsprüfung aufzurufen.“ – Ben Marr, Intruder
Über diese umgangene Prüfung kann der Angreifer nun einen Parameter namens author__not_in manipulieren. Normalerweise wird dieser Wert nur dann korrekt bereinigt, wenn er als Liste von Zahlen übergeben wird. Gibt man ihn stattdessen als einfache Zeichenkette an, landet er ungeprüft direkt in einer Datenbankabfrage – der klassische Nährboden für eine SQL-Injection.
Über die SQL-Injection lässt sich der interne Zwischenspeicher von WordPress „vergiften“. Über weitere Mechanismen – den oEmbed-Cache, Customizer-Changesets und einen Zyklus-Erkennungs-Baustein – nimmt der Angreifer vorübergehend die Identität eines Administrators an. In diesem Moment wird eine zuvor abgelehnte Anfrage zum Anlegen eines Benutzers erneut ausgewertet – und diesmal erfolgreich. Ein neuer Admin-Account entsteht (HTTP-Status 201). Der Angreifer meldet sich an, installiert ein bösartiges Plugin und führt Code aus.
Die einzige Voraussetzung: eine öffentlich erreichbare WordPress-Installation der Version 6.9.x oder 7.0.x ohne persistenten Objekt-Cache, bei der der Endpunkt /wp-json/batch/v1 erreichbar ist.
Betroffen sind folgende WordPress-Versionen:
Versionen vor 6.8 sowie die gepatchten Versionen 6.8.6, 6.9.5 und 7.0.2 sind nicht betroffen.
Das Ausmaß ist enorm. Laut Wiz Research hatten zum Zeitpunkt der Veröffentlichung 60 Prozent aller WordPress-nutzenden Organisationen mindestens eine verwundbare Instanz, 25 Prozent exponierten einen verwundbaren Server direkt ins Internet. WordPress betreibt rund 42,6 Prozent aller Websites weltweit – über 522 Millionen Installationen.
Für deutsche KMU ist die Lage besonders brisant: Deutschland ist mit rund 1,9 Millionen WordPress-Websites der zweitgrößte WordPress-Markt der Welt. Benjamin Harris, CEO von watchTowr, ordnet die Seltenheit ein:
„WordPress bekommt oft einen schlechten Ruf in Sachen Sicherheit. Aber in Wahrheit ist eine wirkungsvolle, unauthentifizierte SQL-Injection oder Remote-Code-Execution-Lücke im WordPress-Kern ziemlich selten. Genau das macht diese hier so besonders – und deshalb versuchen gerade alle, zu patchen, bevor die massenhafte Ausnutzung Fahrt aufnimmt.“ – Benjamin Harris, watchTowr
Das Erschreckende: Die Angriffe begannen praktisch sofort. Bereits um 23:29 UTC am 17. Juli 2026 – weniger als sechs Stunden nach Veröffentlichung der Patches – registrierte Wordfence erste Probes gegen den REST-API-Endpunkt. Um 23:42 UTC folgte der erste klare SQL-Injection-Versuch. Ab dem 18. Juli kursierten öffentliche Proof-of-Concept-Exploits auf GitHub.
Jake Knott, Principal Security Researcher bei watchTowr, berichtet:
„In den frühen Morgenstunden des Samstags (UTC) war die erfolgreiche Ausnutzung bereits in vollem Gange – zunächst mit öffentlichem Exploit-Code zum Abgreifen gehashter Zugangsdaten, gefolgt von Remote Code Execution, sobald weitere Details öffentlich wurden. Aus unserer Sicht sehen wir eine flächendeckende Betroffenheit über Organisationen jeder Größe und jeder Branche hinweg.“ – Jake Knott, watchTowr
WatchTowr registrierte „zehntausende Ausnutzungsversuche“ in seinen Honeypots. Über 100 Backdoor-Administrator-Accounts wurden nach erfolgreicher Ausnutzung beobachtet. Am 21. Juli 2026 nahm die US-Behörde CISA beide CVEs in ihren Katalog aktiv ausgenutzter Schwachstellen (KEV) auf. Das deutsche BSI stufte die Lücke mit Kritikalität 3 ein und veröffentlichte die Cybersicherheitswarnung 2026-271984-1032.
$wp_version in der Datei wp-includes/version.php ablesen./wp-json/batch/v1 oder ?rest_route=/batch/v1 suchen – insbesondere mit Antwortcodes 207 (Multi-Status) oder 200.wp-content/uploads/ und wp-content/plugins/ nach unbekannten PHP-Dateien suchen. Verdächtige Dateien enthalten oft eval(), base64_decode(), gzuncompress() oder passthru()./wp-json/batch/v1 und ?rest_route=/batch/v1 auf WAF-Ebene, oder installieren Sie ein Plugin, das anonymen REST-API-Zugriff deaktiviert (z. B. „Disable REST API“). Das ist kein Ersatz für das Patchen.wp-config.php) und Hosting-Zugangsdaten ändern, wenn eine Kompromittierung nicht ausgeschlossen werden kann.Ein erfolgreicher wp2shell-Angriff kann zum Zugriff auf personenbezogene Daten führen – etwa Kundendaten, Bestelldaten in WooCommerce-Shops, Kommentare, E-Mail-Adressen oder Kontaktformular-Eingaben. Beobachtete Post-Exploitation-Aktivitäten umfassen ausdrücklich das Abgreifen von Admin-Benutzernamen und E-Mail-Adressen sowie Zugriffsversuche auf die wp-config.php mit Datenbank-Zugangsdaten.
Daraus ergeben sich konkrete Pflichten:
Wichtig für die Haftung: Das Versäumnis, einen verfügbaren Sicherheitspatch zeitnah einzuspielen, kann als Verstoß gegen Art. 32 DSGVO (Sicherheit der Verarbeitung) gewertet werden. Die Bußgelder reichen bis zu 10 Mio. Euro oder 2 Prozent des weltweiten Jahresumsatzes, bei schwerwiegenderen Verstößen bis zu 20 Mio. Euro oder 4 Prozent. Hinzu kommen mögliche Schadensersatzansprüche Betroffener nach Art. 82 DSGVO. Zur Einordnung: In Europa wurden allein 2024 rund 1,2 Milliarden Euro an DSGVO-Bußgeldern verhängt.
wp2shell gehört zu den schwerwiegendsten WordPress-Schwachstellen der letzten Jahre und ist vergleichbar mit historischen CMS-Lücken wie Drupalgeddon. Die Kombination aus CVSS 9.8, unauthentifizierter Ausnutzbarkeit, fehlenden Voraussetzungen, öffentlich verfügbaren Exploits, bestätigter aktiver Ausnutzung und Aufnahme in den CISA-KEV-Katalog ergibt ein maximales Risikoprofil.
Die gute Nachricht: Es gibt Patches, und die Reaktion der Community war schnell. Innerhalb von 24 Stunden nach Veröffentlichung sank der Anteil verwundbarer Organisationen von 60 auf 50 Prozent, der Anteil mit internet-exponiertem Server von 25 auf 10 Prozent. Die schlechte Nachricht: Ein Zehntel aller WordPress-Organisationen war einen Tag später immer noch angreifbar – und Angreifer scannen das Internet rund um die Uhr.
Ryan Dewhurst von KEVIntel bringt das eigentliche Problem auf den Punkt: Websites, bei denen automatische Updates deaktiviert, nicht unterstützt oder fehlgeschlagen sind, bleiben verwundbar. Genau hier liegt die größte Gefahr für viele KMU.
Unsere klare Empfehlung: Prüfen Sie noch heute Ihre WordPress-Version. Ist sie verwundbar und Ihre Website öffentlich erreichbar, behandeln Sie das als Notfall – patchen Sie sofort, prüfen Sie auf Kompromittierung und ändern Sie Ihre Zugangsdaten. Jede Stunde zählt.