CVE-2026-63030 wp2shell: WordPress Core Pre-Auth RCE ausgenutzt

Diese Woche in unserer InSEKurity of the Week-Serie: wp2shell, eine Pre-Authentication-Remote-Code-Execution-Kette in WordPress Core selbst — kein Plugin, kein Theme, keine exotische Konfiguration. Zwei getrennt geführte Schwachstellen ergeben zusammen einen Angriff: CVE-2026-63030, eine Route-Confusion im REST-API-Batch-Endpunkt (/wp-json/batch/v1), und CVE-2026-60137, eine SQL-Injection im Parameter author__not_in von WP_Query, dem zentralen Datenbank-Query-Builder von WordPress. Für sich genommen ist jede von beiden begrenzt — die SQL-Injection tritt normalerweise nur auf, wenn ein Plugin ungeprüfte Eingaben in diesen Parameter durchreicht, und die Batch-Confusion allein bringt wenig. Verkettet erlauben sie einem anonymen Angreifer aus dem Internet Codeausführung auf einer Standard-WordPress-Installation ohne jedes Plugin. WordPress hat am 17. Juli 2026 Notfall-Patches veröffentlicht; Wordfence beobachtete noch am selben Tag die ersten Scans und dreizehn Minuten später die ersten SQL-Injection-Versuche. Bis zum 21. Juli standen beide CVEs im Known-Exploited-Vulnerabilities-Katalog der CISA — die ersten Einträge zu WordPress Core, die der Katalog jemals geführt hat. Da WordPress rund 41,5 % aller Websites und knapp 60 % aller CMS-basierten Websites antreibt, ist dies eine der größten Angriffsflächen, die eine einzelne Schwachstellenklasse seit Jahren erreicht hat. Wenn Sie WordPress betreiben, zählt gerade nur eine Frage: Welche Versionsnummer meldet Ihre Site?

🚨 Zusammenfassung

CVE-IDs: CVE-2026-63030 (REST-API-Batch-Route-Confusion — der unauthentifizierte Einstiegspunkt) und CVE-2026-60137 (SQL-Injection — die Payload-Auslieferung). Gemeinsam öffentlich bekannt als wp2shell.
CVSS-3.1-Score: CVE-2026-63030 — 9.8 Critical laut WPScan (der CNA), AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H; CISA-ADP bewertet dieselbe CVE mit 7.5 High. CVE-2026-60137 — 5.9 Medium laut WPScan (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N), aber 9.1 Critical laut CISA-ADP. Entscheidend ist die Kette: unauthentifizierte RCE, effektiv 9.8.
CWE: CWE-436 (Interpretation Conflict) für CVE-2026-63030; CWE-89 (SQL Injection) für CVE-2026-60137
Betroffene Software: WordPress Core — vollständige RCE-Kette auf 6.9.0–6.9.4 und 7.0.0–7.0.1; ausschließlich SQL-Injection auf 6.8.0–6.8.5. Versionen vor 6.8 sind nicht betroffen.
Angriffsvektor: Netzwerk — ein einzelnes HTTP-POST an den REST-API-Batch-Endpunkt, der seit WordPress 5.6 standardmäßig aktiviert ausgeliefert wird
Authentifizierung erforderlich: Keine. Keine Benutzerinteraktion, keine Plugins, keine besondere Konfiguration.
Auswirkung: Unauthentifizierte Remote Code Execution — Webshell-Deployment, Anlegen betrügerischer Administratorkonten, vollständige Übernahme der Site und häufig des gesamten Webservers
Patch-Status: ✅ Verfügbar — 7.0.2, 6.9.5, 6.8.6 und 7.1 beta2, alle veröffentlicht am 17. Juli 2026. WordPress.org hat erzwungene automatische Hintergrund-Sicherheitsupdates für betroffene Installationen aktiviert.
Veröffentlicht: 17. Juli 2026 (WordPress-Sicherheitsrelease, GitHub Security Advisories GHSA-ff9f-jf42-662q und GHSA-fpp7-x2x2-2mjf)
Ausnutzungsstatus: 🔴 Aktiv ausgenutzt. Die Scans begannen am Tag der Veröffentlichung; öffentliche PoCs kursierten innerhalb weniger Tage; das SANS ISC hat aufgezeichnete Payloads aus freier Wildbahn veröffentlicht.
CISA KEV: ✅ Gelistet — CVE-2026-63030 aufgenommen am 21. Juli 2026 (Frist für US-Bundesbehörden 24. Juli 2026), CVE-2026-60137 aufgenommen mit Frist 4. August 2026, gemäß BOD 26-04

🖥️ Was ist WordPress Core?

