Kontakt
Write-up · CVE-2026-63030 + CVE-2026-60137

wp2shell: Wie zwei Bugs in WordPress Core zu unauthentifiziertem RCE führen

Am 17. Juli 2026 hat WordPress Notfall-Releases veröffentlicht und gleichzeitig forced Auto-Updates ausgerollt. Der Grund: eine Angriffskette aus zwei Schwachstellen im Core, die einem anonymen Angreifer auf einer Default-Installation – ohne ein einziges Plugin und ohne Login – beliebige Codeausführung erlaubt. Die Kette hat einen Namen: wp2shell. Dieser Beitrag zerlegt beide Bugs und die vollständige Kette.

Veröffentlicht: 21.07.2026 · Lesezeit: 10 Min · Autor: Niclas Zillmanns

Hinweis: Dieser Artikel basiert auf den offiziellen GitHub Security Advisories, dem Searchlight-Cyber-Advisory, und dem Rapid7-ETR. Die vollständige technische Chain wurde von Searchlight Cyber inzwischen veröffentlicht. Die Techniken dienen ausschließlich der Aufklärung und der Verbesserung der Anwendungssicherheit.

Inhalt

  1. Was passiert ist
  2. Die zwei Schwachstellen
  3. Die vollständige Angriffskette
  4. Betroffene Versionen
  5. Was das für WordPress-Assessments bedeutet
  6. Gegenmaßnahmen und Erkennung
  7. Quellen

Was passiert ist

Am 17. Juli 2026 hat WordPress die Notfall-Releases 6.8.6, 6.9.5 und 7.0.2 herausgebracht – und gleichzeitig forced Auto-Updates für alle betroffenen Installationen aktiviert. Der Grund: eine Angriffskette aus zwei Schwachstellen in WordPress Core, die einem anonymen Angreifer erlaubt, auf einer Default-Installation ohne ein einziges Plugin und ohne Login beliebigen Code auszuführen.

Am 21. Juli 2026 wurden beide CVEs in CISAs KEV-Katalog (Known Exploited Vulnerabilities) aufgenommen. Aktive Ausnutzung ist bestätigt – Sicherheitsfirmen wie Patchstack, Wiz und Hexastrike berichten übereinstimmend von Angriffen in freier Wildbahn.

Die zwei Schwachstellen

Keine der beiden Schwachstellen führt alleine zu RCE. Erst ihre Kombination ergibt die vollständige Angriffskette – aber beide müssen separat gepatcht werden.

CVE-2026-63030 – REST API Batch Route Confusion

CVSS 9.8 (Kritisch) · CWE-436

Der WordPress REST API Batch-Endpoint (/wp-json/batch/v1) führt Validierung und Ausführung von Sub-Requests in zwei separaten Schleifen durch. Wenn wp_parse_url() bei einem Sub-Request-Pfad fehlschlägt, wird der Fehler ins Validierungs-Array geschrieben – aber nicht ins $matches-Array. Das erzeugt einen Index-Offset: jeder nachfolgende Sub-Request wird unter dem falschen Handler dispatcht, ohne den zugehörigen Authorization-Check.

Ein Angreifer kann das gezielt ausnutzen: eine fehlerhafte Low-Privilege-Anfrage erzeugt den Offset, die nachfolgende High-Privilege-Anfrage wird ohne Autorisierungsprüfung ausgeführt. Durch rekursive Batch-Calls lassen sich zusätzlich Anfragemethode, Route und Validierungsschema umgehen.

Der Bug existiert erst seit WordPress 6.9. Ältere Versionen sind von CVE-2026-63030 nicht betroffen.

CVE-2026-60137 – SQL Injection in WP_Query

CVSS 5.9 (Mittel) · CWE-89

Der öffentliche API-Parameter author_exclude wird intern auf WP_Query::author__not_in gemappt. WordPress bereinigt diesen Wert nur, wenn er als Integer-Array übergeben wird – nicht wenn er als String ankommt. Landet ein String dort, wird er direkt in den SQL-Query interpoliert.

Unter normalen Umständen verhindert die Parameter-Validierung diese Eingabe. CVE-2026-63030 hebelt genau diese Validierung aus und öffnet so den Weg zur SQL Injection.

Wichtig: CVE-2026-60137 existiert bereits ab WordPress 6.8.0 – auch auf Versionen, die CVE-2026-63030 gar nicht kennen. Auf 6.8.x gibt es keinen RCE, aber eine ausnutzbare SQL Injection. Auch diese Installationen müssen gepatcht werden.

