Rund 500 Millionen Websites laufen mit WordPress – und seit dem Wochenende steht fest: Eine Schwachstellen-Kette namens wp2shell wird aktiv ausgenutzt. Das WordPress-Security-Team hat am Freitag, 17. Juli 2026, Notfall-Updates veröffentlicht und erstmals seit Längerem Zwangsupdates über das Auto-Update-System aktiviert. Für Shopbetreiber, deren WooCommerce-Installation auf WordPress 6.9 oder 7.0 läuft, ist das kein Routine-Patch, sondern ein Fall für die Prioritätenliste ganz oben.
Was steckt hinter wp2shell?
Hinter dem Namen verbergen sich zwei offiziell als CVE-2026-60137 und CVE-2026-63030 geführte Lücken im WordPress-Core: eine SQL-Injection mit hohem Schweregrad und eine Schwachstelle im REST-API-Batch-Endpunkt, die entfernte Code-Ausführung ermöglicht. Entdeckt und verantwortungsvoll gemeldet hat die Kette Adam Kues von Searchlight Cyber (vormals Assetnote). Seine Einschätzung lässt keinen Interpretationsspielraum: Der Angriff braucht keine Vorbedingungen, keinen Account, keine Plugins – eine Standardinstallation genügt.
„The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins.“
Betroffen sind WordPress 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1. Die Patches tragen die Versionsnummern 6.9.5 und 7.0.2. Der 6.8er-Zweig ist nur von der SQL-Injection betroffen und wird mit 6.8.6 abgesichert; wer die Beta 7.1 einsetzt, braucht Beta 2. Versionen vor 6.8 gelten nach offizieller Einschätzung als nicht verwundbar.
Warum trifft das Online-Shops besonders hart?
Ein Angreifer, der beliebigen Code auf dem Server ausführt, kontrolliert faktisch den gesamten Shop: Kundendaten, Bestellungen, Zahlungs-Schnittstellen. Die Sicherheitsfirma Patchstack hat nach eigenen Angaben bereits reale Angriffe beobachtet, Proof-of-Concept-Code kursiert. Dass Angreifer kompromittierte Shops gern mit Kreditkarten-Skimmern im Checkout oder mit Spam-Weiterleitungen versehen, zeigt die Praxis vergangener Massenangriffe – ein Szenario, das bei einem Shopsystem mit Zahlungsdaten existenzielle Folgen hat, von DSGVO-Meldepflichten bis zum Vertrauensverlust.
WordPress reagiert ungewöhnlich scharf: Das Zwangsupdate über das Auto-Update-System soll betroffene Installationen ohne Zutun der Betreiber auf die gepatchte Version heben. Cloudflare hat parallel WAF-Regeln ausgerollt, die Exploit-Versuche erkennen und Kunden schützen, deren Instanzen noch nicht aktualisiert sind. Trotzdem gilt: Auto-Updates können scheitern, ohne dass es im Frontend sichtbar wird. Plugins wie Wordfence oder Patchstack-Monitoring liefern zusätzliche Erkennung, ersetzen aber den Core-Patch nicht.
Was müssen Shopbetreiber jetzt konkret tun?
Erster Schritt ist die Versionsprüfung im Dashboard oder auf Kommandozeile – nicht die Annahme, das Zwangsupdate habe schon gegriffen. Wer wp2shell unsicher einschätzt, kann über den öffentlichen Checker wp2shell.com testen, ob die eigene Instanz verwundbar ist. Steht dort 6.9.5 oder 7.0.2, ist der akute Teil erledigt.
Danach folgt die unangenehmere Frage: War der Shop zwischen Disclosure und Patch verwundbar? Ein Blick in die Access-Logs auf verdächtige HTTP-Requests gegen REST-API-Endpunkte in diesem Zeitfenster ist Pflicht, keine Kür. Wer Indikatoren findet, sollte die Installation als potenziell kompromittiert behandeln – Passwörter rotieren, Integrität der Core-Dateien prüfen, Backups einspielen, die nachweislich außerhalb des Servers lagern.
Für Händler mit Agentur- oder Hosting-Vertrag heißt das: heute nachfragen, nicht nächste Woche. Managed-Hoster haben größtenteils bereits gepatcht, doch Staging-Umgebungen und ältere Entwicklungsinstanzen werden regelmäßig vergessen – und sind genauso erreichbar wie das Produktivsystem. wp2shell wird nicht die letzte Core-Lücke bleiben; die Shops, die jetzt sauber patchen und prüfen, sind auch für die nächste besser aufgestellt.