WordPress ist das weltweit am weitesten verbreitete Content-Management-System. „WordPress Core” bezeichnet die Basisplattform selbst — die PHP-Anwendung, die man von wordpress.org herunterlädt — im Unterschied zu den rund 60.000 Plugins und Tausenden Themes, die darauf aufbauen. Genau diese Unterscheidung ist hier die ganze Geschichte. Die überwältigende Mehrheit der WordPress-CVEs steckt in Drittanbieter-Plugins, weshalb der Standardratschlag („Prüfen Sie Ihre Plugins, entfernen Sie, was Sie nicht nutzen”) normalerweise funktioniert. wp2shell ist anders: Der verwundbare Code liegt in Core, sodass eine gehärtete, minimale, plugin-freie Installation genauso ausnutzbar ist wie eine überladene.

Die konkret betroffene Komponente ist die REST API, die WordPress seit Version 4.7 standardmäßig aktiviert ausliefert, und deren Batch-Endpunkt (/wp-json/batch/v1), hinzugefügt in Version 5.6. Der Batch-Endpunkt existiert, damit ein Client mehrere API-Aufrufe in einer einzigen HTTP-Anfrage bündeln kann — nützlich für den Block-Editor, Headless-Frontends und mobile Apps, die sonst ein Dutzend Roundtrips bräuchten. Er ist per Design anonym erreichbar, weil zahlreiche legitime REST-Routen öffentlich sind.

Die schiere Größenordnung macht aus einem Core-Bug ein internetweites Ereignis. Stand Juli 2026 beziffert W3Techs WordPress auf rund 41,5 % aller Websites und 59,9 % aller Sites mit bekanntem CMS — mehr als alle anderen CMS zusammen. Schätzungen zur absoluten Zahl der WordPress-Sites gehen in die Hunderte Millionen. Eine Pre-Authentication-RCE in Core ist damit kein Herstellerproblem einer einzelnen Branche, sondern ein Problem für Unternehmenswebsites, Onlineshops, Behördenportale, Universitätsfachbereiche und den langen Schwanz kleiner Firmenseiten, in die sich seit drei Jahren niemand mehr eingeloggt hat.

Typische Anwendungsfälle

Unternehmenswebsites und Marketing-Präsenz: das öffentliche Gesicht der Organisation, häufig direkt neben anderer Infrastruktur gehostet.
E-Commerce: WooCommerce und vergleichbare Stacks verarbeiten Zahlungsflüsse und personenbezogene Kundendaten.
Publishing und Medien: reichweitenstarke Redaktionsseiten mit vielen Autorenkonten.
Headless CMS / API-Backend: die REST API liefert Inhalte an mobile Apps und JavaScript-Frontends — genau der Anwendungsfall, für den der Batch-Endpunkt gebaut wurde.
Intranets und Mitgliederportale: interne oder zugangsbeschränkte Seiten, die davon ausgehen, dass Authentifizierung sie schützt.

🔍 Technische Analyse

Schwachstellenbeschreibung

wp2shell ist eine Kette aus zwei Schwachstellen, und zu verstehen, warum keine der beiden allein ausreicht, ist der Schlüssel zum Verständnis des Fehlers.

CVE-2026-60137 ist eine SQL-Injection in WP_Query, der Klasse, durch die nahezu jede WordPress-Abfrage läuft. Die Query-Variable author__not_in soll ein Array von Benutzer-IDs entgegennehmen, die ausgeschlossen werden sollen. Der Sanitisierungscode greift jedoch nur, wenn der Wert tatsächlich ein Array ist — die Implementierung ist durch eine Prüfung abgesichert, die if ( is_array( $query_vars['author__not_in'] ) ) entspricht. Erreicht stattdessen ein skalarer String diesen Parameter, umgeht er die Bereinigung vollständig und landet im generierten SQL. Unter normalen Bedingungen ist das ein „mittlerer” Bug: Die Schema-Validierung der REST API erzwingt den Array-Typ, sodass nur ein Plugin oder Theme, das rohe Benutzereingaben unachtsam an WP_Query durchreicht, ihn auslösen könnte. Deshalb bewertete WPScan ihn mit 5.9.

CVE-2026-63030 ist das, was diese Leitplanke entfernt. WP_REST_Server::serve_batch_request_v1() verarbeitet einen Batch in zwei getrennten Durchläufen: Zuerst validiert die Methode jede Teilanfrage, anschließend führt sie sie aus. Dabei verfolgt sie die Teilanfragen über parallele Arrays — die Anfragen selbst, ihre Route-$matches (der aufgelöste Handler samt Parametern) und die $validation-Ergebnisse — und verlässt sich darauf, dass diese Arrays indexgleich bleiben. Schlägt das Parsen eines Teilanfrage-Pfads fehl (wp_parse_url() liefert einen Fehler), wird der Fehler zwar an das Validation-Array angehängt, aber kein entsprechender Platzhalter in das Matches-Array eingefügt. Ab diesem Punkt sind die Arrays um eins verschoben, und jede nachfolgende Teilanfrage wird unter dem Handler einer anderen Teilanfrage ausgeführt.