Die vollständige Angriffskette

  1. Batch-Endpoint ansprechen: Anonymer Request an /wp-json/batch/v1 mit einer fehlerhaften Low-Privilege-Anfrage, die den Index-Offset im $matches-Array erzeugt.
  2. Authorization-Check umgehen: Durch den Offset dispatcht die nachfolgende High-Privilege-Anfrage ohne Autorisierungsprüfung. Rekursive Batch-Calls umgehen zusätzlich GET-Restriktionen und Parametervalidierung.
  3. SQL Injection auslösen: Über author_exclude als String-Parameter wird eine UNION SELECT SQL Injection ausgelöst. Damit lassen sich unter anderem Admin-Passwort-Hashes, Tabellenpräfix, Benutzer-IDs und Beitrags-IDs auslesen.
  4. Object Cache missbrauchen: Die UNION SELECT Injection erzeugt legitime WP_Post-Objekte, die im WordPress Object Cache gespeichert werden. Diese Objekte ketten legitimes WordPress-Verhalten – WordPress verhält sich also „normal", führt aber dabei Datenbankschreibvorgänge und Anwendungs-Kontrollflussänderungen aus, die vom Angreifer gesteuert werden.
  5. Code Execution: Ergebnis ist entweder die Erstellung eines Admin-Accounts mit anschließendem Plugin-Upload, oder direkt die Erstellung betrügerischer Beiträge mit eingebetteten Webshells. Beides läuft mit den Rechten des Webserver-Prozesses.

Kein Plugin nötig. Kein Account. Keine besondere Konfiguration. Eine Default-Installation reicht – sofern kein persistenter Object Cache aktiv ist. Cloudflare hat bestätigt, dass ein aktiver Object Cache den verwundbaren Codepfad schließt. Das senkt das Risiko in manchen Setups, ersetzt aber keinen Patch.

Betroffene Versionen

Version Betroffen Schwachstelle Fix
< 6.8 Nein – –
6.8.0–6.8.5 Ja CVE-2026-60137 (SQL Injection, kein RCE) 6.8.6
6.9.0–6.9.4 Ja CVE-2026-63030 + CVE-2026-60137 (vollständiger RCE) 6.9.5
7.0.0–7.0.1 Ja CVE-2026-63030 + CVE-2026-60137 (vollständiger RCE) 7.0.2
7.1 Beta Ja Behoben in 7.1 Beta 2 7.1 Beta 2

Der 6.8.x-Punkt ist der häufigste Triage-Fehler. Wer nur CVE-2026-63030 trackt, behandelt 6.8.x-Installationen als sicher – obwohl die SQL Injection dort immer noch offen ist.

Was das für WordPress-Assessments bedeutet

wp2shell verändert eine Grundannahme bei WordPress-Pentests: Core ist meistens sicher, das Risiko liegt in Plugins. Das gilt weiterhin als Faustregel – aber wp2shell zeigt, dass Core-Bugs möglich sind, und dass sie, wenn sie kommen, sofort kritisch sind.

Zwei konkrete Punkte, die sich für Assessments ändern:

  • Den Batch-Endpoint aktiv testen. /wp-json/batch/v1 taucht in den meisten Standard-Checklisten nicht gesondert auf. Nach wp2shell gehört er zu den ersten Anlaufpunkten – Patch-Stand, Konfiguration (anonymer Zugriff erlaubt?) und Object-Cache-Status.
  • 6.8.x nicht vergessen. Ein Scanner, der nur auf CVE-2026-63030 prüft, gibt für 6.8.x-Installationen grünes Licht. Für einen Pentest-Bericht ist das ein Fehler – die SQL Injection ist dort immer noch offen.

Gegenmaßnahmen und Erkennung

Sofort patchen – das ist die einzige vollständige Lösung. Forced Auto-Updates reduzieren das Risiko, garantieren aber keine erfolgreiche Durchführung. Jede Installation sollte manuell auf den tatsächlich installierten Stand geprüft werden.

Wer nicht sofort patchen kann

  • /wp-json/batch/v1 und ?rest_route=/batch/v1 auf WAF-Ebene blockieren.
  • Anonymen REST-API-Zugriff per Plugin deaktivieren.

Kompromittierungscheck nach dem Patchen

  • HTTP-Logs auf auffällig viele 207- oder 200-Multi-Status-Antworten am Batch-Endpoint prüfen – ein zuverlässiger Hinweis auf Ausnutzungsversuche.
  • User-Agent-Strings wp2shell oder rezwp2shell im Access-Log = zweckgebaute Angriffs-Frameworks.
  • Neue Admin-Accounts seit dem 17. Juli, unbekannte Plugins und veränderte PHP-Dateien kontrollieren.
Wer zwischen dem 17. und 21. Juli ungepatcht online war, sollte den Kompromittierungscheck nicht überspringen.

Quellen

← Zurück zur Blog-Übersicht