wp2shell: Wie eine 25Dollar-KI-Session Millionen WordPress-Seiten ins Wackeln bringt

Stell dir vor, du sitzt entspannt beim Kaffee, hast dein Lieblings-KI-Modell offen, wirfst 25 Dollar API-Guthaben rein und 10 Stunden später hältst du eine unauthentifizierte Remote Code Execution (RCE) für das meistgenutzte CMS der Welt in den Händen. YAY!

Genau das ist Adam Kues (Security Analyst bei Searchlight Cyber) passiert. Das Ergebnis hört auf den geschmeidigen Namen wp2shell und ist eine aktiv ausgenutzte Exploit-Kette, die aktuell über Millionen WordPress-Instanzen rollt. Security-Insider.de hat darüber bereits am 27.7 ausführlich berichtet.

Wenn du WordPress betreibst und seit Mitte Juli kein Update gemacht hast, ist now der Moment, den Kaffee wegzustellen und das Terminal zu öffnen.

Die Anstalt brennt: Was ist wp2shell?

In the case of: wp2shell handelt es sich nicht nur um einen einfachen Bug, sondern um eine Exploit-Kette aus zwei Schwachstellen im WordPress-Core. Zusammen erlauben sie Unauthenticated RCE, was bedeutet, ein Angreifer braucht weder Zugangsdaten noch besonderen Status auf deiner Seite. Ein präparierter HTTP-Request reicht, um beliebigen PHP-Code auszuführen und den Server komplett zu übernehmen.

Die Angreifer verschwenden keine Zeit: Bereits 13 Minuten nach Veröffentlichung des Security-Patches durch WordPress am 17.7 registrierten Sicherheitsfirmen wie Defiant die ersten automatisierten SQL-Injection-Sonden im Netz.

Die Anatomie des Exploits: Was unter der Haube passiert

Für alle, die genauer wissen wollen, wie der Hase läuft: hier ist das Zusammenspiel der zwei Sicherheitslücken vereinfacht:

[ Unauth Request ] 
       │
       ▼
[ REST API Batch-Endpoint ] (CVE-2026-63030: Route Mapping Flaw)
       │
       ├─ Bypass von Auth / Routing-Restrictions
       ▼
[ WP_Query Engine ] (CVE-2026-60137: SQL Injection via 'author__not_in')
       │
       ├─ Unbereinigter Parameter hebelt SQL-Sanitization aus
       ▼
[ Remote Code Execution / Webshell ]
       │
       └─ Ablage in /wp-content/cache/ mit zufälligem Hash-Namen

Alle technischen Details findet Ihr schön aufgedröselt in den Beiträgen von Searchlight Cyber and wiz.io

Der Türöffner: REST-API Batch Routing (CVE-2026-63030)

• CVSS Score: 9.8 (Kritisch)
• Affected versions: WP 6.9.x (< 6.9.5) & 7.0.x (< 7.0.2)

WordPress bietet über seinen REST-API-Batch-Endpunkt die Möglichkeit, mehrere Requests in einem einzigen Aufruf zu bündeln. Hier gab es einen logischen Fehler bei der Routenzuordnung (Route Mapping). Dadurch konnten Angreifer Anfragen an interne/geschützte Endpunkte schleusen, die normalerweise eine Authentifizierung erfordern würden.

Der Payload-Lieferant: SQL Injection in WP_Query (CVE-2026-60137)

• CVSS Score: 5.9 (Mittel)
• Affected versions: WP 6.8.x (< 6.8.6), 6.9.x (< 6.9.5) & 7.0.x (< 7.0.2)

Der Klassiker: Der Parameter author__not_in in der zentralen Abfrageklasse WP_Query wurde nicht ordnungsgemäß sanitisiert. Wird dieser Parameter mit ungefilterten Eingaben gefüttert (z. B. getriggert über ein Plugin oder die oben genannte REST-API-Lücke), entsteht eine klassische SQL Injection.

Die Kombination: Das 2-Stufen-Prinzip

Security researcher Johannes B. Ullrich (SANS Institute) zeigt anhand eines Beispiels, wie die Angriffswelle in der Praxis abläuft:

1. Probe / Recon: Der Attacker schickt einen ersten Payload via SQLi, um zu prüfen, ob die Datenbank schreibbar ist und ob die Lücke greift.
2. Webshell-Dropper: Über die SQLi wird eine PHP-Webshell ins Dateisystem gedrückt – typischerweise im Verzeichnis /wp-content/cache/ unter einem zufällig generierten MD5/SHA-Namen (z. B. a8f3b...php).
3. Stealth-Mechanismus: Der Dateiname dient gleichzeitig als Authentifizierungs-Token. Ruffst du die Webshell ohne den passenden URL-Parameter auf, gibt sie eiskalt einen gefälschten HTTP 404 Not Found zurück. Smart!