Diese Desynchronisation ist das Exploit-Primitiv. Ein Angreifer fügt gezielt eine fehlerhafte Teilanfrage ein, um den Index zu verschieben, und seine eigentliche Payload läuft dann gegen einen Handler, dessen Schema-Validierung zu einer anderen Route gehört. Die Typbeschränkung, die author_exclude (den REST-Parameter, der auf author__not_in abgebildet wird) zu einem Array gezwungen hätte, wird nicht mehr angewendet. Ein skalarer, angreiferkontrollierter String erreicht WP_Query ungefiltert — und aus der „mittleren” SQL-Injection wird eine unauthentifizierte SQL-Injection auf einer Standardinstallation.

Ursachenanalyse (Root Cause)

Typabhängige Sanitisierung (CWE-89): WP_Query bereinigt author__not_in nur, wenn der Wert bereits ein Array ist. Ein skalarer String wird unangetastet durchgereicht statt zurückgewiesen oder konvertiert. Eine Bereinigung, die von der Form der Eingabe abhängt, ist eine Bereinigung, um die ein Angreifer sich herumformen kann.
Parallele Arrays als impliziter Vertrag (CWE-436): serve_batch_request_v1() hält Anfragedaten in mehreren getrennten Arrays und nimmt an, dass deren Indizes korrespondieren. Nichts in der Codestruktur erzwingt diese Annahme — sie wird nur dadurch aufrechterhalten, dass jeder Codepfad daran denkt, in alle Arrays zu schreiben.
Fehlerpfad, der ein Array überspringt: Der Fehlerzweig für einen nicht parsbaren Teilanfrage-Pfad schreibt in $validation, ohne einen Platzhalter in $matches zu ergänzen. Ein einziger fehlender Push in einer Fehlerbehandlung ist die vollständige Ursache der Route-Confusion.
Validierung entkoppelt von der Ausführung: Da die Validierung in einer Schleife und die Ausführung in einer anderen stattfindet, wird die Entscheidung „diese Eingabe wurde validiert” an einer anderen Stelle getroffen als dort, wo die Eingabe verwendet wird. Die Desynchronisation lässt eine Anfrage das Validierungsurteil einer anderen tragen.
Anonyme Erreichbarkeit per Design: Der Batch-Endpunkt akzeptiert unauthentifizierte Anfragen, weil viele REST-Routen öffentlich sind. Für sich genommen ist das vertretbar, bedeutet aber, dass die Routing-Schicht direkt anonymen Angreifereingaben ausgesetzt ist.
Standardmäßig aktive Angriffsfläche: Die REST API (seit 4.7) und der Batch-Endpunkt (seit 5.6) sind ab Werk aktiviert, sodass der verwundbare Codepfad praktisch auf jeder modernen Installation vorhanden ist.

Angriffsvektor

Das folgende Diagramm zeigt die Struktur der Kette für Verteidiger. Es ist eine konzeptionelle Datenflussbeschreibung, kein funktionsfähiger Exploit.

# Illustratives Angriffsdiagramm -- KEIN funktionsfaehiger Exploit. Nur fuer Verteidiger.

Anonymer Angreifer (keine Zugangsdaten, kein Konto)
      |
      | (1) POST einer Batch-Anfrage an /wp-json/batch/v1 (oder ?rest_route=/batch/v1)
      |     mit mehreren Teilanfragen. Eine Teilanfrage traegt einen absichtlich
      |     fehlerhaften Pfad, sodass wp_parse_url() daran scheitert.
      v
WP_REST_Server::serve_batch_request_v1()
      |
      |     Validierungsschleife: Fehler wird in $validation geschrieben,
      |     aber KEIN Platzhalter in $matches  ->  Arrays sind um eins verschoben
      v
Ausfuehrungsschleife startet jede Teilanfrage unter dem FALSCHEN Handler
      |
      | (2) CVE-2026-60137: Der author_exclude-Wert des Angreifers wird nicht
      |     mehr per Schema als Array geprueft. Ein skalarer String erreicht WP_Query.
      v
Unbereinigter String wird in die SQL-Abfrage konkateniert  ->  SQL-Injection
      |
      | (3) Eskalation vom Datenbank-Lesezugriff zur Codeausfuehrung
      |     (siehe "Von der SQL-Injection zur Codeausfuehrung")
      v
Webshell auf der Festplatte und/oder betruegerisches Admin-Konto  ->  Uebernahme

Von der SQL-Injection zur Codeausführung

Zwei unterschiedliche Eskalationswege sind dokumentiert, und Verteidiger sollten nach beiden suchen.

