wp2shell: CVE-2026-63030 + CVE-2026-60137 verketten sich zu unauthentifizierter RCE in WordPress Core — jetzt in der CISA-KEV

TL;DR — 90 Sekunden

Betroffen?

WordPress 6.8.0–6.8.5 (nur die SQL-Injection, kein RCE-Pfad), WordPress 6.9.0–6.9.4 und 7.0.0–7.0.1 (volle RCE-Kette, beide Bugs vorhanden). 7.1 beta2 enthielt beide Fixes bereits während der Entwicklung.

Risiko?

SQL-Injection (CVE-2026-60137, CVSS 9.1) plus REST-API-Batch-Route-Confusion (CVE-2026-63030, CVSS 7.5) ergeben zusammen unauthentifizierte Remote Code Execution über /wp-json/batch/v1. CISA bestätigt aktive Ausnutzung seit spätestens 18./19.07.2026, KEV-Aufnahme am 21.07.2026.

Sofortmaßnahme?

Sofort auf 6.8.6 / 6.9.5 / 7.0.2 aktualisieren (WordPress hat Zwangs-Auto-Updates für betroffene Installationen aktiviert — prüfen Sie trotzdem manuell, ob Ihre Instanz das Update erhalten hat). Falls sofortiges Patchen nicht möglich ist: /wp-json/batch/v1 und ?rest_route=/batch/v1 am Edge/WAF blockieren.

Empfehlung?

Patchen allein reicht nicht, wenn die Instanz im Zeitfenster 17.–21.07.2026 ungepatcht und erreichbar war — zusätzlich auf Kompromittierungsspuren prüfen (rogue Admin-Accounts, unbekannte Plugin-Verzeichnisse, Webshells).

Kritikalität?

kritisch (Hero-Badge) — CISA-KEV-Eintrag, öffentliche Exploit-Tools mit mehr als zwei Dutzend dokumentierten PoC-Varianten, aktive Ausnutzung in freier Wildbahn.

Was ist das Problem?

„wp2shell“ ist der von Sicherheitsforschern und Exploit-Tooling geprägte Spitzname für eine Kette aus zwei WordPress-Core-Schwachstellen, die zusammen einem nicht authentifizierten Angreifer volle Codeausführung ermöglichen. Beide wurden am 17. Juli 2026 mit den Releases 7.0.2, 6.9.5 und 6.8.6 geschlossen und offiziell als GHSA-ff9f-jf42-662q (CVE-2026-63030, gemeldet von Adam Kues, Assetnote/Searchlight Cyber) und GHSA-fpp7-x2x2-2mjf (CVE-2026-60137, gemeldet von TF1T, dtro und haongo) geführt.

CVE-2026-63030 — Batch-Route-Confusion (CWE-436, Interpretation Conflict)

Der REST-API-Batch-Endpunkt (/wp-json/batch/v1 bzw. ?rest_route=/batch/v1) erlaubt es, mehrere Sub-Requests in einem einzigen HTTP-Aufruf zu bündeln — praktisch für Clients, die viele kleine API-Calls vermeiden wollen. Die Batch-Implementierung führt Validierung und Ausführung der Sub-Requests jedoch in getrennten Schleifen durch. Schlägt wp_parse_url() beim Verarbeiten eines Sub-Request-Pfads fehl, landet der Fehler zwar im Validierungs-Array, nicht aber im Matches-Array, das für die eigentliche Ausführung herangezogen wird. Ergebnis: Ein präparierter Sub-Request kann so an der Route-Auflösung vorbeigeschleust werden, dass die endpoint-spezifische Permission-Prüfung (die anonyme Zugriffe normalerweise blockiert) nicht greift — inklusive der Argument-Schema-Validierung, die author__not_in unter normalen Umständen zwingend in ein Array casten würde.

CVE-2026-60137 — SQL-Injection in WP_Query (CWE-89)

Der Parameter author__not_in von WP_Query geht davon aus, ein Array von Nutzer-IDs zu erhalten. Wird stattdessen ein String übergeben, interpoliert WordPress diesen Wert ungefiltert direkt in das rohe SQL-Statement. Unter normalen Umständen verhindert die REST-API-Argument-Validierung genau das — der Batch-Bug hebelt diese Validierung aber für Sub-Requests aus, sodass ein Angreifer den Parameter als rohen String einschleusen kann.

Die Kette

Zusammengesetzt ergibt das: Ein anonymer Angreifer schickt einen Batch-Request an /wp-json/batch/v1, der einen präparierten Sub-Request enthält. Dieser Sub-Request triggert dank der Route-Confusion eine WP_Query-Ausführung mit String-Payload in author__not_in, liest per SQL-Injection Datenbankinhalte (u. a. Passwort-Hashes, Secrets, WordPress-Options) und wird von dort aus zu Admin-Account-Erstellung und Plugin-Upload eskaliert — klassischer Weg zu einer PHP-Webshell und damit zu Remote Code Execution, ohne dass ein einziges Drittanbieter-Plugin benötigt wird.

