wp2shell WordPress RCE: Jetzt patchen

wp2shell WordPress RCE ist jetzt eine Zwei-CVE-Kette im CISA-Known-Exploited-Vulnerabilities-Katalog — und sie lässt einen vollständig nicht authentifizierten Angreifer Code auf einer Standard-WordPress-Installation ausführen, ganz ohne Plugins. Wer selbst gehostetes WordPress betreibt und noch nicht bestätigt hat, dass das Auto-Update vom 17. Juli angekommen ist, sollte das heute prüfen.

Was ist passiert

wp2shell WordPress RCE kombiniert zwei Schwachstellen im WordPress-Kern: CVE-2026-63030, einen Logikfehler im REST-API-Batch-Prozessor, und CVE-2026-60137, eine SQL-Injection im Parameter author__not_in des Posts-Endpunkts. WordPress validiert und führt Batch-Sub-Requests in getrennten Schleifen aus; schlägt die URL-Auflösung eines fehlerhaften Sub-Request-Pfads fehl, landet der Fehler im Validierungs-Array, aber nicht im Matches-Array. Diese Desynchronisierung lässt eine präparierte Batch-Anfrage einen Handler erreichen, der die Validierung eigentlich nie hätte passieren dürfen, und die verkettete SQL-Injection macht daraus vollständige Remote Code Execution — ohne Login, ohne Plugin.

Betroffen sind die WordPress-Kernversionen 6.9.0–6.9.4 und 7.0.0–7.0.1, behoben in 6.9.5 und 7.0.2 am 17. Juli. WordPress verteilte den Fix noch am selben Tag über das erzwungene Auto-Update-System. Trotzdem tauchten innerhalb weniger Tage mehrere öffentliche Proof-of-Concept-Exploits auf — inklusive eines veröffentlichten Exploit-Toolkits —, und beide CVEs, CVE-2026-63030 und CVE-2026-60137, wurden am 21. Juli mit bestätigter aktiver Ausnutzung in den CISA-KEV-Katalog aufgenommen, darunter Credential-Exfiltration und Web-Shell-Deployment auf Seiten ohne das Update.

Warum das wichtig ist

WordPress betreibt einen überproportional großen Anteil kleiner Unternehmenswebsites im DACH-Raum, und ein Großteil dieser Installationen ist selbst gehostet und unverwaltet — niemand kontrolliert, ob das erzwungene Auto-Update tatsächlich angekommen ist. Eine Pre-Auth-RCE-Kette im WordPress-Kern selbst statt in einem Plugin ist selten und schwerwiegend: Sie betrifft jede Seite mit betroffener Version, unabhängig davon, welche Plugins oder Themes installiert sind. Für jede Organisation, die WordPress für eine Marketing-Seite, ein Kundenportal oder einen Onlineshop nutzt, ist das eine Prüfung für heute, kein Punkt für die nächste Quartalsreview.

Was Sie jetzt tun sollten

1. Bestätigen Sie, dass Ihre WordPress-Kernversion 6.9.5, 7.0.2 oder neuer ist — gehen Sie nicht davon aus, dass das erzwungene Auto-Update erfolgreich war; prüfen Sie es manuell im Dashboard oder per wp-cli (wp core version).
2. Wenn Sie mehrere WordPress-Seiten betreuen (Agenturen, Hosting-Reseller), skripten Sie eine Versionsprüfung über Ihr gesamtes Portfolio noch heute, statt Seite für Seite vorzugehen.
3. Wo sofortiges Patchen nicht möglich ist, blockieren oder begrenzen Sie Anfragen an /wp-json/batch/v1 auf der WAF- oder Reverse-Proxy-Ebene als Übergangsmaßnahme.
4. Prüfen Sie kürzlich angelegte Admin-Nutzer, unerwartete Plugin- oder Theme-Dateiänderungen und Webserver-Logs auf POST-Anfragen an den Batch-REST-Endpunkt seit dem 17. Juli.

DIESEC Einschätzung

Das ist dasselbe Muster, das DIESEC schon bei Ghost CMS und Drupal in diesem Jahr markiert hat: Das größte Risiko einer einzelnen Plattform liegt nicht in der Raffinesse des Exploits, sondern in der schieren Zahl unverwalteter, selbst gehosteter Installationen, die den Patch nie erreichen. Das erzwungene Auto-Update von wp2shell ist eine gute Reaktion des Herstellers — aber „erzwungen“ funktioniert nur, wenn der Update-Mechanismus auf dem jeweiligen Server überhaupt noch funktioniert.

Nicht sicher, ob wirklich jede WordPress-Seite Ihrer Organisation gepatcht ist? Kontaktieren Sie DIESEC für eine schnelle Expositionsprüfung Ihrer WordPress-Flotte und Patch-Verifizierung.

Quellen: The Hacker News | BleepingComputer
Veröffentlicht: 2026-07-24 | Kategorie: Tägliche News | ~4 Min. Lesezeit