Weg A — die Kette des Forschers (Object Poisoning). Die ursprüngliche Forschung von Searchlight Cyber, wie sie von Picus Security öffentlich analysiert wurde, kommt gänzlich ohne Dateischreibzugriff über MySQL aus. Stattdessen wird die Injection genutzt, um die Felder eines gecachten WP_Post-Objekts zu kontrollieren; ein oEmbed-Schreibpfad zwingt das vergiftete Objekt zurück in die Datenbank; ein Customizer-Changeset-Save läuft kurzzeitig in einem erhöhten Kontext, und ein verschachtelter REST-Loader-Save bewertet eine zuvor abgelehnte Benutzeranlage-Anfrage erneut — als Administrator. Ergebnis ist ein angreiferkontrolliertes Administratorkonto — und danach ist die Installation eines Plugins eine unterstützte Funktion, aus der Codeausführung trivial folgt. Dieser Weg benötigt kein FILE-Privileg des Datenbankbenutzers.

Weg B — was Angreifer tatsächlich abgefeuert haben (Webshell-Drop). Die vom SANS ISC in freier Wildbahn aufgezeichneten Payloads gehen den direkteren Weg. Angreifer senden POST-Anfragen an /?rest_route=/batch/v1 mit Content-Type: application/json und — hilfreich für Verteidiger — dem User-Agent-String cve-2026-63030/1.0. Zunächst schicken sie eine UNION-basierte Sonde, deren injizierte Abfrage die Markierung ||OK|| zurückgibt, um die Ausnutzbarkeit zu bestätigen, und anschließend eine Payload, die per INTO OUTFILE eine PHP-Webshell in das Cache-Verzeichnis schreibt — beobachtet unter /var/www/wp-content/cache/94uh9ubh6e1x.php. Die Webshell authentifiziert über einen p-Parameter, der ihrem eigenen Dateinamen-Token entspricht, nimmt Befehle in b (Base64-kodiert) oder c (roh) entgegen, umschließt die Ausgabe mit den Markierungen [S] und [E] und probiert nacheinander system(), passthru(), exec(), shell_exec() und popen(). Zusätzlich wurden neue Administratorkonten direkt in die Datenbank geschrieben.

Eine Nuance für die Triage: Die Analyse von Rapid7 stellt fest, dass die Kette voraussetzt, dass ein persistenter Object Cache deaktiviert ist — was dem Auslieferungszustand einer Standard-WordPress-Installation entspricht. Sites mit Redis- oder Memcached-Objektcaching sind über diesen Weg möglicherweise nicht ausnutzbar, doch darauf sollten Sie sich nicht als Gegenmaßnahme verlassen; die SQL-Injection selbst bleibt davon unberührt.

Ausnutzung in freier Wildbahn

Ausnutzung am selben Tag. WordPress veröffentlichte die Patches am 17. Juli 2026. Wordfence dokumentierte noch am 17. Juli erste Scans und dreizehn Minuten später die ersten SQL-Injection-Versuche — praktisch kein Patch-Fenster.
PoCs binnen Stunden. Öffentliche Proof-of-Concept-Exploits erschienen innerhalb eines Tages nach der Offenlegung; mehrere Kommentatoren wiesen darauf hin, dass sie rasch mithilfe von KI-Coding-Assistenten zusammengesetzt wurden, was den klassischen Zeitverzug der Exploit-Entwicklung zusammenschrumpfen ließ.
Opportunistisch, nicht zielgerichtet. Die beobachtete Aktivität besteht aus breitem, internetweitem Scanning über alle Branchen und Regionen hinweg — typisch für Massenausnutzung statt für eine bestimmte Opfergruppe.
Eine Premiere für den KEV-Katalog. Die CISA nahm beide CVEs am 21. Juli 2026 auf — das erste Mal, dass WordPress Core und nicht ein WordPress-Plugin im Known-Exploited-Vulnerabilities-Katalog auftaucht.
Zurückhaltung der Forscher half wenig. Searchlight Cyber hielt technische Details zum Offenlegungszeitpunkt bewusst zurück und veröffentlichte stattdessen einen kostenlosen Scanner. Angreifer haben den Patch dennoch rückwärts analysiert; ab dem 22. Juli waren alle Details öffentlich.

Auswirkungen nach der Ausnutzung

Beliebige Codeausführung als Webserver-Benutzer: Eine Webshell, die als www-data/apache läuft, kann jede Datei lesen, die dieser Benutzer lesen kann — einschließlich wp-config.php samt Datenbank-Zugangsdaten.
Vollständiger Datenbankzugriff: Inhalte, Benutzertabellen, Passwort-Hashes und in Onlineshops Kunden- und Bestelldaten.
Betrügerische Administratorkonten: dauerhafter, legitim wirkender Zugang, der das Entfernen der Webshell überlebt.
Kompromittierung von Besuchern nach Supply-Chain-Art: eingeschleuste Skimmer, SEO-Spam oder bösartige Weiterleitungen, ausgeliefert an jeden Besucher einer vertrauenswürdigen Domain.
Laterale Bewegung im Shared Hosting: Eine kompromittierte Site bedeutet häufig Zugriff auf Nachbar-Sites unter demselben Account oder Server.
Wiederverwendung von Zugangsdaten: Datenbank- und SMTP-Zugangsdaten aus wp-config.php werden regelmäßig an anderer Stelle in der Umgebung wiederverwendet.
Persistenz über den Patch hinaus: Ein Angreifer, der vor Ihrem Update eine Webshell oder ein Admin-Konto platziert hat, ist nach dem Update immer noch da.

