Ein Angreifer braucht keinen Account. Er braucht nur Ihre URL.
500 Millionen Websites laufen auf WordPress. Seit dem 17. Juli 2026 ist ein erheblicher Teil davon mit einem einzigen HTTP-Request übernehmbar — ohne Benutzerkonto, ohne installiertes Plugin, ohne dass irgendjemand im Unternehmen einen Fehler gemacht hätte. Die Schwachstelle trägt den Namen wp2shell, und sie steckt nicht in einem verwaisten Slider-Plugin, sondern im WordPress Core selbst.
7,5 auf der CVSS-Skala klingt nach „hoch, aber nicht katastrophal“. Diese Zahl täuscht. Sie beschreibt die technische Bewertung, nicht die reale: Wenn eine Lücke anonym, ohne Vorbedingungen und gegen eine Standardinstallation ausnutzbar ist, gehört sie in die Kategorie, die Angreifer mit „druckbares Geld“ bezeichnen würden.
Konkret handelt es sich um zwei verkettete Schwachstellen: CVE-2026-63030, eine Route-Confusion im REST-API-Batch-Endpoint, und CVE-2026-60137, eine SQL-Injection im Query-System von WordPress. Einzeln unangenehm, zusammen eine unauthentifizierte Remote-Code-Execution — der Angreifer führt eigenen Code im Kontext des Webservers aus. Betroffen sind die Versionen 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1; die Releases 6.8.0 bis 6.8.5 tragen zumindest die SQL-Injection-Komponente in sich.
Warum gerade diese Lücke ein Lehrstück ist
Der eigentliche Clou der Geschichte steckt im Entstehungsweg. Entdeckt hat die Kette Adam Kues von Searchlight Cyber — nach eigener Darstellung mit Hilfe eines KI-Modells, für etwa 25 Dollar an Rechenkosten. Zum Vergleich: Exploit-Broker zahlen für eine WordPress-RCE dieser Güte bis zu 500.000 Dollar. Diese Kostenrechnung sollte jeder Verantwortliche im E-Commerce einmal auf sich wirken lassen.
Was hier auf der Verteidigerseite funktioniert hat, funktioniert auf der Angreiferseite genauso. Die Einstiegshürde für das Finden kritischer Lücken in weit verbreiteter Software fällt Richtung null. Die Zeitspanne zwischen Veröffentlichung eines Patches und aktiver Ausnutzung schrumpft entsprechend — bei wp2shell waren es keine 48 Stunden. Der Patch kam am Freitag, den 17. Juli, bis zum 19. Juli kursierten öffentliche Proof-of-Concept-Exploits und die ersten echten Angriffe waren dokumentiert.
Die Angriffe haben keine Vorbedingungen und funktionieren gegen eine anonyme Standardinstallation von WordPress — ganz ohne Plugins.
Dieses Zitat von Searchlight Cyber ist der Satz, der wp2shell von den Dutzenden Plugin-Lücken unterscheidet, die wöchentlich durch die Security-Newsletter rauschen. Die übliche Abwehrstrategie deutscher Agenturen — schlanke Installation, wenige Erweiterungen, alles gepflegt — greift hier nicht.
WordPress patcht erstmals per Zwangs-Update — reicht das?
Die kurze Antwort: nein, nicht blind vertrauen. Das WordPress.org-Team hat wegen der Schwere der Lücke erzwungene Auto-Updates über das Update-System aktiviert. Wer auf Version 6.9.5, 7.0.2 oder 6.8.6 sitzt, ist gegen die bekannte Angriffskette geschützt. Aber Auto-Updates scheitern in der Praxis an banalen Dingen: Dateirechte, deaktivierte Cronjobs, Deployment-Pipelines, die den Core bei jedem Deploy zurücksetzen, oder Hostings, bei denen das Update-System bewusst ausgeschaltet wurde.
Genau hier liegt die Falle für Agenturen und Shopbetreiber. Wer im Dashboard „WordPress 7.0.2“ liest, darf sich nicht darauf verlassen, dass das Update auch wirklich vollständig durchgelaufen ist. Searchlight Cyber stellt unter wp2shell.com einen öffentlichen Checker bereit, der die Installation direkt testet, statt nur den Versionsstring abzufragen. Cloudflare hat parallel Regeln ausgerollt, die Exploit-Versuche auf Netzwerkebene erkennen und blockieren — für Kunden des Dienstes ist das eine zweite Verteidigungslinie, keine Alternative zum Patch.
Was bedeutet wp2shell für WooCommerce-Shops im DACH-Markt?
Für einen Shop ist eine übernommene WordPress-Instanz kein IT-Problem, sondern ein Betriebs- und Rechtsproblem. Wer Code auf dem Server ausführen kann, kann Zahlungsdaten abgreifen, Checkout-Seiten manipulieren, Kundendatenbanken exfiltrieren oder die Installation als Sprungbrett für Folgeangriffe nutzen. Bei WooCommerce liegen Bestellungen, Adressen und je nach Setup Zahlungstoken in genau dieser Datenbank.
Die deutsche Perspektive verschärft das zusätzlich. Ein Datenabfluss mit personenbezogenen Kundendaten löst die Meldepflicht nach Artikel 33 DSGVO aus: 72 Stunden Zeit für die Meldung an die Aufsichtsbehörde, ab Kenntnis des Vorfalls. Wer die Lücke seit Tagen hätte schließen können, wird sich die Frage gefallen lassen müssen, warum ein als kritisch kommunizierter Notfall-Patch nicht eingespielt war. Das ist keine theoretische Debatte — Datenschutzbehörden fragen bei Verfahren regelmäßig nach dem Patch-Management, und „das Auto-Update hat wohl nicht funktioniert“ ist kein Verteidigungsargument.
- Version prüfen, aber nicht nur im Dashboard: den Checker auf wp2shell.com gegen die Live-Installation laufen lassen.
- Bei Agenturen und Freelancern: dokumentieren, wann welcher Kunden-Shop auf 6.9.5/7.0.2 gehoben wurde — diese Nachweise entscheiden später über Haftungsfragen.
- Logs der letzten Tage auf verdächtige REST-API-Requests prüfen; wer ungepatcht war, sollte einen Kompromittierungs-Check machen, statt nur zu patchen.
- Deployment-Prozesse kontrollieren: Setzt die eigene Pipeline den Core bei jedem Release auf eine alte Version zurück?
Besonders heikel ist die Lage für Agenturen mit Maintenance-Verträgen. Wer für Kunden „Wartung und Sicherheit“ verkauft und jetzt einen kompromittierten Shop abliefert, hat ein Vertrags- und Reputationsproblem. Die gute Nachricht: Die betroffenen Versionen 6.9 und 7.0 sind jung. Shops, die konservativ auf älteren Zweigen fahren, sind vom vollen Exploit-Chain nicht betroffen — allerdings tragen die 6.8er-Versionen vor 6.8.6 die SQL-Injection in sich, auch das gehört gepatcht.
Wie sollten Shopbetreiber jetzt priorisieren?
Priorität eins ist Verifizierung, nicht Aktionismus. Erst feststellen, welche Installationen betroffen sind und ob das Zwangs-Update tatsächlich gegriffen hat, dann patchen, dann auf Kompromittierung prüfen. Diese Reihenfolge klingt selbstverständlich und wird in der Praxis ständig falschherum gemacht: gepatcht, Haken dran, weiter im Tagesgeschäft.
48 Stunden reichten den Angreifern von der Veröffentlichung bis zu den ersten dokumentierten Angriffen. Wer seinen Shop eine Woche nach dem Patch noch nicht verifiziert hat, operiert im Zeitfenster, in dem Massen-Scans längst jede verwundbare Instanz katalogisiert haben. Der Markt für kompromittierte WordPress-Installationen funktioniert automatisiert — da sitzt niemand, der gezielt Ihren Shop angreift. Ein Skript reicht.
Wer zusätzliche Zeit braucht — etwa weil ein komplexes Setup das Update erschwert — hat kurzfristig drei Hebel: einen Web-Application-Firewall-Anbieter mit wp2shell-Regeln davor schalten, den REST-API-Batch-Endpoint auf Netzwerkebene einschränken und die Installation hinter Basic Auth oder IP-Allowlisting verstecken. Alles Übergangslösungen. Der Patch bleibt Pflicht.
Die unbequeme Lehre aus 25 Dollar
wp2shell wird nicht die letzte Core-Lücke dieser Art sein — im Gegenteil. Wenn KI-gestützte Analyse für 25 Dollar findet, wofür Broker früher eine halbe Million gezahlt haben, steigt die Fundrate kritischer Lücken in der Software, auf der der halbe E-Commerce läuft. Die Reaktionszeiten, die bislang als ausreichend galten, sind es dann nicht mehr.
Für Shopbetreiber heißt das konkret: Patch-Prozesse, die „innerhalb von zwei Wochen“ vorsehen, gehören für kritische Core-Lücken auf „innerhalb von 24 Stunden, inklusive Verifikation“ verschärft. Und wer seinem Dienstleister oder seiner Agentur bisher nicht die Frage gestellt hat, wie schnell im Notfall gepatcht und nachgewiesen wird, sollte dieses Gespräch diese Woche führen — nicht erst, wenn die nächste Kette einen Namen bekommt und Ihre Kundendatenbank im Angebot ist.