Wer ist betroffen?

Betroffen ist damit praktisch jede selbst gehostete oder gemanagte WordPress-Instanz auf 6.9.x oder 7.0.x, die zwischen dem 17. und 21. Juli 2026 (Veröffentlichung des Patches bis KEV-Aufnahme) aus dem Internet erreichbar war und nicht sofort aktualisiert wurde — unabhängig von installierten Plugins oder Themes, da die Kette allein in WordPress Core liegt. Relevanz für diesen Blog: Auch wenn hier primär TYPO3-, Symfony- und Sylius-Stacks betrieben werden, laufen bei Kunden, Partnern und im gemeinsamen Hosting-Umfeld häufig WordPress-Instanzen mit — Marktanteil und Verbreitung von WordPress machen diese Kette zu einem Vorfall mit Breitenwirkung.

Auswirkungen

Der unmittelbare Impact ist vollständige, unauthentifizierte Remote Code Execution auf Betriebssystemebene des Webservers — nicht nur Datenzugriff. Der dokumentierte Ausnutzungspfad läuft über SQL-Injection (Lesezugriff auf beliebige Datenbankinhalte inklusive Passwort-Hashes und Secrets), Erstellung eines Administrator-Accounts und Upload eines bösartigen Plugins, das dann als PHP-Webshell fungiert. Von dort aus ist praktisch alles möglich: Datenexfiltration, Ablage weiterer Backdoors, Nutzung des kompromittierten Servers als Sprungbrett in interne Netze, Krypto-Mining, Spam-Versand oder Ranking-Manipulation via SEO-Spam-Injection. Da keine Plugins oder Themes benötigt werden, ist jede Standardinstallation der betroffenen Versionsreihen ein valides Ziel — der Angriffsfläche liegt vollständig in WordPress Core, nicht in der individuellen Konfiguration einer Seite. Nach VulnCheck-Angaben kursierten bereits am 19. Juli 2026 mehr als zwei Dutzend unterschiedliche PoC-Implementierungen; Patchstack, Hexastrike und WatchTowr berichten unabhängig von beobachteten Exploit-Versuchen über das Wochenende nach der Veröffentlichung.

Mitigation / Sofortmassnahmen

Operativer Entscheidungsblock

• Jetzt handeln, wenn … Sie eine WordPress-Instanz auf 6.9.0–6.9.4 oder 7.0.0–7.0.1 betreiben (oder für Kunden verwalten) und diese öffentlich erreichbar ist.
• Mit Priorität prüfen, wenn … Sie auf 6.8.x sind — kein RCE-Pfad, aber die SQL-Injection allein ist bereits CVSS 9.1 und kann von Plugins/Themes unbeabsichtigt triggerbar sein.
• Nur beobachten, wenn … Sie bereits auf 6.8.6 / 6.9.5 / 7.0.2 oder neuer sind und dies verifiziert haben.

Schritt 1 — Version prüfen und aktualisieren

# aktuelle Version prüfen (WP-CLI)
wp core version

# auf die neueste Patch-Version aktualisieren
wp core update
wp core update-db

# alternativ ohne WP-CLI: WordPress-Adminbereich > Dashboard > Updates
# oder manuell die Core-Dateien gegen 6.8.6 / 6.9.5 / 7.0.2 ersetzen

Schritt 2 — Auto-Update-Status verifizieren

WordPress.org hat laut eigener Ankündigung wegen der Schwere der Lücke Zwangs-Auto-Updates über den Background-Update-Mechanismus für betroffene Versionen aktiviert. Das greift standardmäßig bei Minor-/Security-Releases — nicht jedoch, wenn Auto-Updates explizit deaktiviert wurden (z. B. via wp-config.php-Konstanten, Hosting-Policy oder Management-Tools mit gepinnter Major-Version). Solche Installationen müssen manuell aktualisiert werden.

# Auto-Update-Konfiguration in wp-config.php prüfen
grep -E "WP_AUTO_UPDATE_CORE|AUTOMATIC_UPDATER_DISABLED" wp-config.php

# Cron-Log/Update-Log prüfen, ob der Zwangs-Patch bereits eingespielt wurde
wp core version --extra

Schritt 3 — WAF-Mitigation, falls Patchen nicht sofort möglich ist

# nginx: Batch-Endpunkt blockieren, bis gepatcht ist
location ~* ^/wp-json/batch/v1 { deny all; return 403; }
location ~* "rest_route=/batch/v1" { deny all; return 403; }

# Apache (.htaccess)
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-json/batch/v1 [OR]
RewriteCond %{QUERY_STRING} rest_route=/batch/v1
RewriteRule .* - [F,L]

