wp2shell: Sind Sie betroffen? Prüfen, patchen, dauerhaft absichern

AKTUELLE SICHERHEITSLÜCKE

Die Mitte Juli 2026 bekannt gewordene WordPress-Schwachstelle „wp2shell“ erlaubt es einem nicht angemeldeten Angreifer, aus der Ferne Code auf dem Server auszuführen – ohne Benutzerkonto, ohne Zutun eines Administrators, auch bei einer Standardinstallation ganz ohne zusätzliche Plugins. Ein Proof-of-Concept ist öffentlich. Dieser Beitrag beantwortet zuerst die dringende Frage – sind Sie betroffen und was tun Sie jetzt – und erklärt danach, warum Patchen allein das Problem nicht vollständig löst.

Sind Sie betroffen? So prüfen Sie es in 30 Sekunden

Betroffen sind die WordPress-Versionen 6.8 bis 7.0.1. Abgesichert sind 6.8.6, 6.9.5 und 7.0.2 sowie alles Neuere.

Ihre installierte Version finden Sie auf drei Wegen:

• Im Dashboard: Unter Dashboard → Aktualisierungen steht die aktuell laufende Version ganz oben.
• Im Fuß der Admin-Oberfläche: Rechts unten auf fast jeder Seite im Backend wird die Versionsnummer eingeblendet.
• Auf dem Server: In der Datei wp-includes/version.php steht die Version in der Zeile $wp_version.

Liegt Ihre Version zwischen 6.8 und 7.0.1, war Ihre Installation verwundbar – unabhängig davon, welche Plugins oder welches Theme Sie einsetzen.

Was jetzt zu tun ist

1. Aktualisieren. Auf 6.8.6, 6.9.5 oder 7.0.2 – je nachdem, auf welchem Versionsstrang Sie sind. Das ist der eigentliche, dauerhafte Fix und sollte nicht aufgeschoben werden.
2. Prüfen, ob das Update wirklich durchgelaufen ist. WordPress hat für betroffene Installationen Zwangsupdates aktiviert – die greifen aber nicht überall. Verlassen Sie sich nicht auf die Annahme, sondern sehen Sie nach.
3. Nach Spuren sehen. Da der Proof-of-Concept öffentlich ist und automatisierte Scans seit Juli laufen: Prüfen Sie auf unbekannte Administratorkonten, veränderte oder neu hinzugekommene PHP-Dateien im Web-Verzeichnis und auffällige geplante Aufgaben (Cron). Ein Update schließt die Lücke – es entfernt aber nichts, was vorher schon hereingekommen ist.
4. Das Zeitfenster strukturell schließen. Dazu unten mehr.

Wenn Sie beim dritten Punkt unsicher sind oder etwas gefunden haben: Nicht neu starten, nicht löschen, nicht überschreiben. Im akuten Verdachtsfall erreichen Sie uns unter +49 5362 975 28 66.

Was bei wp2shell konkret passiert ist

Am 17. Juli 2026 veröffentlichte WordPress ein Notfall-Sicherheitsupdate (Version 7.0.2), das zwei kombinierbare Schwachstellen im Core schließt:

• CVE-2026-63030: ein Logikfehler bei der Verarbeitung von Batch-Anfragen der WordPress-REST-API, konkret über die Route /wp-json/batch/v1
• CVE-2026-60137: eine SQL-Injection im WordPress-Core

Einzeln betrachtet ist bereits jede der beiden Schwachstellen ein ernstes Problem. In Kombination erlauben sie einem nicht angemeldeten, entfernten Angreifer, ohne gültiges Benutzerkonto und ohne jede Interaktion eines Administrators beliebigen Code auf dem Server auszuführen. Das BSI hat die Lücke mit der Warnstufe 3 von 4 („Orange“) eingestuft.

Warum „einfach updaten“ in der Praxis nicht reicht

WordPress hat für betroffene Installationen automatische Zwangsupdates aktiviert – ein sinnvoller Schritt angesichts der Schwere der Lücke. Trotzdem bleibt eine reale Lücke im Zeitfenster:

• Nicht jede Website aktualisiert sich zuverlässig automatisch, etwa wegen inkompatibler Plugins, deaktivierter Auto-Updates oder gemanagter Hosting-Umgebungen mit eigenen Update-Zyklen.
• Zwischen Veröffentlichung einer Schwachstelle und dem tatsächlichen Einspielen des Patches liegt immer ein Zeitfenster – bei wp2shell zusätzlich verschärft durch einen bereits verfügbaren Proof-of-Concept, den automatisierte Angreifer innerhalb von Stunden in Scan-Skripte einbauen.
• Ältere, aus guten Gründen (Kompatibilität, individuelle Anpassungen) nicht sofort aktualisierte Installationen bleiben in genau diesem Fenster verwundbar.

Genau hier setzt eine Web Application Firewall (WAF) an – und genau hier zeigt sich auch, warum es einen Unterschied macht, wer eine solche Regel konfiguriert. Eine WAF-Regel, die zu breit greift, blockiert legitime Anfragen; eine, die zu eng greift, lässt die eigentliche Lücke offen.

Wie eine WAF diese konkrete Lücke schließt

Eine Web Application Firewall prüft eingehende HTTP-Anfragen, bevor sie die Anwendung – hier: WordPress – überhaupt erreichen. Für wp2shell bedeutet das konkret:

Virtuelles Patchen der Schnittstelle. Der Angriffsweg führt über eine spezifische REST-API-Route mit einem bestimmten Anfragemuster. Eine WAF kann diese Route gezielt sperren oder nur für erwartetes, unverdächtiges Anfragemuster freigeben – unabhängig davon, ob der eigentliche WordPress-Kern schon aktualisiert wurde. Die Schwachstelle bleibt im Code vorhanden, wird aber technisch nicht erreichbar.

Erkennung des SQL-Injection-Musters. Der zweite Teil der Angriffskette basiert auf einer SQL-Injection. Klassische WAF-Regelsätze erkennen typische Injection-Muster in Parametern und blockieren die Anfrage, bevor sie die Datenbank erreicht – unabhängig vom konkreten CVE.

Reduktion der Angriffsfläche insgesamt. Eine WAF schützt nicht nur gegen die eine, aktuell bekannte Lücke, sondern gegen die Angriffsklasse: unautorisierte Zugriffe auf sensible REST-API-Endpunkte, verdächtige Batch-Anfragen, bekannte Exploit-Signaturen. Genau das ist der Unterschied zwischen reaktivem Patchen einzelner CVEs und einer strukturell kleineren Angriffsfläche.

Hosting, das die Lücke schließt, bevor Sie patchen

Der wirksamste Weg, dieses Zeitfenster dauerhaft zu schließen, liegt eine Ebene tiefer als die einzelne Website: auf dem Server selbst. Lösungen wie Imunify kombinieren WAF-Funktionalität mit Malware-Scanning, Intrusion-Detection und automatisiertem Patch-Management – nicht pro Website, sondern für die gesamte Hosting-Umgebung. Für Betreiber mehrerer WordPress-Installationen – Agenturen, Unternehmen mit mehreren Marken-Websites, Verbände mit Untergliederungen – heißt das: Eine kritische Lücke wie wp2shell wird zentral über alle Installationen hinweg abgesichert, statt jede Website einzeln und manuell zu prüfen.

Genau so ist unser Managed Hosting aufgebaut:

• Isolierte Umgebungen: Jede Website läuft getrennt. Eine kompromittierte Installation reißt nicht die Nachbarn mit – bei vielen günstigen Shared-Hostern ist genau das der Normalfall.
• Virtuelles Patchen zentral: Bekannte Lücken in WordPress-Core und -Plugins werden auf Serverebene geschlossen, bevor das Update eingespielt ist.
• Malware-Scanning im Dauerbetrieb: Veränderte Dateien und eingeschleuste Skripte fallen auf, statt monatelang unbemerkt zu laufen.
• Tägliche Sicherung außerhalb des Servers: Ein Backup, das auf demselben System liegt, ist im Ernstfall genauso kompromittiert wie die Website.
• Betreut statt nur bereitgestellt: Bei einer Lücke dieser Schwere handeln wir, ohne dass Sie ein Ticket aufmachen müssen.

