Blog CloudflareNews

wp2shell: kritische WordPress-Lücke wird aktiv angegriffen

By Sven Launspach 21 July 2026 5 min read

Zwei verkettete Lücken im WordPress-Core, zusammen als wp2shell bekannt, erlauben nicht angemeldeten Angreifern die Codeausführung. Angriffe laufen bereits. Wer nicht sofort patchen kann, schließt die Lücke mit Cloudflare am Edge, ohne auf das nächste Wartungsfenster zu warten.

wp2shell: die kritische WordPress-Kernluecke wird aktiv angegriffen. KAEMI und Cloudflare schirmen den Exploit mit Edge-WAF und virtuellem Patching am REST-API-Batch-Endpunkt ab, Anwendung geschuetzt

Note: This article is currently available in German only. An English translation is on its way. Open the German original.

WordPress steht hinter einem großen Teil des Webs. Eine Lücke im Kern trifft deshalb nicht einzelne Seiten, sie trifft Millionen Installationen auf einmal. Genau das ist mit wp2shell passiert. Seit dem 17. Juli 2026 ist eine Schwachstellenkette öffentlich, für die binnen Stunden ein Exploit kursierte und die inzwischen aktiv ausgenutzt wird.

Das eigentliche Problem ist nicht der fehlende Patch. Den gibt es. Das Problem ist die Zeit dazwischen: die Tage zwischen „Exploit ist öffentlich" und „Update ist überall sauber ausgerollt". In genau diesem Fenster passieren die Angriffe. Und dieses Fenster lässt sich schließen, bevor der erste Server neu startet.

Ob eine Ihrer Installationen betroffen ist, prüfen Sie in Sekunden mit dem kostenlosen Checker der Entdecker : Domain eingeben, das Tool sagt Ihnen, ob Ihre WordPress-Seite angreifbar ist.

Was ist wp2shell?

wp2shell ist kein Plugin-Fehler, sondern eine Kette aus zwei Schwachstellen im WordPress-Core, die zusammen zur Codeausführung führen, ganz ohne Anmeldung.

CVE-2026-63030: eine Verwechslung von Routen im REST-API-Batch-Endpunkt (/wp-json/batch/v1), eingeführt mit WordPress 6.9. Das ist der Teil, der die Codeausführung möglich macht.
CVE-2026-60137: eine SQL-Injection im Parameter author__not_in von WP_Query, vorhanden ab WordPress 6.8.

Verkettet auf WordPress 6.9.0 bis 7.0.1 ergibt das einen nicht authentifizierten Weg bis zur Codeausführung. Das BSI bewertet die Kette mit einem CVSS-Wert von 9.8, also kritisch. Angreifer nutzen den Zugang, um dauerhafte Webshells abzulegen. Eine Webshell ist eine kleine Datei, die dem Angreifer die Fernsteuerung des Servers gibt. Daher der Name wp2shell.

Entdeckt hat die Kette das Sicherheitsteam von Searchlight Cyber. Sie trifft Standard-Installationen, es braucht kein anfälliges Plugin. Betroffen sind die Versionen 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1. Versionen bis einschließlich 6.8.5 sind nicht betroffen. Behoben ist das Problem in 6.9.5 und 7.0.2, veröffentlicht am 17. Juli 2026, für ältere Zweige gibt es einen Backport in 6.8.6.

Warum reicht schnelles Patchen nicht?

Weil „schnell patchen" in der Praxis selten schnell ist. Zwischen dem Bekanntwerden einer Lücke und einem sauber ausgerollten Update vergehen auch bei sorgfältigen Teams oft Tage. Die Gründe sind bekannt:

Kompatibilität: Ein Core-Update kann Plugins oder das Theme brechen. Verantwortungsvoll heißt: erst im Staging testen, dann produktiv gehen.
Wartungsfenster: Produktive Seiten werden nicht mitten am Tag aktualisiert. Freigaben und Change-Prozesse kosten Zeit.
Menge: Agenturen und Unternehmen betreiben oft dutzende oder hunderte WordPress-Instanzen. Die lassen sich nicht alle gleichzeitig anfassen.
Abhängigkeiten: gehostete Umgebungen mit festgesetzten Versionen, angepasste Cores, deaktivierte automatische Updates.

WordPress.org hat für betroffene Versionen erzwungene automatische Updates aktiviert. Das hilft, deckt aber längst nicht alles ab. Wer sich allein darauf verlässt, verlässt sich auf etwas, das er nicht kontrolliert. Das Ergebnis: Der verwundbare Code bleibt eine Weile verwundbar, auch bei Teams, die alles richtig machen wollen. Gebraucht wird also etwas, das den Angriffsweg sofort schließt, unabhängig vom Patch-Zyklus.

Wie schützt Cloudflare vor der Lücke, bevor Sie patchen?

