wp2shell: WordPress-Hack erkennen und richtig bereinigen

Die WordPress-Kernlücke wp2shell wird aktiv ausgenutzt. Woran Sie einen Befall erkennen, was Angreifer auf gekaperten Seiten anrichten und wie Sie sauber bereinigen.

wp2shell ist eine Verkettung von zwei Sicherheitslücken im WordPress-Kern, über die Angreifer ohne Anmeldung Schadcode auf einer Standardinstallation ausführen können. Betroffen sind die Versionen 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1, die Lücke wird seit Mitte Juli 2026 aktiv und automatisiert ausgenutzt. Wenn Ihre Seite auf einer dieser Versionen lief, reicht das Update allein nicht: Sie müssen prüfen, ob die Seite bereits übernommen wurde, denn eine einmal abgelegte Hintertür überlebt jedes Update.

Das Wichtigste in Kürze

wp2shell kombiniert zwei Kernlücken (CVE-2026-63030 und CVE-2026-60137) zu einer Codeausführung ohne Login, angreifbar über die REST-Schnittstelle /wp-json/batch/v1.
Verwundbar: WordPress 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1. Abgesichert: 6.9.5, 7.0.2 und 6.8.6. Ältere 6.8er sind teilweise betroffen.
Ausgenutzt wird seit dem 17. Juli 2026, die US-Behörde CISA führt die Lücke seit dem 21. Juli in ihrem Katalog aktiv ausgenutzter Schwachstellen.
Typische Spuren: Antworten mit HTTP-Status 207 auf Batch-Anfragen in den Server-Logs, die Kennungen wp2shell oder rezwp2shell im User-Agent, neue Admin-Konten, unbekannte Plugins.
Ein Update entfernt keine Hintertür. Wer verwundbar war, muss die Seite forensisch prüfen oder aus einem sauberen Backup von vor dem 17. Juli neu aufbauen.

Was ist wp2shell genau?

Hinter dem Namen stecken zwei Schwachstellen, die einzeln unangenehm und in Kombination fatal sind. Die erste (CVE-2026-60137) ist eine SQL-Injection im Batch-Endpunkt der REST-Schnittstelle: Über den Parameter author__not_in lassen sich Datenbankinhalte auslesen, darunter die Passwort-Hashes der Administratoren. Die zweite (CVE-2026-63030) ist eine Logikschwäche im selben Batch-Prozessor, der eingehende Anfragen in zwei getrennten Schleifen erst prüft und dann ausführt. Zwischen Prüfung und Ausführung lässt sich die Anfrage so verändern, dass am Ende fremder Code läuft.

Entdeckt und gemeldet wurde die Kette von Sicherheitsforschern des Assetnote-Teams von Searchlight Cyber. Veröffentlicht wurde sie am 17. Juli 2026, funktionierende Angriffswerkzeuge kursierten fast unmittelbar danach. Seitdem laufen automatisierte Massen-Scans: Die Angreifer suchen nicht gezielt Ihre Seite, sie suchen jede verwundbare Seite.

Bin ich betroffen? Die Versionsfrage

WordPress-Version	Status
6.9.0 bis 6.9.4	voll verwundbar, beide Lücken
7.0.0 und 7.0.1	voll verwundbar, beide Lücken
6.8.x vor 6.8.6	teilweise betroffen (nur die SQL-Injection)
6.9.5, 7.0.2, 6.8.6 oder neuer	abgesichert

Die Version finden Sie im Backend unter Dashboard, Aktualisierungen, oder ohne Login in der Datei readme.html Ihrer Installation. Wichtig ist aber nicht nur die heutige Version, sondern die Frage, welche Version zwischen dem 17. Juli und Ihrem Update lief. Genau in diesem Fenster konnte die Seite übernommen worden sein, und dieser Zustand bleibt nach dem Update bestehen.

Woran Sie erkennen, ob Ihre Seite gehackt wurde

Die gute Nachricht: wp2shell hinterlässt vergleichsweise klare Spuren. Sicherheitsfirmen wie Wiz, Patchstack und Cloudflare haben die Angriffe analysiert und übereinstimmende Erkennungsmerkmale dokumentiert. Prüfen Sie in dieser Reihenfolge:

**Server-Logs:** Anfragen an /wp-json/batch/v1 oder /?rest_route=/batch/v1, auf die der Server mit HTTP-Status 207 (Multi-Status) geantwortet hat. Diese Kombination gilt als verlässlichstes Zeichen eines erfolgreichen Angriffs.
**User-Agents:** die Zeichenketten wp2shell oder rezwp2shell in den Zugriffsprotokollen, außerdem auffällige author__not_in-Parameter in REST-Anfragen.
**Benutzerkonten:** Administrator-Konten, die Sie nicht angelegt haben. Auch unauffällige Namen prüfen, Angreifer imitieren gern bestehende Muster.
**Plugins:** Einträge in der Plugin-Liste und Ordner unter wp-content/plugins, die niemand installiert hat. Eine der beobachteten Varianten tarnt sich als eigenes Plugin mit einem versteckten REST-Endpunkt.
**Dateiänderungen:** PHP-Dateien mit Änderungsdatum nach dem 17. Juli 2026, die Sie nicht erklären können, besonders in wp-content/uploads und in Plugin-Ordnern.

Was Angreifer auf übernommenen Seiten anrichten

Aus den dokumentierten Fällen ergeben sich drei wiederkehrende Muster, vom Minimalen bis zum Vollausbau. Die einfachste Variante ist ein einzeiliges PHP-Skript, das beliebige Befehle über einen Anfrage-Parameter entgegennimmt: unscheinbar, winzig, leicht zu übersehen. Die zweite ist eine rund 150 Kilobyte große, verschleierte Webshell mit Dateimanager, Datenbankzugriff und Netzwerk-Scanner, also ein komplettes Fernwartungswerkzeug für den Angreifer. Die dritte tarnt sich als WordPress-Plugin und richtet einen eigenen versteckten REST-Endpunkt ein, über den kodierte Befehle laufen.

Für Besucher wird es dann gefährlich, wenn die gekaperte Seite als Waffe weiterverwendet wird. Dokumentiert sind eingeschleuste Skripte, die Zugangsdaten abgreifen, gefälschte Anmeldefenster im Stil von Microsoft 365 und Google einblenden und Besucher auf Server der Angreifer umleiten. Ihre Seite verteilt dann Phishing an genau die Menschen, die Ihnen vertrauen: Kunden, Interessenten, Geschäftspartner.

Richtig bereinigen: so gehen Sie vor

**1. Sofort aktualisieren** auf 6.9.5, 7.0.2 oder 6.8.6, damit nicht während der Bereinigung erneut jemand hereinkommt.
**2. Spuren sichern:** Server-Logs und eine Kopie des aktuellen Zustands aufheben, bevor Sie etwas löschen. Ohne Logs lässt sich später nicht klären, was passiert ist und ob Daten abgeflossen sind.
**3. Prüfen** nach der Liste oben: Logs, Konten, Plugins, Dateiänderungen, dazu der Scanner aus dem Plugin-Verzeichnis.
**4. Bei Befall:** am zuverlässigsten ist ein sauberes Backup von vor dem 17. Juli 2026, neu aufgesetzt und sofort auf die abgesicherte Version gebracht. Einzelne Dateien von Hand zu putzen scheitert oft an der zweiten, übersehenen Hintertür.
**5. Alle Zugänge erneuern:** sämtliche WordPress-Passwörter, die Sicherheitsschlüssel in der wp-config.php (Salts), Datenbank- und FTP-Passwörter. Die Angreifer konnten Passwort-Hashes auslesen, behandeln Sie sie als verbrannt.
**6. Bei Kundendatenbezug an die Meldepflicht denken:** Sind personenbezogene Daten betroffen, greift Artikel 33 DSGVO mit der 72-Stunden-Frist für die Meldung an die Aufsichtsbehörde.

Die ehrliche Einordnung

wp2shell ist kein Grund, WordPress zu verteufeln. Es ist ein Grund, die eigene Update- und Prüf-Routine ernst zu nehmen. Die Lücke wurde schnell gepatcht, die Erkennungsmerkmale sind gut dokumentiert, und wer zeitnah aktualisiert hat, ist mit hoher Wahrscheinlichkeit davongekommen. Das strukturelle Problem bleibt trotzdem: Eine Software, die auf Millionen Seiten identisch läuft, macht jede Kernlücke sofort zum Massenereignis. Warum ich für viele meiner Kunden deshalb auf Websites ohne WordPress-Unterbau setze und wie Angreifer bei WordPress grundsätzlich vorgehen, habe ich in eigenen Beiträgen beschrieben.