⚠️ Auswirkungsanalyse

Unmittelbare Auswirkung

Unauthentifiziert vom Internet zur RCE: keine Zugangsdaten, keine Benutzerinteraktion, kein Plugin als Voraussetzung.
Standardinstallationen sind verwundbar: Die Härtungsstrategie „wir halten es minimal” hilft hier nicht.
Die exponierte Population ist riesig: Rund 41,5 % aller Websites laufen auf WordPress, und die Patch-Adoption in diesem langen Schwanz ist historisch langsam.
Die Ausnutzung setzte vor nennenswertem Patching ein: Die Angriffe begannen am selben Tag, an dem der Fix erschien.
Patchen macht eine frühere Kompromittierung nicht rückgängig: Webshells und betrügerische Admin-Konten überleben Updates.

Betroffene Versionen

WordPress-Branch	Verwundbare Versionen	Fehlerbereinigte Version	Exposition
7.0.x	7.0.0 – 7.0.1	7.0.2	Vollständige RCE-Kette (beide CVEs)
6.9.x	6.9.0 – 6.9.4	6.9.5	Vollständige RCE-Kette (beide CVEs)
6.8.x	6.8.0 – 6.8.5	6.8.6	Nur SQL-Injection (CVE-2026-60137)
7.1 beta	7.1 beta1	7.1 beta2	Vollständige RCE-Kette (beide CVEs)
Vor 6.8	—	—	Nicht betroffen von diesen CVEs

Versionen vor 6.8 sind nicht von wp2shell betroffen, aber mit an Sicherheit grenzender Wahrscheinlichkeit von zahlreichen älteren, längst öffentlichen Schwachstellen. „Zu alt, um davon betroffen zu sein” ist keine Sicherheitsstrategie.

Betroffene Umgebungen

Jede aus dem Internet erreichbare WordPress-Site auf 6.9.x oder 7.0.x unterhalb der fehlerbereinigten Builds — die Standardkonfiguration ist die verwundbare Konfiguration.
Sites mit deaktivierten automatischen Updates: Agenturen, Managed Hoster und Unternehmen, die Core-Versionen aus Stabilitätsgründen festschreiben, sind genau die Gruppe, die noch exponiert ist.
Headless- und API-getriebene Deployments: Die REST API ist hier nicht nur aktiviert, sondern aktiv im Einsatz, und der Batch-Endpunkt ist an der WAF womöglich ausdrücklich freigegeben.
Vernachlässigte und vergessene Sites: Kampagnen-Microsites, alte Landingpages und Abteilungsblogs ohne Verantwortlichen — der klassische Schatten-IT-Fußabdruck.
Shared-Hosting-Mandanten: Ein verwundbarer Nachbar kann zum Problem aller werden.

Angreiferprofile

Massenausnutzungs-Gruppen: Eine unauthentifizierte Core-RCE gegen 40 % des Webs ist der ideale Ausgangspunkt für automatisierte, skalierte Kompromittierung — Webshells in großer Zahl, Monetarisierung später.
SEO-Spam- und Malvertising-Betreiber: Gekaperte Domains mit Autorität lassen sich unmittelbar zu Geld machen.
Skimmer-Gruppen: WooCommerce-Checkout-Seiten sind eine Fundgrube für Zahlungsdaten.
Initial-Access-Broker: Eine Webshell auf einer Unternehmens-Marketingseite ist ein verkäuflicher Brückenkopf, besonders wenn diese Site Infrastruktur oder Zugangsdaten mit wertvolleren Systemen teilt.
Botnet-Betreiber: Codeausführung auf Webservern in dieser Größenordnung ist Rohkapazität für DDoS, Proxying und weiteres Scanning.

🛡️ Gegenmaßnahmen

Sofortmaßnahmen (Priorität 1) ⚡

Prüfen Sie, welche Version jede Site tatsächlich meldet. Vertrauen Sie keiner Inventarliste. Mit WP-CLI auf dem Host:

# Gibt die exakte WordPress-Core-Version (und DB-Revision) dieser Installation aus.
# Abgleich mit den fehlerbereinigten Builds: 7.0.2, 6.9.5 oder 6.8.6.
wp core version --extra

Für Sites, die Sie nur über HTTP erreichen, gibt WordPress seine Version standardmäßig im Generator-Meta-Tag preis (Hinweis: Viele Härtungs-Plugins entfernen es, das Fehlen beweist also nichts):