# ModSecurity-Regel (Beispiel)
SecRule REQUEST_URI "@contains /wp-json/batch/v1" "id:100063030,phase:1,deny,status:403"
SecRule ARGS:rest_route "@contains /batch/v1" "id:100063031,phase:1,deny,status:403"

Alternative: anonymen REST-API-Zugriff generell über ein Security-Plugin einschränken, bis der Core-Patch eingespielt ist. Das Blockieren des Batch-Endpunkts ist eine Notlösung — legitime Clients, die Batch-Requests nutzen, funktionieren dann nicht mehr.

Detection / Prüfung

Hinweis: Die folgenden Indikatoren stammen aus öffentlichen Herstellerveröffentlichungen (Elastic Security Labs, Eye Security, InstaWP). Sie sind Momentaufnahmen von konkret beobachtetem oder von Scanner-Autoren erwartetem Angreiferverhalten — keine festen, dauerhaft gültigen Signaturen. Kein Datensatz enthält bislang öffentlich verifizierte Datei-Hashes oder IP-Listen; falls Sie solche benötigen, prüfen Sie kommerzielle Feeds (z. B. VulnChecks Initial Access Intelligence) direkt.

Access-Logs: Batch-Endpunkt-Zugriffe

# Zugriffe auf den Batch-Endpunkt identifizieren
grep -E "wp-json/batch/v1|rest_route=%2Fbatch%2Fv1|rest_route=/batch/v1" access.log

# POST-Requests mit verschachteltem "requests"-Array im Body sind das eigentliche Angriffsmuster;
# das taucht in Standard-Access-Logs nicht auf (nur die URL, nicht der Body) —
# HTTP 207 (Multi-Status) als Response-Code auf Batch-Requests ist ein unterstützender Indikator,
# aber auch legitime Batch-Nutzung erzeugt 207 — nur Häufungen im fraglichen Zeitfenster sind auffällig
awk '$9 == 207' access.log | grep "batch/v1"

User-Agent-Signaturen

# nach Tooling-Signaturen suchen (laut öffentlichen Scanner-/Exploit-Repos)
grep -iE "wp2shell|rezwp2shell|cve-2026-63030" access.log

Dateisystem: Webshell- und Plugin-Artefakte

# verdächtige Plugin-Verzeichnisse mit Hex-Suffix
find wp-content/plugins -maxdepth 1 -type d -regextype posix-extended -regex ".*-[0-9a-f]{6}$"

# Staging-/Temp-Dateien, die während der Ausnutzung angelegt werden
find wp-content -maxdepth 2 -iname "temp-write-test-*"

# kleine PHP-Dateien mit Command-Interface (?c=) als generischer Webshell-Indikator
grep -rl "\$_GET\['c'\]" wp-content/plugins wp-content/uploads wp-content/cache 2>/dev/null

Datenbank: Rogue-Admin-Accounts

# Admin-Accounts mit auffälligen Login-Mustern oder Domains prüfen
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# nach bekannten Mustern aus öffentlichen Scannern filtern (Login-Präfixe und E-Mail-Domains
# variieren je nach Tooling-Version — als Ausgangspunkt, nicht als vollständige Liste):
# Login-Präfixe: wp2_*, w2s_*, wpsvc_*
# E-Mail-Domains: @wp2shell.*, @shellcode.*, @wordpress-svc.internal, @wordpress-noreply.net

Empfohlene Tools