Über virtuelles Patchen. Dabei fängt eine Regel am Edge den Exploit-Request ab, bevor er WordPress überhaupt erreicht. Der Code selbst bleibt zunächst unverändert, aber der Weg dorthin ist zu.

Cloudflare hat für wp2shell eine Notfallregel in der Web Application Firewall ausgerollt, abgestimmt mit dem WordPress-Sicherheitsteam, am 17. Juli 2026 um 17:03 UTC, also bevor die Details öffentlich wurden. Wer die Managed Rules einsetzt, war dadurch automatisch geschützt, in vielen Fällen früher, als die Betreiber überhaupt von der Lücke wussten. Sogar der kostenlose Regelsatz greift hier. Die Regeln setzen an zwei Stellen an: an den Parametern der SQL-Injection und an den Anfragen, die die Codeausführung über die REST-API auslösen.

Der ehrliche Zusatz gehört dazu: Das ersetzt den Patch nicht, es überbrückt die Zeit bis dahin. Cloudflare nennt es „defense in depth while you patch". Genau darum geht es: das Risiko sofort senken und dann in Ruhe patchen. Die technischen Details hat Cloudflare im eigenen Blog beschrieben .

Die Cloudflare-Bausteine, die hier greifen

Vier Komponenten spielen bei genau diesem Angriff zusammen:

Web Application Firewall mit Managed Rules : das Herzstück des virtuellen Patchens. Die Notfallregel gegen wp2shell landete hier automatisch und blockiert die Exploit-Anfragen an den Batch-Endpunkt.
Rate Limiting : bremst die massenhaften Ausnutzungsversuche, die nach Veröffentlichung eines Exploits typischerweise über die betroffenen Endpunkte hereinrollen.
Bot Management : Die Ausnutzung läuft fast vollständig automatisiert über Scanner und Botnetze. Eine Bewertung des Bot-Verhaltens fängt diese Wellen ab, bevor sie Wirkung entfalten.
DDoS-Schutz : Dieselben Endpunkte werden nach einer Veröffentlichung oft mit Anfragen überzogen. Der immer aktive Schutz auf Ebene 7 hält das ab.

Jede dieser Komponenten senkt das Risiko. Keine ersetzt das Update. Die Reihenfolge lautet: sofort abschirmen, dann geordnet patchen.

Was Sie jetzt konkret tun sollten

Betroffenheit prüfen. Die Entdecker stellen unter wp2shell.com einen kostenlosen Checker bereit: Domain eingeben, das Tool sagt Ihnen, ob Ihre WordPress-Installation angreifbar ist.
Version prüfen und patchen. Läuft eine Installation auf 6.9.0 bis 6.9.4 oder 7.0.0 bis 7.0.1, gehört sie sofort auf 6.9.5 beziehungsweise 7.0.2, ältere Zweige auf 6.8.6.
Automatischen Updates nicht blind vertrauen. Prüfen Sie aktiv, ob das Update wirklich angekommen ist.
Eine WAF davorsetzen. Mit aktiven Managed Rules greift die Notfallregel und schließt den Angriffsweg, auch während Sie noch testen und ausrollen.
Auf Kompromittierung prüfen. Achten Sie auf unbekannte PHP-Dateien in den Upload-Verzeichnissen, neu angelegte Administratorkonten und auffällige Anfragen an /wp-json/batch/v1 in den Logs. wp2shell hinterlässt Webshells, die auch nach dem Patch aktiv bleiben.
Sichern und dokumentieren. Ziehen Sie ein Backup, bevor Sie eingreifen, und halten Sie fest, was Sie geprüft haben.

Wie KAEMI Sie dabei unterstützt

KAEMI ist Cloudflare-Partner (Authorized Service Delivery Partner) und richtet genau diesen Schutz für Sie ein. Konkret heißt das: Wir setzen die Web Application Firewall vor Ihre Seiten, prüfen, ob die Managed Rules die aktuelle Bedrohung abdecken, justieren Rate Limiting und Bot-Regeln auf Ihren Verkehr und sehen uns Ihre WordPress-Installationen auf Spuren einer Kompromittierung an.

Das geht auf zwei Wegen. Einmalig, damit Ihre Seiten jetzt geschützt sind, während Sie in Ruhe patchen. Oder dauerhaft als Managed Service, bei dem wir die Sicherheit am Edge laufend für Sie betreiben und überwachen. Beides bündeln wir in unserer Application Security und in unseren Cloudflare-Services .

Der Punkt, auf den es bei wp2shell ankommt: Eine WAF steht innerhalb weniger Stunden vor Ihrer Seite und schließt das Zeitfenster, bevor der Patch überall durch ist. Wenn Sie mehrere Seiten betreiben oder unsicher sind, ob Sie betroffen sind, sprechen Sie uns an . Wir schauen gemeinsam drauf, unverbindlich.