# Liest die WordPress-Version aus dem oeffentlichen Generator-Meta-Tag.
# -s unterdrueckt die Fortschrittsanzeige; grep filtert die Generator-Zeile aus dem HTML.
curl -s https://example.com/ | grep -i 'name="generator"'

Aktualisieren Sie sofort auf ein fehlerbereinigtes Release. Das ist die einzige echte Behebung. Gemäß dem WordPress-7.0.2-Sicherheitsrelease:
```
# Aktualisiert WordPress Core auf das gepatchte Release des jeweiligen Branch.
# Verwenden Sie die zu Ihrem Branch passende Version: 7.0.2, 6.9.5 oder 6.8.6.
wp core update --version=7.0.2

# Alternative: auf dem aktuellen Major-Branch bleiben und nur das
# Minor-(Sicherheits-)Release einspielen -- z. B. 6.9.4 -> 6.9.5.
wp core update --minor
```
WordPress.org hat erzwungene automatische Hintergrund-Updates für betroffene Installationen aktiviert, sodass viele Sites bereits ohne Zutun der Betreiber gepatcht wurden — Sie müssen das jedoch verifizieren statt es anzunehmen, und Sites mit deaktiviertem WP_AUTO_UPDATE_CORE haben es nicht erhalten.
Sperren Sie den Batch-Endpunkt an der WAF — ausschließlich als Notbehelf. Wenn Sie wirklich nicht innerhalb einer Stunde aktualisieren können, empfehlen Searchlight Cyber und Tenable, beide Zugriffspfade auf den Endpunkt zu sperren, da beide Formen denselben Code erreichen:
- /wp-json/batch/v1
- /?rest_route=/batch/v1
Nur einen von beiden zu sperren ist der häufigste Fehler an dieser Stelle. Das verschafft Zeit; es ist kein Fix und kann den Block-Editor oder ein Headless-Frontend brechen.
Gehen Sie bei jeder Site, die nach dem 17. Juli exponiert und ungepatcht war, von einer Kompromittierung aus. Da die Ausnutzung binnen dreizehn Minuten nach dem Release begann, sollte eine aus dem Internet erreichbare Site, die tagelang auf einem verwundbaren Build blieb, als potenziell kompromittiert gelten, bis die folgenden Prüfungen sauber sind.

Detektionsmaßnahmen 🔍

Prüfen Sie, ob Core-Dateien manipuliert wurden. Dieser Befehl vergleicht jede Core-Datei mit den offiziellen Prüfsummen von WordPress.org und ist die wertvollste verfügbare Einzelprüfung:

# Verifiziert alle Core-Dateien gegen die WordPress.org-Pruefsummen und meldet
# zusaetzlich Nicht-WordPress-Dateien im Wurzelverzeichnis der Installation.
wp core verify-checksums --include-root

Suchen Sie in den Webserver-Logs nach der Signatur der Ausnutzung. Die aufgezeichneten Payloads nutzten einen markanten User-Agent, und jedes anonyme POST an den Batch-Endpunkt verdient Aufmerksamkeit:

# 1) Der in freier Wildbahn beobachtete User-Agent-String dieses Exploits.
#    Log-Pfad anpassen: gezeigt ist nginx unter Debian/Ubuntu; verwenden Sie
#    /var/log/apache2/access.log (Debian) bzw. /var/log/httpd/access_log (RHEL).
grep -F 'cve-2026-63030/1.0' /var/log/nginx/access.log

# 2) Jede Anfrage an den Batch-Endpunkt, in beiden moeglichen Formen.
grep -E 'batch/v1|rest_route=/batch/v1' /var/log/nginx/access.log

# 3) SQL-Injection-Marker in den Request-Zeilen: UNION SELECT und die
#    vom SANS ISC gemeldete ||OK||-Sondenmarkierung. -i ignoriert Gross-/Kleinschreibung;
#    die Pipe-Zeichen stehen in Klammern, damit sie in ERE literal bleiben.
grep -E -i 'union[[:space:]]+select|[|][|]OK[|][|]' /var/log/nginx/access.log

Suchen Sie nach abgelegten Webshells. Die beobachtete Payload schrieb PHP in das Cache-Verzeichnis, das normalerweise keinen ausführbaren PHP-Code enthalten sollte, den Sie nicht selbst dort abgelegt haben:

# Listet PHP-Dateien unterhalb von wp-content, die seit dem Offenlegungsdatum
# geaendert wurden. -newermt erwartet eine Datumsangabe; passen Sie sie an den
# letzten bekannt guten Stand an.
find wp-content -name '*.php' -newermt '2026-07-16' -ls

# Der beobachtete Ablageort war das Cache-Verzeichnis. Jedes PHP hier ist verdaechtig.
find wp-content/cache -name '*.php' -ls