Sobald die Shell sitzt, laden Bots schädliche Plugins nach, lesen die wp-config.php aus (Hallo Datenbank-Credentials!), legen neue Administrator-User an oder schleusen Schadcode über manipulierte CDN-Skripte ein.

KI im Bug-Bounty-Game: Der 25-Dollar-Joker

Ein pikantes Detail am Rande: Adam Kues nannte seinen Writeup provokant:

„Exploit-Broker zahlen 500.000 $ für eine WordPress-RCE. Ich habe eine mit GPT-5.6 Sol Ultra und 25 $ gefunden.“

Er nutzte das Large Language Model gezielt für die statische Code-Analyse und das Sifting durch Diff-Commits des WordPress-Cores. Was früher Teams von Security-Researchern wochenlang beschäftigt hat, erledigt eine spezialisierte KI heute in wenigen Stunden für Kleingeld.

Für Admins bedeutet das: Die Time-to-Exploit schrumpft massiv. Die Zeitspanne zwischen Patch-Release und vollautomatisierten Massenscans liegt mittlerweile im Minutenbereich.

Erste Hilfe: Bist du betroffen & was ist zu tun?

Quick Check via Webseite: https://wp2shell.com/

Step 1: Aktualisieren (JETZT!)

WordPress hat am 17. Juli 2026 die gepatchte Version 7.0.2 (bzw. die Backports 6.9.5 and 6.8.6) veröffentlicht. Wenn dein Auto-Update nicht gegriffen hat: Sofort manuell anstoßen.

Step 2: IoC-Check (Indicators of Compromise)

Falls du wissen willst, ob sich schon jemand bei dir eingenistet hat, prüfe deine Instanz auf folgende Auffälligkeiten:

1. /wp-content/cache/ durchsuchen: Achte auf frische .php-Dateien mit kryptischen Namen im Cache-Ordner. Cache-Ordner sollten in der Regel keinen ausführbaren PHP-Code enthalten.
   
2. Admin-User checken: Schau in der WordPress-Musterungsliste (/wp-admin/users.php?role=administrator) nach unbekannten Accounts. Angreifer legen gerne unauffällige Admins an.
   
3. Logfile-Analyse: Filtere deine Webserver-Logs (Nginx/Apache) nach verdächtigen Anfragen an admin-ajax.php, Aufrufen von /wp-json/wp/v2/batch sowie Zugriffen auf PHP-Dateien im cache/-Verzeichnis.

Step 3: Hilfreiche Tools

• Der oben bereits erwähnte Searchlight Cyber „wp2shell checker“: Bietet einen schnellen Remote-Check für deine Domain.
• Macnica Live-Dashboard (Yutaka Sejiyama): Verfolgt die globale Patch-Rate. Aktuell sind immerhin ~81,6 % der untersuchten Systeme gepatcht. Das bedeutet aber auch: Fast jede 5. Seite ist still open to attack!

Fazit & Tipp für die Praxis

wp2shell zeigt mal wieder eindrucksvoll, wo die Reise im Cybersecurity-Bereich hingeht: Wenn KI-gestützte Analysen die Entdeckung von 0-Days demokratisieren, müssen auch Verteidiger aufrüsten.

3 Goldene Regeln für deinen WP-Server:

1. Verzeichnisschutz für Uploads/Cache: Binde in deiner Nginx-/Apache-Config eine Regel ein, die die Ausführung von .php-Dateien in /wp-content/uploads/ and /wp-content/cache/ rigoros verbietet (location ~* /wp-content/(uploads|cache)/.*\.php$ { deny all; }).
   
2. Fail2Ban / WAF nutzen: Richte eine Web Application Firewall (z. B. Cloudflare, Wordfence oder ModSecurity) ein, um bekannte Injection-Pattern am Edge abzufangen.
   
3. Backups prüfen: Wenn du eine Shell im System hattest, reicht „drüber-patchen“ oft nicht mehr. Dann gilt: System aus einem sauberen Backup vor dem 17. Juli wiederherstellen und alle Keys in der wp-config.php rotieren!

Stay safe & happy patching! Wie sieht’s bei euch aus? Schon alle Instanzen durchgepatcht oder habt ihr schon verdächtige Zugriffe im Log entdeckt? Dann aber los!