Der Mechanismus ist im Kern derselbe wie bei einer klassischen WAF: verdächtige Anfragemuster werden erkannt und blockiert, bevor sie die verwundbare Anwendungslogik erreichen – nur eben zentral für die gesamte Serverumgebung statt pro einzelner Website konfiguriert.

Häufige Fragen (FAQ)

Woran erkenne ich, ob meine WordPress-Installation von wp2shell betroffen ist? Betroffen sind die Versionen 6.8 bis 7.0.1. Sicher sind 6.8.6, 6.9.5 und 7.0.2. Die installierte Version steht im Dashboard unter „Aktualisierungen“, rechts unten im Backend oder in wp-includes/version.php.

Gibt es einen Scanner oder Test für wp2shell? Für die reine Frage „bin ich verwundbar?“ genügt der Versionsabgleich oben – dafür braucht es kein Werkzeug. Was ein Versionscheck nicht beantwortet: ob jemand die Lücke vorher bereits ausgenutzt hat. Diese Frage beantwortet nur eine Prüfung des Systems selbst – veränderte Dateien, unbekannte Konten, auffällige Cron-Jobs – und genau das übernimmt serverseitiges Malware-Scanning dauerhaft.

Ich habe gepatcht. Bin ich jetzt sicher? Gegen diese Lücke ja. Ein Patch entfernt aber nicht, was vor dem Update bereits auf dem System gelandet ist. Wenn Ihre Installation längere Zeit ungepatcht erreichbar war, gehört eine Prüfung auf Spuren dazu.

Reicht eine WAF aus, wenn ich das WordPress-Update nicht sofort einspielen kann? Eine WAF reduziert das Risiko erheblich, ist aber eine Übergangslösung, kein Ersatz für den Patch. Sie überbrückt das Zeitfenster, sie ersetzt das Update nicht dauerhaft.

Schützt ein Standard-Sicherheitsplugin genauso gut wie eine dedizierte WAF? Viele WordPress-Sicherheitsplugins bieten grundlegenden Schutz, arbeiten aber auf Anwendungsebene innerhalb von WordPress selbst – wird die Schwachstelle vor der eigentlichen WordPress-Logik ausgenutzt, kann das zu spät sein. Eine WAF oder serverseitige Lösung prüft Anfragen bereits, bevor sie WordPress überhaupt erreichen.

Lohnt sich das auch für eine einzelne kleine Unternehmenswebsite? Ja. Automatisierte Angreifer scannen das Internet unabhängig von der Größe einer Website nach bekannten Schwachstellenmustern. Eine kleine Website ist kein geringeres, sondern oft ein leichteres Ziel, weil seltener aktiv überwacht wird.

Warum braucht die WAF-Konfiguration technische Tiefe und nicht nur ein Standard-Regelwerk? Weil eine zu allgemeine Regel entweder Angriffe durchlässt oder legitimen Traffic blockiert – etwa, wenn eine Website selbst reguläre Batch-Anfragen an die REST-API nutzt. Bei UBESAFE konfigurieren Techniker diese Regeln, die selbst tief in Netzwerk, Microsoft 365 und Serverinfrastruktur stecken, und dadurch beurteilen können, was im konkreten Betrieb normaler Traffic ist und was nicht.

Passende Leistungen von UBESAFE: Managed Hosting · Firewall & Netzwerk · Internes Audit

Fazit

wp2shell ist für die meisten Betreiber schnell erledigt: Version prüfen, aktualisieren, nach Spuren sehen. Die eigentliche Lehre liegt daneben – zwischen dem Bekanntwerden einer Lücke und dem vollständigen Rollout des Patches liegt immer ein Fenster, und beim nächsten Mal ist der Proof-of-Concept wieder schneller da als Ihr Update-Zyklus. Der Patch schließt die konkrete Lücke im Code; serverseitiger Schutz schließt das Fenster davor – und greift auch gegen Angriffsmuster, für die es noch gar kein CVE gibt.

---

Unsicher, ob Ihre WordPress-Installation sauber ist – oder es leid, bei jeder kritischen Lücke selbst hinterherzurennen? Managed Hosting von UBESAFE nimmt Ihnen genau das ab. Zum Einstieg: kostenloses Erstgespräch. Im akuten Verdachtsfall: +49 5362 975 28 66.