Prüfen Sie auf betrügerische Administratorkonten. Beide Eskalationswege enden bei einem angreiferkontrollierten Admin:

# Listet jeden Administrator samt Registrierungsdatum.
# Pruefen Sie jedes Konto, das Sie nicht zuordnen koennen.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Zusätzliche Suche:

Prüfen Sie die installierten Plugins auf alles, was Sie nicht selbst installiert haben — Weg A endet damit, dass der Angreifer als Schritt zur Codeausführung ein Plugin hochlädt. wp plugin list --status=active liefert den aktuellen Bestand.
Suchen Sie nach den Antwortmarkierungen der Webshell ([S] / [E]) und dem Parametermuster p/b/c in POST-Bodies, sofern Ihre WAF oder Ihr Proxy Request-Bodies protokolliert.
Alarmieren Sie auf POST-Anfragen an batch/v1 aus unauthentifizierten Sitzungen in Ihrem SIEM. In Splunk-artigem SPL gegen kombinierte Access-Logs:
```
index=web sourcetype=access_combined method=POST uri="*batch/v1*"
| stats count by clientip, useragent
| sort - count
```
Rotieren Sie jedes Geheimnis in wp-config.php auf jeder Site, bei der Sie einen Zugriff vermuten: Datenbank-Zugangsdaten, die Authentifizierungs-Salts/Keys sowie dort hinterlegte SMTP- oder API-Zugangsdaten.

Langfristige Sicherheitsverbesserungen

Lassen Sie automatische Core-Sicherheitsupdates aktiviert. Der Auto-Update-Mechanismus von WordPress ist der einzige Grund, warum dieses Ereignis nicht deutlich schlimmer ausfiel. Wer ihn aus Change-Management-Gründen deaktiviert, übernimmt die Pflicht, schneller als dreizehn Minuten zu patchen — was nicht möglich ist.
Führen Sie ein echtes Inventar Ihrer WordPress-Instanzen. Sie können die Marketing-Microsite nicht patchen, deren Existenz Sie vergessen haben. Die Erfassung aus dem Internet erreichbarer CMS-Instanzen gehört in das Asset Management, nicht in jemandes Gedächtnis.
Beschränken Sie die REST API dort, wo Sie sie nicht brauchen. Ist eine Site nicht headless und nutzt den Block-Editor nicht remote, verringert eine Einschränkung des anonymen REST-Zugriffs eine große standardmäßige Angriffsfläche.
Behandeln Sie „Core ist sicher, Plugins sind riskant” nicht als Axiom. Dieses Ereignis ist das Gegenbeispiel. Core verdient dasselbe Patch-SLA wie alles andere.
Segmentieren und entprivilegieren Sie den Webserver. Der PHP-Prozess sollte in Produktion nicht in seine eigenen Code-Verzeichnisse schreiben können, keine wiederverwendbaren Zugangsdaten für andere Systeme halten und nicht in einem flachen Netz mit wertvollen Systemen stehen.
File Integrity Monitoring auf Web-Roots. wp core verify-checksums ist eine manuelle Momentaufnahme; kontinuierliches FIM erwischt die Webshell, die um 3 Uhr nachts landet.
Verlagern Sie Webserver-Logs vom Host weg. Eine Detektion, die von Logs auf der kompromittierten Maschine abhängt, ist eine Detektion, die ein Angreifer löschen kann.

🎯 Warum ist das kritisch?

Es steckt in Core, nicht in einem Plugin: Die übliche Gegenmaßnahme, einen schlanken, gut geprüften Plugin-Bestand zu fahren, bietet hier überhaupt keinen Schutz.
Unauthentifiziert und ohne Interaktion: ein einziges HTTP-POST von irgendwo im Internet, gegen eine Standardinstallation.
Die exponierte Population umfasst rund 41,5 % des Webs: Nur wenige Schwachstellen hatten je eine derart große adressierbare Fläche.
Die Ausnutzung begann dreizehn Minuten nach dem Fix: Das praktische Patch-Fenster betrug null.
Eine WordPress-Core-Premiere für CISA KEV: Der Katalog führte zuvor WordPress-Plugin-Schwachstellen — nie Core.
Der Endpunkt existiert seit WordPress 5.6: Die verwundbare Route liegt seit Jahren unbemerkt exponiert auf Installationen.
Zwei „mittlere” Bugs ergaben einen kritischen: Eine mit 5.9 bewertete SQL-Injection plus eine Routing-Eigenart ergibt unauthentifizierte RCE — eine Erinnerung daran, dass die Schwere einzelner Findings das verkettete Risiko regelmäßig unterschätzt.
Patchen vertreibt keinen Angreifer, der bereits erfolgreich war: Behebung und Incident Response sind hier zwei getrennte Aufgaben.

🚀 Zeitleiste und Offenlegung

