wp2shell: Ist Ihre WordPress-Seite betroffen? Versionen, Anzeichen und was jetzt zu tun ist

Kurzfassung für Eilige: Läuft Ihre Seite auf WordPress 6.8.0 bis 6.8.5, 6.9.0 bis 6.9.4 oder 7.0.0 bis 7.0.1, ist sie von wp2shell betroffen. Sicher sind 6.8.6, 6.9.5, 7.0.2 und alles Neuere. Und selbst wenn das Update längst drin ist: Prüfen Sie die Benutzerliste, die Plugin-Liste und den Webspace — die Lücke wurde ab dem 20. Juli automatisiert ausgenutzt, und die Angreifer haben nicht auf das Update gewartet.

Was wp2shell ist

Am 17. Juli 2026 veröffentlichte das WordPress-Projekt außerplanmäßig die Versionen 7.0.2, 6.9.5 und 6.8.6. Sie schließen zwei Schwachstellen im WordPress-Kern, die einzeln unangenehm und zusammen verheerend sind: eine SQL-Injection in der Abfrage-Klasse WP_Query (CVE-2026-60137) und eine Verwechslung von Routen in der Batch-Schnittstelle der REST-API (CVE-2026-63030). Hintereinander geschaltet ergeben sie das, was Sicherheitsforscher „wp2shell” tauften: Ein einziger präparierter HTTP-Aufruf gegen eine unveränderte Standardinstallation genügt, um eigenen Code auf dem Server auszuführen. Kein Plugin nötig, kein Theme, kein Login, kein Nutzerfehler.

Das unterscheidet wp2shell von fast allem, was WordPress-Betreiber sonst kennen. Die üblichen Lücken stecken in Plugins, und wer die nicht installiert hat, ist nicht betroffen. Hier war jede Seite betroffen, die online war. WordPress.org hat deshalb erstmals in seiner Geschichte Zwangs-Updates ausgelöst — auch bei Seiten, die automatische Updates abgeschaltet hatten, soweit das technisch ging. Das BSI warnte am selben Tag (Kennung 2026-271984-1032). Ab dem 20. Juli waren Angriffsprogramme öffentlich, ab dem 21. Juli meldeten Hoster und Sicherheitsfirmen laufende Angriffe.

Bin ich betroffen?

Drei Wege, es herauszufinden:

1. Im Backend: Dashboard → Aktualisierungen. Dort steht die installierte Version. Alles unter 6.8.6, 6.9.5 bzw. 7.0.2 ist offen.
2. Von außen: Unser WordPress-Alters-Check liest die Version aus dem Quelltext Ihrer Seite und sagt Ihnen direkt, ob die Versionsnummer in der wp2shell-Liste steht — und welche Sicherheits-Releases seitdem noch fehlen.
3. Beim Hoster: Viele Anbieter (IONOS, Strato, all-inkl, Raidboxes) haben Ende Juli Rundmails verschickt oder das Update selbst eingespielt. Prüfen Sie das Postfach, das beim Hoster hinterlegt ist — oft ist es nicht das, in das Sie täglich schauen.

Wichtig: Ein Zweig, der weiter gepflegt wird, ist nicht automatisch sicher. Eine 6.9.4 fühlt sich aktuell an, weil 6.9 noch Updates bekommt — sie ist trotzdem offen. Entscheidend ist die dritte Stelle der Versionsnummer.

Woran Sie einen Befall erkennen

Das Tückische an dieser Welle: Die angegriffenen Seiten liefen weiter wie immer. Die Angreifer wollten keine Aufmerksamkeit, sondern einen dauerhaften Zugang, den sie später verkaufen oder für Spam und Weiterleitungen nutzen können. Die vier Zeichen, die wir in bereinigten Fällen regelmäßig gesehen haben:

• Unbekannte Administrator-Konten. Benutzer → Alle Benutzer, nach Rolle „Administrator” filtern. Typisch sind unauffällige Namen wie admin2, wp-support, backup oder ein Vorname ohne Nachnamen, angelegt zwischen dem 17. und 31. Juli.
• Plugins, die Sie nicht installiert haben. Oft mit Namen, die nach WordPress-Kern klingen (wp-core-helper, system-optimizer), manchmal ohne Eintrag in der Plugin-Liste, weil sie als „Must-Use-Plugin” unter wp-content/mu-plugins/ liegen — dieser Ordner wird im Backend nicht angezeigt.
• Deaktivierte Sicherheits-Plugins. Wordfence, Solid Security oder ein Backup-Plugin sind plötzlich aus, ohne dass jemand es war.
• Fremde Dateien im Webspace. PHP-Dateien mit kryptischen Namen in wp-content/uploads/, im Hauptverzeichnis oder in wp-includes/, mit Änderungsdatum aus dem Juli.

Fehlt alles davon, ist das kein Beweis für eine saubere Seite. Aber es ist eine gute Nachricht.

Warum das Update allein nicht reicht

Das Update auf 7.0.2 oder 6.9.5 schließt die Tür. Es holt aber niemanden zurück, der schon im Haus ist. Ein angelegtes Admin-Konto funktioniert nach dem Update weiter, eine Hintertür in mu-plugins auch. Wer zwischen dem 17. und dem Update-Zeitpunkt online war — und das waren die meisten Seiten mindestens ein paar Stunden —, muss die vier Punkte oben durchgehen. Bei einem Fund gilt: nicht einfach löschen. Erst den Zustand sichern, dann alle Passwörter und Salts wechseln, dann bereinigen, dann das Einfallstor bewerten. Wer nur das Konto löscht, lässt in der Regel die Datei stehen, die es wieder anlegt.

Was Sie jetzt tun sollten

1. Version prüfen und, falls nötig, sofort aktualisieren — mit Backup davor.
2. Die vier Befallszeichen durchgehen. Bei Unsicherheit: unser Beitrag Woran Sie erkennen, dass Ihre WordPress-Seite gehackt wurde beschreibt die allgemeinen Symptome ausführlicher.
3. Automatische Updates für Sicherheits-Releases einschalten (sie sind standardmäßig an — prüfen Sie, ob ein Plugin oder die wp-config.php sie abgeschaltet hat).
4. Danach: 7.0.3 und 7.0.4 nachziehen (im 6.9-Zweig 6.9.7, im 6.8-Zweig 6.8.8) oder gleich auf 7.1 vom 19. August gehen. Der August brachte zwei weitere Sicherheits-Releases, davon eines mit erneuter Codeausführung — Details im Beitrag zu WordPress 7.0.4.

Wenn Sie einen der Punkte finden oder sich die Prüfung nicht zutrauen: Unser Malware-Notfall macht genau das — Update, Prüfung von Dateien, Datenbank und Benutzerliste, Bereinigung, Härtung, Bericht. Zum Festpreis, Start am selben Werktag.