Vor einer Woche hatte ich über eine kritische Schwachstelle in WordPress berichtet, die die Entdecker als wp2shell bezeichnen. Die Schwachstelle erlaubt eine CMS-Übernahme. Es war auffällig ruhig, aber mir liegen nun die ersten Fälle vor, wo es WordPress-Instanzen getroffen hat.
Die WordPress Schwachstelle wp2shell
In WordPress existieren vor der Version 6.9.5 und 7.0.2 gleich zwei Schwachstellen CVE-2026-63030 und CVE-2026-60137 (wp2shell), die die Übernahme des CMS ermöglichen. Sicherheitsforscher von Searchlight Cyber waren kürzlich auf die wp2shell genannte Schwachstelle gestoßen. Es ist eine RCE-Schwachstelle im WordPress-Kernel, die vor der Authentifizierung ausgenutzt werden kann. Der Angriff erfordert keine Voraussetzungen und kann von einem anonymen Benutzer in einer Standardinstallation von WordPress ohne Plugins ausgenutzt werden.
Ich hatte zum 19. Juli 2026 im Blog-Beitrag Kritische WordPress-Schwachstelle wp2shell erlaubt CMS-Übernahme ausführlicher berichtet. Die WordPress-Entwickler hatten über die WordPress Versionen 6.9.5 und 7.0.2 einen Fix bereitgestellt. Und die Entdecker der Schwachstelle hatten einen Scanner veröffentlicht, wo man über eine Webseite seinen WordPress-Blog auf eine Gefährdung prüfen konnte.
Als mein Blog-Beitrag online ging, waren alle meine Blogs bereits aktualisiert und abgesichert, auch wenn der Online-Scanner teilweise fälschlich behauptete, dass die Installation angreifbar sei. Auch dem Besitzer der Domain borncity[.]com hatte ich einen Hinweis hinterlassen und auch deren Blog ist auf WordPress 7.0.2.
Ich habe seit diesem Zeitpunkt mehrfach meine Blogs auf Unstimmigkeiten geprüft, konnte aber weder manuell noch mit internen Scannern irgend ein Anzeigen einer Kompromittierung entdecken. Man kann das WordPress-Plugin Compromise Scanner for wp2shell zur Prüfung, ob eine Instanz kompromittiert sein könnte, als Gegenprobe zum manuellen Check durchlaufen lassen.
Betroffenennetzwerk BeNe ein Opfer
Eines der ersten Opfer der wp2shell-Schwachstelle ist BeNe. Das Kürzel steht für "Betroffenen Netzwerk", das ist eine Plattform, auf der Betroffene sexualisierter Gewalt in der Evangelischen Kirche in Deutschland (EKD) seit 2024 Erfahrungen austauschen können. Die Plattform wurde mittels WordPress realisiert, und die Betreiber haben diese Plattform erst offline genommen, nachdem das BSI die Woche gewarnt hatte. Leider zu spät, denn es sind wohl Daten abgeflossen, wie ich im Blog-Beitrag Gebets-App des Papstes leakt Nutzer; BeNe-Hack verunsichert Betroffene berichtet habe.
Weitere Opfer – Diskussion auf Facebook
Ich hatte meinen Blog-Beitrag Kritische WordPress-Schwachstelle wp2shell erlaubt CMS-Übernahme auch auf Facebook in einer WordPress-Gruppe geteilt. Dort hat sich ein Betroffener mit folgenden Informationen gemeldet.
Heute erhielten wir von IONOS die Mail, dass unsere Webseite vermutlich betroffen ist (s.u.).
_____________________________________________
In der Benutzerliste tauchte ein verdächtiges Administrator-Konto auf "wpsvc_59ef9db7ebe0@wordpress-svc.internal", das sich zuletzt am 19.7. eingeloggt hat. Das Konto habe ich gelöscht.In der Liste der Plugins fand ich daneben zwei am 19.7. installierte Plugins:
"Database Repair Assistant" und "wp2s-606aa615"
Beide erst einmal deaktiviert.
Mich wundert allerdings, dass die BSI-Informationen https://www.bsi.bund.de/…/DE/2026/2026-271984-1032.pdf… davon sprechen, dass WP 7.0.2 nicht betroffen sei – und wir nutzen 7.0.2
_____________________________________________
Hallo xxxxxxin der Content Management Software WordPress wurde die Sicherheitslücke wp2shell bekannt. Damit können Angreifer potenziell schadhaften Code auf betroffene Webspaces einschleusen und auf Ihre Daten zugreifen.
Potenziell sind alle WordPress-Installationen weltweit betroffen. Technische Details zur Sicherheitslücke finden Sie in der offiziellen Cybersicherheitswarnung des BSI.
Bei einer Sicherheitsprüfung haben wir starke Anzeichen dafür gefunden, dass Ihre WordPress-Installation Opfer eines entsprechenden Angriffs wurde und dass Dateien und/oder Datenbanken kompromittiert wurden.
Bitte loggen Sie sich umgehend in Ihr IONOS Konto ein und ändern Sie Ihre Passwörter:
• Kundenpasswort
• E-Mail-Passwörter
• Passwörter oder Zugangsdaten (z. B. API-Keys, Token) für alle Programme und Erweiterungen (Plugins), die mit Ihrer WordPress-Seite verbunden sind (zum Beispiel für Ihren Online-Shop).Sollten Sie Passwörter, die Sie auch bei anderen Diensten oder Accounts verwenden, in Ihrer WordPress-Instanz hinterlegt haben, ändern Sie diese bitte aus Sicherheitsgründen ebenfalls umgehend bei den jeweiligen Anbietern.
WICHTIG: Tragen Sie geänderte Passwörter oder Zugangsdaten keinesfalls in Ihr WordPress ein. Angreifer könnten sonst Zugriff auf Ihre Daten bekommen.
Wir arbeiten mit Nachdruck an weiteren Sicherheitsmaßnahmen für Ihre WordPress-Installation und informieren Sie in Kürze über die nächsten Schritte.
Mit freundlichen Grüßen
Klingt mir so, dass die vor dem Upgrade auf WordPress 7.0.2 kompromittiert wurden. In den Kommentaren bestätigen weitere Nutzer, dass es einige Betroffene gebe. Einer der Teilnehmer schrieb: "Wir haben bereits einige betroffene WordPresss-Websites; Update auf WordPress 7 bereits erfolgt, trotzdem generiert sich immer eine .htaccess und index.php mit Schadcode." Hier muss eine Infektion vor dem Update angenommen werden.
Ein Nutzer schrieb: "Ich habe bereits eine Website erfolgreich bereinigt. Muster: in jedem Unterordner gibt es eine htaccess und die index.php im Hauptordner wird automatisch immer wieder überschrieben. Ich habe es mit einer bereinigten neuen Version gelöst." Vielleicht hilft dies betroffenen WordPress-Nutzern.
Ähnliche Artikel:
Kritische WordPress-Schwachstelle wp2shell erlaubt CMS-Übernahme
Gebets-App des Papstes leakt Nutzer; BeNe-Hack verunsichert Betroffene
WordPress-Hacks über wp2shell – erste Opfer
MVP: 2013 – 2016
Günther, wieviele Artikel braucht es von Dir noch, bis Du erkennst dass es besser wäre WordPress zu ersetzen?
Warum sollte er – oder gibt's hier Probleme?
sehe ich genauso. Es ist nicht mal machen, wenn Du einen Blog 19 Jahre am Start hast, und auf einige Sachen achten musst. Zudem gibt es das 'Vom Regen in die Traufe' … ein Wechsel will überlegt sein. Zudem bin ich hier im IT-Blog nur noch Autor und Chefredakteur.
Wenn ich eine tragfähige Alternative habe, versuche ich ggf. mal einen meiner Nischenblogs zu portieren.
Vor 6 Jahren stand auch auch vor der Wahl, mit welcher technischen Basis ich meinen Blog starte. Zuvor hatte ich ein proproietäres Produkt verwendet, das zwar gute Resultate lieferte aber eben a) nicht frei und b) nicht besonders geeignet für viele Inhalte (war Rapidweaver). Ich habe mich bewusst für ein Static Page Generator entschieden ohne aktive Inhalte, ohne Datenbanken ohne irgendwas. Meine Wahl fiel auf Hugo und einem GitOps-Way. Der Blog dazu vor sechs Jahren:
https://blog.jakobs.systems/blog/20200818-hugo-als-blog-plattform/
Ich finde, wer heute über WP jammert, der hätte es lange vorher besser wissen und eine nachhaltige, technologische Grundlage schaffen können. Ich habe da jetzt nichts besonderes gemacht, sondern lediglich mich einmal hingesetzt und überlegt, was will ich und welche Technoloie und welches Modell ist das Beste zum Erreichen des Ziels.
Mach Vorschläge, und ganz wichtig: ohne HTML, CSS oder Konsole.
ich hatte diese email auch bekommen, aber mittlerweile finde ich sie sehr generisch ohne dass sie den indicator dafür beschreiben. Ich hatte direkt nach der info und release , dass update eingespielt.
Nach der email direkt alles überprüft:
wp version
wp core verify-checksums
admin accounts aufgelistet , plugins folder nach zeit erstellung und php überprüft. nirgend war etwas zu erkennen, weder in der datenbank , noch in den Einstellungen. Der support konnte mir auch nicht "genau" sagen was jetzt der indicator war. Am ende trotzdem alle passwörter rotiert und wp gelöscht und neu installiert. Aber so eine email bringt niemanden weiter.
Das wurde bereits bei Erscheinen des ersten wp2shell Beitrags aufgeklärt, der genutzte Online-Scanner konnte zunächst nicht mit der Installation von WordPress im Unterverzeichnis /blog/ innerhalb einer anderen WordPress Installation im Hauptverzeichnis der Domain umgehen. Das Problem wurde zeitnah vom Autor des Scanners behoben, die Scans waren dann korrekt.
Ein WordPress Plugin innerhalb einer WordPress Installation selbst als Scanner für diese Installation einzusetzen, ist nett gesagt wenig zielführend. Ggf. vorhandener bösartiger Code kann solche Plugins jederzeit in die Irre führen bzw. auch gezielt so patchen, dass immer "ok" angezeigt wird. So einen Ansatz sollte man nicht als Tipp verbreiten.
zum letzten Absatz: Gehe ich nur bedingt mit. Ich hatte ja Hinweise auf einen Artikel gegeben, was man manuell prüfen kann. Wenn das negativ ist, ließe sich das Plugin zur Gegenprobe einsetzen. Zudem gibt es externe Security Scanner. Es liegt letztlich beim Blogbetreiber.
Auch als Gegenprobe ist so ein Plugin untauglich, technisch läuft es im exakt gleichen Kontext wie mögliche Malware, die es dadurch beliebig unterlaufen kann.
Noch ergänzend zu diesem Absatz im Beitrag:
Deren Blog war noch tagelang(!) nach Bekanntwerden von wp2shell auf der verwundbaren WordPress 6.9.4 Version und kann daher durchaus kompromitiert worden sein. Das wurde mehrfach angemerkt weil es hochgradig gefährlich war.
Und falls sich deren WordPress Installationen auf dem gleichen Server im gleichen Verzeichnis Kontext befindet, kann es dadurch auch zu "normalen Übergriffen" via PHP auf die /blog/ WordPress Installation im Unterordner gekommen sein, z.B. durch Auslesen der allgemeinen Datenbankzugangsdaten aus wp-config.php, dem Hinterlassen ganz anders gelagerter Backdoors usw., völlig ohne irgendwelche Spuren von wp2shell zu hinterlassen. Das wäre der eigentlich wichtige Hinweis hier.
Was ist da bei ionos los? Ich habe da 3 unabhängige Pakete. Und soll jetzt für alle Mailkonten von allen Paketen die Passwörter ändern? Obwohl nur in einem Paket ein WordPress dabei ist.
Was ist da los?
Wir haben den Hinweis bewusst sehr breit gehalten – manche WordPress Plugins speichern Passwörter im Klartext, und wenn diese Daten auch für andere zugänge genutzt werden, sind die entsprechenden Dienste natürlich auch gefährdet.
Wenn Sie überall unterschiedliche Passwörter nutzen und keine anderweitig genutzten Passwörter in ihrer WordPress-Instanz gespeichert haben, müssen Sie selbstverständlich nichts ändern.