Vor Juli 2026 — Adam Kues von Assetnote / Searchlight Cyber entdeckt die REST-API-Batch-Route-Confusion und meldet sie über das HackerOne-Programm von WordPress. Unabhängig davon melden TF1T, dtro und haongo die SQL-Injection in WP_Query.
2026-07-17 — WordPress veröffentlicht das koordinierte Sicherheitsrelease: 7.0.2, 6.9.5, 6.8.6 und 7.1 beta2. Die GitHub Security Advisories GHSA-ff9f-jf42-662q (CVE-2026-63030) und GHSA-fpp7-x2x2-2mjf (CVE-2026-60137) werden veröffentlicht. Searchlight Cyber publiziert unter dem Namen wp2shell eine bewusst detailarme Zusammenfassung sowie einen kostenlosen Scanner unter wp2shell.com.
2026-07-17 (derselbe Tag) — Wordfence dokumentiert Scans, gefolgt von den ersten SQL-Injection-Versuchen dreizehn Minuten später.
2026-07-20 — Das SANS ISC veröffentlicht aufgezeichnete Payloads aus freier Wildbahn, darunter den User-Agent cve-2026-63030/1.0, die ||OK||-Sondenmarkierung und den INTO OUTFILE-Webshell-Drop. Detaillierte technische Analysen Dritter erscheinen.
2026-07-21 — Die CISA nimmt beide CVEs in den KEV-Katalog auf, mit einer Behebungsfrist für US-Bundesbehörden von 24. Juli für CVE-2026-63030 und 4. August für CVE-2026-60137 gemäß BOD 26-04. WordPress.org aktiviert erzwungene automatische Sicherheitsupdates für betroffene Installationen.
2026-07-22 — Alle technischen Details sind öffentlich; mehrere funktionsfähige Proof-of-Concept-Exploits kursieren; aktive Massenausnutzung wird von mehreren Anbietern bestätigt.
CW30 (20.-26. Juli 2026) — Anhaltende Berichterstattung und Ausnutzung, dokumentiert von Rapid7, Tenable, Horizon3.ai, Greenbone, Picus, SANS ISC und The Hacker News.

🔗 Ressourcen und Referenzen

CVE: CVE-2026-63030 (Batch-Route-Confusion) · CVE-2026-60137 (SQL-Injection)
NVD: NVD — CVE-2026-63030 · NVD — CVE-2026-60137
Hersteller-Advisory: WordPress 7.0.2 Security Release · GHSA-ff9f-jf42-662q
Ursprüngliche Forschung: wp2shell: Pre Authentication RCE in WordPress Core — Searchlight Cyber
CWE: CWE-436: Interpretation Conflict · CWE-89: SQL Injection
CISA-KEV-Katalog: Known Exploited Vulnerabilities (beide CVEs aufgenommen am 21.07.2026)
WP-CLI-Dokumentation: wp core version · wp core update · wp core verify-checksums · wp user list

💼 SEKurity Unterstützt Sie

wp2shell ist eine Lehrstunde darüber, wo Risiko tatsächlich sitzt. Jeder Härtungsleitfaden sagt, die Gefahr liege in den Plugins, also prüfen Teams ihre Plugins — und dann verwandeln eine Routing-Eigenart und eine Typprüfung in Core eine blanke, plugin-freie Installation in einen Webshell-Host. Es ist zugleich eine Lehrstunde über Verkettung: Aus einer mit 5.9 bewerteten SQL-Injection, die „nur relevant ist, wenn ein Plugin sie falsch nutzt”, wurde in dem Moment eine unauthentifizierte RCE, in dem ein zweiter, unauffälliger Bug die davorstehende Validierung entfernte. Keines der beiden Findings hätte für sich einen Bericht angeführt; gemeinsam sind sie die am breitesten ausnutzbare Web-Schwachstelle des Jahres. Genau diese Lücke — zwischen der Einzelbewertung von Findings und dem, was ein Angreifer daraus baut — deckt eine echte Adversary Simulation auf und ein Checklisten-Scan nicht. Wir helfen Organisationen dabei, die aus dem Internet erreichbaren CMS-Instanzen zu inventarisieren, die sie längst vergessen haben, zu verifizieren, ob Notfall-Patch-Prozesse unter einem Zero-Day-Patch-Fenster wirklich funktionieren, und festzustellen, ob ein kompromittierter Webserver überhaupt entdeckt würde — geschweige denn eingedämmt, bevor er zum Sprungbrett in alles Übrige wird.

Unsere Leistungen

Penetration Testing: Webanwendungen, mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Engagements
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

🌐 Website: www.sekurity.de

📧 Anfragen: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Webanwendungen ist unser Antrieb.

InSEKurity of the Week (CW30/2026): WordPress Core wp2shell Pre-Auth RCE (CVE-2026-63030 & CVE-2026-60137)