• InstaWP wp2shell-scan (GitHub) — read-only, bulk-fähiger Scanner speziell für Kompromittierungsartefakte dieser Kette.
• Eye Security — kostenloses WordPress-Plugin und Browser-Extension zur Versions- und Kompromittierungsprüfung („wp2shell defender's guide“).
• Elastic Security Labs — veröffentlichte Detection-Regeln für PHP-Dateierstellung in Plugin-Verzeichnissen, Payload-Ausführung durch den Webserver-Prozess und ungewöhnliche Kindprozesse von apache2/nginx/php-fpm.

Betreiberempfehlung

Wenn Sie kein WordPress betreiben

Der WordPress-Bezug ist für diesen Blog nicht das Kernthema — die Bug-Klasse ist es. CVE-2026-63030 ist im Kern eine Route-Confusion in einem Batch-/Bulk-API-Dispatcher: Ein Endpunkt, der mehrere Sub-Requests bündelt, führt Validierung und Ausführung in getrennten Codepfaden aus, wodurch Sub-Requests an der normalen Permission- und Argument-Prüfung vorbeirutschen können. Dieses Muster ist nicht WordPress-spezifisch. Prüfen Sie in Ihrer eigenen Plattform-Landschaft: Erlaubt Ihre Symfony-/API-Platform-Installation Bulk-Operationen, die einzelne Sub-Requests intern re-dispatchen? Durchläuft dabei jeder Sub-Request denselben Voter-/Security-Stack wie ein regulärer HTTP-Request, oder wird die Security-Prüfung nur einmal für den äußeren Request ausgeführt? Gilt Gleiches für TYPO3-Backend-Ajax-Routen oder eigene Bulk-Endpunkte im Sylius-API-Layer? Überall dort, wo ein Framework „viele Requests in einem“ anbietet, lohnt sich die konkrete Nachfrage, ob Auth-/Permission-Checks pro Sub-Request oder nur pro äußerem Request laufen.

Wenn Sie oder ein Kunde WordPress betreiben

Sofort auf 6.8.6 / 6.9.5 / 7.0.2 aktualisieren, unabhängig davon, ob der Auto-Update-Mechanismus bereits gegriffen hat — manuell verifizieren. War die Instanz zwischen 17. und mindestens 21. Juli 2026 ungepatcht und aus dem Internet erreichbar, gilt sie bis zum Beweis des Gegenteils als potenziell kompromittiert: Führen Sie die oben beschriebenen Detection-Schritte durch (Rogue-Admin-Accounts, verdächtige Plugin-Verzeichnisse, Webshell-Muster), bevor Sie sich allein auf den Patch verlassen. Bei Agenturen und Hostern, die WordPress für Kunden verwalten: Dieses Zeitfenster betrifft potenziell den gesamten Kundenbestand auf 6.9.x/7.0.x gleichzeitig — ein Massenscan aller verwalteten Instanzen ist gerechtfertigt.

Entscheidungsblock

Heute handeln, wenn: eigene oder Kunden-WordPress-Instanz auf 6.9.x/7.0.x, öffentlich erreichbar, noch nicht verifiziert gepatcht. Beobachten, wenn: bereits auf 6.8.6/6.9.5/7.0.2 verifiziert, oder kein WordPress im eigenen oder betreuten Bestand — dann bleibt die generelle Lehre zu Batch-API-Auth-Bypass relevant für die eigene Architektur-Review.

Fazit

wp2shell ist ein Lehrbuchbeispiel dafür, wie zwei für sich genommen unterschiedlich schwere Bugs — eine kritische SQL-Injection und eine „nur“ hoch eingestufte Route-Confusion — zusammen zu vollständiger, unauthentifizierter Remote Code Execution eskalieren. Die vermeintliche CVSS-Diskrepanz (9.1 versus 7.5) löst sich bei genauem Hinsehen auf: Jede CVE wird isoliert nach ihrem eigenen, direkten Impact bewertet, nicht nach dem Schaden der gesamten Kette — WordPress selbst stuft die SQL-Injection als kritisch und die Route-Confusion als hoch ein, was exakt den NVD-Werten entspricht. Bemerkenswert ist vor allem das Tempo der Eskalation: von „öffentlicher PoC, kein bestätigter Missbrauch“ am 17./18. Juli zu einer CISA-KEV-Aufnahme mit dem Vermerk aktiver Ausnutzung am 21. Juli — vier Tage. Wer WordPress betreibt oder betreut, sollte längst gepatcht und auf Kompromittierung geprüft haben. Wer es nicht tut, sollte trotzdem einen Blick auf die eigene API-Architektur werfen: überall dort, wo Requests gebündelt werden, lohnt sich die Frage, ob jeder Sub-Request wirklich denselben Auth-Check durchläuft wie ein eigenständiger Request.

Quellen

• WordPress.org — WordPress 7.0.2 Release (17.07.2026, offizielle Advisory, GHSA-ff9f-jf42-662q / GHSA-fpp7-x2x2-2mjf, Bestätigung der Zwangs-Auto-Updates)
• NVD — CVE-2026-63030 (CVSS 3.1: 7.5 HIGH, CWE-436)
• NVD — CVE-2026-60137 (CVSS 3.1: 9.1 CRITICAL, CWE-89)
• The Hacker News — New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code (17./18.07.2026)
• CISA — CISA Adds Four Known Exploited Vulnerabilities to Catalog (21.07.2026)
• VulnCheck — WP2Shell Vulnerabilities: CVE-2026-60137 and CVE-2026-63030 (PoC-Zählung, Exploit-Reife)
• SecurityWeek — WP2Shell WordPress Vulnerabilities Exploited in the Wild
• Eye Security — wp2shell: incident response guide (Detection-Indikatoren, Rogue-Admin-Muster)
• Elastic Security Labs — wp2shell: detecting WordPress pre-auth RCE end-to-end (Detection-Regeln, IOCs)
• InstaWP — wp2shell-scan (GitHub, Kompromittierungs-Scanner)
• Horizon3.ai — CVE-2026-60137 & CVE-2026-63030 | WordPress wp2shell (technische Details)