Warum automatisierte Angriffe jede Webseite treffen können und was WP2Shell damit zu tun hat.

WP2Shell bezeichnet eine Kombination aus zwei Sicherheitslücken im WordPress-Core, die im Juli 2026 bekannt wurde. Angreifer konnten damit ohne Login… und ohne Zutun von Betreibern Code auf dem Server ausführen. Der Angriff lief fast ausschließlich automatisiert ab, es war also egal, wie groß oder unbekannt eine Seite war.

wp2shell: Wenn aus einer WordPress-Lücke plötzlich eine Hintertür wird

Im Juli 2026 wurde es für WordPress-Betreiber unangenehm. Unter dem Namen wp2shell wurde eine Angriffskette bekannt, mit der sich Sicherheitslücken im WordPress-Core kombinieren ließen. Das besonders Kritische daran: Für den Angriff war bei den tatsächlich für die vollständige Kette anfälligen Versionen kein vorhandener Benutzeraccount notwendig. Angreifer konnten eine öffentlich erreichbare WordPress-Installation automatisiert angreifen und im schlimmsten Fall eigenen Code auf dem Server ausführen.

Und genau das macht solche Schwachstellen für Bots interessant. Sie müssen weder deine Webseite kennen noch sich speziell für dein Unternehmen interessieren. Automatisierte Scanner suchen schlicht das Internet nach verwundbaren Installationen ab.

WordPress reagierte am 17. Juli 2026 mit einem außerplanmäßigen Sicherheitsupdate. Wegen der Schwere der Lücken wurden für betroffene Installationen sogar automatische Sicherheitsupdates forciert.

Kleiner Exkurs: Was bedeutet eigentlich „wp2shell“?

Eine Webshell ist vereinfacht gesagt eine Hintertür auf einem Webserver. Gelingt es einem Angreifer, eine entsprechende PHP-Datei oder ein manipuliertes Plugin auf dem Server abzulegen, kann er darüber später Befehle ausführen – teilweise unabhängig davon, ob die ursprüngliche Sicherheitslücke längst geschlossen wurde.

Genau daher kommt der Name wp2shell: Der Angriff führt von einer verwundbaren WordPress-Installation bis zu der Möglichkeit, eine solche Shell beziehungsweise eigenen ausführbaren Code auf dem Server zu platzieren.

Das Entscheidende dabei: Ein WordPress-Update schließt die Eingangstür – eine bereits installierte Hintertür verschwindet dadurch aber nicht automatisch.

Welche WordPress-Versionen waren betroffen?

Hier lohnt es sich, genau zu unterscheiden.

WordPress 6.9.0 bis 6.9.4 sowie 7.0.0 und 7.0.1 waren für die vollständige wp2shell-Angriffskette anfällig. Behoben wurde sie mit WordPress 6.9.5 beziehungsweise 7.0.2.

Die Versionen 6.8.0 bis 6.8.5 waren ebenfalls von einer der zugrunde liegenden SQL-Injection-Schwachstellen betroffen, allerdings nicht von der vollständigen Remote-Code-Execution-Kette. Dafür erschien WordPress 6.8.6. Versionen vor WordPress 6.8 waren nach Angaben des WordPress-Projekts nicht betroffen.

Das ist ein wichtiger Unterschied: Wer im Juli eine WordPress-6.8-Installation hatte, war nicht automatisch im gleichen Maße gefährdet wie eine ungepatchte 6.9- oder 7.0-Installation.

Woran erkenne ich, ob meine Seite kompromittiert wurde?

Das Gemeine ist: Im Frontend muss man davon überhaupt nichts sehen.

Die Webseite kann ganz normal aussehen, während im Hintergrund bereits Dateien verändert oder neue Zugänge angelegt wurden. Bei Untersuchungen von wp2shell-Angriffen wurden unter anderem neu angelegte Plugin-Verzeichnisse, PHP-Webshells und Prozesse beobachtet, bei denen der Webserver plötzlich Shell-Befehle ausführte.

Verdächtig sind insbesondere:

• unbekannte Administrator-Konten, die niemand angelegt hat,
• neue oder unbekannte Ordner unter wp-content/plugins/,
• PHP-Dateien an Stellen, an denen normalerweise keine liegen sollten, beispielsweise in Upload- oder Cache-Verzeichnissen,
• plötzlich veränderte WordPress-Core-Dateien,
• unbekannte Plugins oder Must-Use-Plugins unter wp-content/mu-plugins/,
• ungewöhnliche Dateiänderungen ungefähr zu dem Zeitpunkt, zu dem die Sicherheitslücke aktiv ausgenutzt wurde,
• verdächtige POST-Anfragen auf die WordPress-REST-API beziehungsweise den Batch-Endpunkt in den Server-Logs.

Auch stark verschleierter PHP-Code kann ein Warnsignal sein – etwa lange unleserliche Zeichenketten in Verbindung mit Funktionen wie base64_decode, eval, gzinflate oder shell_exec. Das allein beweist allerdings noch keinen Angriff: Solche Funktionen können auch in legitimer Software vorkommen. Entscheidend ist immer der Zusammenhang.

Und noch etwas ist wichtig: Die öffentlich bekannten Dateinamen und Verzeichnisse der ersten Exploits sind keine vollständige Checkliste. Angreifer können Namen und Speicherorte problemlos verändern. Auch Elastic weist deshalb darauf hin, dass eine Prüfung nur nach bekannten Dateinamen nicht ausreicht.

„Ich habe auf 7.0.2 aktualisiert – dann ist doch alles gut?“

Wenn die Installation vor einem erfolgreichen Angriff aktualisiert wurde: ja, hinsichtlich dieser beiden Sicherheitslücken ist die Schwachstelle damit geschlossen.

War die Seite aber bereits kompromittiert, sieht die Sache anders aus.

Ein Update repariert WordPress. Es löscht aber nicht zwangsläufig einen zuvor angelegten Admin-Account, ein manipuliertes Plugin oder eine Webshell. Genau deshalb sollte eine Website, die während des kritischen Zeitraums öffentlich erreichbar und ungepatcht war, nicht einfach nur aktualisiert und anschließend abgehakt werden.

Dann heißt es: Dateien, Benutzer, Plugins, Logs und gegebenenfalls die Datenbank überprüfen.

Denn bei wp2shell ist nicht nur die Frage entscheidend:, ob gepatcht wurde, sondern ob die Seite kompromittiert wurde bevor das Patch installiert wurde.

Du willst wissen, ob deine Seite sauber ist?
Ich schaue mir deine WordPress-Installation gerne gezielt auf mögliche Spuren von wp2shell an. Schreib mir einfach – dann prüfen wir das gerne.