wp2shell: Codeausführung ohne Anmeldung in WordPress und wie Sie sie blockieren
wp2shell ist eine Kette im WordPress-Kern, über die Angreifer ohne Anmeldung Code auf dem Server ausführen können, gebildet aus den zwei Lücken CVE-2026-63030 und CVE-2026-60137. WordPress hat sie am 17. Juli 2026 mit den Versionen 7.0.2, 6.9.5 und 6.8.6 geschlossen, und schon wenige Stunden später liefen die ersten Angriffe.
Aktualisieren Sie zuerst den WordPress-Kern, denn nur der Patch beseitigt den Fehler. ReportedIP Hive blockiert das Angriffsmuster seit Version 2.1.25 vom 19. Juli 2026 in jedem Tarif, auch im kostenlosen. Das schützt Websites, die noch nicht gepatcht sind, und fängt Varianten des Angriffs ab.
Was ist wp2shell?
wp2shell ist der Name für zwei Schwachstellen im WordPress-Kern, die zusammen ausgenutzt werden. Keine der beiden führt allein zur Codeausführung. Verkettet bringen sie eine anonyme Anfrage bis zu einem neuen Administratorkonto.
- CVE-2026-60137 (SQL-Injection). WordPress bereinigt den Parameter
author__not_invonWP_Querynicht ausreichend. In der REST-API wird er überauthor_excludebefüllt. Allein ist die Lücke nur erreichbar, wenn ein Plugin oder Theme ungeprüfte Eingaben an diesen Parameter weitergibt. - CVE-2026-63030 (Routenverwechslung im REST-Batch). Der Batch-Endpunkt
/wp-json/batch/v1prüft und verteilt Teilanfragen in zwei getrennten Schleifen. Eine Teilanfrage mit fehlerhaftem Pfad bringt die beiden Listen aus dem Takt, sodass eine Anfrage unter dem Handler einer anderen Route läuft. So erreicht der angreifbare Parameter ohne Anmeldung die Beitragsabfrage.
Welche WordPress-Versionen sind betroffen?
Die Routenverwechslung kam mit WordPress 6.9, die vollständige Kette funktioniert deshalb nur unter 6.9 und 7.0. Die SQL-Injection allein reicht bis 6.8 zurück. Die offiziellen Release Notes zu WordPress 7.0.2 nennen die Korrekturen.
| Zweig | Betroffen | Behoben in | Vollständige Kette |
|---|---|---|---|
| 7.0 | 7.0.0 bis 7.0.1 | 7.0.2 | Ja |
| 6.9 | 6.9.0 bis 6.9.4 | 6.9.5 | Ja |
| 6.8 | 6.8.0 bis 6.8.5 | 6.8.6 | Nein |
WordPress.org hat betroffenen Websites über das Auto-Update-System ein Zwangs-Update ausgeliefert. Websites mit abgeschalteten automatischen Updates, oder bei einem Hoster, der Kern-Updates zurückhält, bleiben offen, bis jemand sie von Hand aktualisiert. Die CISA hat beide CVEs am 21. Juli 2026 in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen, die Details stehen im NVD-Eintrag zu CVE-2026-63030.
Wie kommt der Angriff bis zur Shell?
Jeder Schritt der Kette ist eine POST-Anfrage an den Batch-Endpunkt, entweder an /wp-json/batch/v1 oder an ?rest_route=/batch/v1. In der Anfrage löst ein fehlerhafter Teilpfad die Routenverwechslung aus, und ein verschachtelter Batch trägt die SQL-Injection. Die Injection liest Daten aus der Datenbank, und die folgenden Anfragen legen über die REST-Benutzerroute einen neuen Administrator an. Mit einem Admin-Konto führt der Upload eines Plugins zur Codeausführung auf dem Server.
Patchstack registrierte die ersten Angriffsversuche rund 90 Minuten nach dem Release von 7.0.2. Bis zum 22. Juli 2026 hatte Patchstack mehr als 65.000 Versuche von über 1.500 IP-Adressen blockiert, 97 Prozent davon gegen den Batch-Endpunkt.
Wie viele wp2shell-Angriffe sieht ReportedIP?
Unsere Honeypot-Server erkennen wp2shell-Anfragen seit dem 5. September 2026 als eigene Angriffsart. Vom 5. bis 28. September 2026 haben sie 601 Meldungen zu 347 verschiedenen IP-Adressen abgegeben, insgesamt 3.196 protokollierte Anfragen. 580 der 601 Meldungen enthielten den verschachtelten Batch, ohne den der Angriff nicht funktioniert. Am 29. September 2026 hatten 51 der 347 Adressen einen Confidence-Score von 75 oder mehr, die Schwelle für die ReportedIP-Blacklist.
Der Angriff läuft auch mehr als zwei Monate nach dem Patch weiter. Scanner testen jede WordPress-Website, die sie finden, weil manche Websites noch ungepatcht sind. Der Angriffsbericht Mai bis Juli behandelt die Wochen rund um die Veröffentlichung.
Wie blockiert ReportedIP Hive wp2shell?
Die Hive-Firewall prüft jede Anfrage von Besuchern, die nicht angemeldet sind. Sie untersucht URL, User-Agent und Request-Body, bevor WordPress die Anfrage bearbeitet. Mit eingeschaltetem Erweitertem Schutz läuft die Prüfung sogar, bevor WordPress lädt. Seit Version 2.1.25 liest die Firewall den Body roh und URL-dekodiert, sodass eine kodierte Nutzlast in einem JSON-Batch für dieselben Signaturen sichtbar ist.
Version 2.1.25 brachte zwei Regeln, die auf die Struktur des Angriffs zielen statt auf ein einzelnes Schlüsselwort:
waf_rest_batch_desyncerkennt die fehlerhaften Teilpfade, die der Batch-Parser ablehnt, etwa mehrere führende Schrägstriche oder ein Schema mit leerem Host. Wer einen fehlerhaften Pfad gegen einen anderen tauscht, kommt trotzdem nicht durch.waf_rest_batch_nestederkennt eine Teilanfrage, deren Body selbst ein Batch ist. Auf diese Verschachtelung kann der Angriff nicht verzichten, ohne die Routenverwechslung zu verlieren.waf_sqli_unionblockierte dieUNION SELECT-Injection, auf die der Schritt zur Admin-Anlage angewiesen ist, schon vor 2.1.25.
Alle drei Regeln gehören zu den kostenlosen Grundregeln, die im Plugin mitgeliefert werden. Sie wirken deshalb in jedem Tarif und ohne Regel-Synchronisierung. Websites mit Priority-Sync im Tarif Professional erhalten dieselben Regeln über die signierte Regelauslieferung und können die tieferen Signaturen der Paranoia-Level 2 und 3 zuschalten. In unserer Testsuite passieren normale Batch-Aufrufe, protokollrelative URLs und absolute URLs beide Batch-Regeln. Der Leitfaden zur WordPress-Firewall erklärt Regelstufen, Ausnahmen und die Sperrseite.
Was sollten WordPress-Admins jetzt tun?
- Prüfen Sie die Kernversion jeder Website und aktualisieren Sie auf 7.0.2, 6.9.5 oder 6.8.6 oder neuer.
- Suchen Sie nach Administratorkonten, die niemand aus Ihrem Team angelegt hat, und nach Plugins, die Sie nicht installiert haben.
- Aktualisieren Sie ReportedIP Hive unter Plugins auf die aktuelle Version, oder klicken Sie in der Plugin-Zeile auf Nach Update suchen.
- Klicken Sie auf Professional-Websites auf der Regelseite auf Jetzt synchronisieren, um den aktuellen Regelsatz sofort zu holen.
Die Firewall-Dokumentation beschreibt die Regelauslieferung und wie Sie eine versehentlich blockierte Anfrage freigeben.
Häufige Fragen
Ersetzt ReportedIP Hive das Update des WordPress-Kerns?
Hive ersetzt das Kern-Update nicht, denn nur der Patch beseitigt den Fehler. Die Firewall blockiert das Anfragemuster, bevor es den verwundbaren Code erreicht. Das schützt eine Website in der Zeit bis zum Patch und fängt Varianten des Angriffs ab. Jede Website sollte trotzdem WordPress 7.0.2, 6.9.5 oder 6.8.6 oder neuer nutzen.
Sind kostenlose Hive-Websites gegen wp2shell geschützt?
Kostenlose Websites sind geschützt, sobald sie Hive 2.1.25 oder neuer nutzen. Beide Batch-Regeln und die UNION-SELECT-Regel gehören zu den Grundregeln, die im Plugin mitgeliefert werden, deshalb braucht es weder einen bezahlten Tarif noch eine Regel-Synchronisierung. Der Tarif Professional ergänzt tiefere Signaturen und tägliche Regel-Updates.
Blockieren die neuen Regeln legitime REST-Batch-Anfragen?
Normale Batch-Anfragen kommen durch, weil die Regeln nur fehlerhafte Teilpfade und einen im Body einer Teilanfrage verschachtelten Batch erkennen. Batch-Aufrufe des Block-Editors haben keine dieser Formen. Sendet ein Plugin auf Ihrer Website doch eine, können Sie für diese Regel im Hive-Ereignisprotokoll eine Ausnahme anlegen.