Die meisten gehackten Seiten, die bei mir landen, sind nicht an einer raffinierten Attacke gescheitert, sondern daran, dass sich monatelang niemand zuständig gefühlt hat. Eine Lücke wie wp2shell trifft dann keine Website, sie trifft eine Wartungslücke.

Carlo Krämer, Mediengestalter (IHK), CarloMedia

Wenn Sie das nicht selbst leisten wollen: Genau dafür gibt es meine WordPress-Wartung mit Sicherheits-Checks und getesteten Updates. Dann ist bei der nächsten Lücke dieser Art jemand dran, bevor die Scanner der Angreifer es sind.

Quellen und weiterführende Informationen

Häufige Fragen

Meine Seite läuft auf WordPress 6.8, bin ich sicher?

Teilweise. Die 6.8er-Reihe ist von der vollständigen Angriffskette nicht betroffen, die SQL-Injection funktioniert dort aber bis einschließlich 6.8.5. Damit lassen sich Datenbankinhalte wie Passwort-Hashes auslesen, was für sich genommen schlimm genug ist. Aktualisieren Sie auf 6.8.6 oder direkt auf die aktuelle Version.

Ich habe sofort aktualisiert. Muss ich trotzdem prüfen?

Ja, wenn Ihre Seite zwischen dem 17. Juli 2026 und dem Update auf einer verwundbaren Version erreichbar war. Die Massen-Scans begannen fast unmittelbar nach Veröffentlichung der Lücke, das Zeitfenster kann also kurz gewesen sein und trotzdem gereicht haben. Ein Blick in die Logs auf Batch-Anfragen mit Status 207 schafft in wenigen Minuten Klarheit.

Reicht es, das Schadplugin zu löschen, wenn ich eines finde?

Nein, darauf sollten Sie sich nicht verlassen. In den dokumentierten Fällen legen Angreifer häufig mehrere Zugänge an: ein sichtbares Plugin, dazu eine unauffällige Datei woanders und ein zusätzliches Admin-Konto. Wer nur den offensichtlichen Fund entfernt, lässt die zweite Tür offen. Deshalb ist das saubere Backup von vor dem Befall der verlässlichere Weg.

Kann ich die REST-Schnittstelle nicht einfach komplett abschalten?

Davon rate ich ab, denn WordPress selbst, der Editor und viele Plugins brauchen die REST-Schnittstelle für den normalen Betrieb. Das Abschalten des Batch-Endpunkts war als Notbehelf vor dem Patch im Gespräch, ist aber seit den abgesicherten Versionen unnötig. Das Update ist die richtige Lösung, nicht der Umbau am Kern.

Woher weiß ich, ob über meine Seite Besucherdaten abgegriffen wurden?

Sicher wissen können Sie es nur über die Logs und eine forensische Prüfung, deshalb gehört das Sichern der Protokolle an den Anfang jeder Bereinigung. Dokumentiert sind Fälle, in denen gekaperte Seiten gefälschte Anmeldefenster einblendeten und Zugangsdaten von Besuchern abgriffen. Wenn sich ein Abfluss personenbezogener Daten nicht ausschließen lässt, gilt die Meldepflicht nach Artikel 33 DSGVO binnen 72 Stunden an die Aufsichtsbehörde.

Mein Hoster hat mir eine Warnung geschickt. Ist die echt?

Gut möglich, viele Hoster haben wegen wp2shell aktiv gewarnt. Klicken Sie trotzdem keine Links aus der Mail, sondern loggen Sie sich direkt beim Hoster und in WordPress ein und prüfen Sie die Version selbst. Phishing-Wellen reiten gern auf echten Sicherheitsvorfällen mit, gerade weil die Empfänger dann verunsichert sind.

Wie verhindere ich, dass mich die nächste Lücke dieser Art trifft?

Drei Dinge: Updates zeitnah einspielen, am besten mit automatischen Sicherheitsupdates für den Kern. Regelmäßige Backups, die getrennt von der Seite liegen, damit ein sauberer Stand zum Zurückspielen existiert. Und jemanden, der sich zuständig fühlt, ob Sie selbst mit fester Routine oder eine betreute Wartung. Die Lücke selbst können Sie nicht verhindern, den wochenlang unbemerkten Befall schon.