WordPress gehackt nach wp2shell: der Bereinigungsablauf

Das Sicherheitsupdate vom 17. Juli hat die Lücke geschlossen — aber keine einzige Hintertür entfernt, die vorher gesetzt wurde. Seit die US-Behörde CISA die beiden wp2shell-Schwachstellen am 21. Juli als aktiv ausgenutzt eingestuft hat und einen Tag später funktionierender Angriffscode öffentlich wurde, läuft nicht mehr die Angriffswelle, sondern die Aufräumwelle. Dieser Beitrag beschreibt, wie Sie feststellen, ob Ihre Website betroffen ist — und was danach zu tun ist.

Schritt 1: Waren Sie überhaupt angreifbar?

Die Angriffskette wp2shell verbindet zwei Schwachstellen im WordPress-Kern: eine Routen-Verwechslung in der REST-Batch-Schnittstelle (CVE-2026-63030) und eine SQL-Injection in WP_Query über den Parameter author__not_in (CVE-2026-60137). Die Batch-Schnittstelle kam erst mit WordPress 6.9 — deshalb ist der Zweig 6.8 von der Verwechslung nicht betroffen und erhielt mit 6.8.6 nur die Korrektur der SQL-Injection.

Ihre laufende Version steht im Dashboard unter «Aktualisierungen» oder unter «Werkzeuge › Website-Zustand». Entscheidend ist aber nicht nur die heutige Version, sondern seit wann sie läuft. WordPress hat automatische Updates erzwungen, was viele Installationen innerhalb von Stunden geschützt hat. Wo automatische Updates deaktiviert waren, blieb das Fenster offen — teilweise über Tage.

Zur Einordnung der Dringlichkeit: Die beiden Schwachstellen werden unterschiedlich bewertet. Die US-Datenbank NVD führt für CVE-2026-63030 zwei Werte nebeneinander — 9.8 «kritisch» vom zuständigen Vergabeteam WPScan und 7.5 «hoch» von der CISA-Ergänzung. Der Unterschied liegt darin, ob die vollständige Kette oder nur die Routen-Verwechslung bewertet wird. Für die Praxis ist beides dasselbe: sofort aktualisieren.

Warum das Update allein nicht reicht

Das ist der Punkt, an dem die meisten Anleitungen aufhören — und an dem die eigentliche Arbeit beginnt. Ein Angreifer, der die Lücke vor dem Update genutzt hat, ist bereits drin gewesen. Nach der Analyse von Rapid7 verläuft die Eskalation typischerweise so: Über die verkettete SQL-Injection wird ein Administratorkonto angelegt; damit meldet sich der Angreifer regulär an und lädt ein präpariertes Plugin hoch, das ihm dauerhaften Zugriff verschafft.

Beides überlebt das Update. Das Konto bleibt bestehen, das Plugin bleibt liegen. Die Lücke ist geschlossen, die Tür steht weiterhin offen — nur benutzt der Angreifer sie jetzt über einen anderen Weg.

Woran Sie einen Befall erkennen

Hier ist eine Warnung angebracht, die in vielen Checklisten fehlt: Es kursiert nicht ein Angriffsmuster, sondern mehrere. Die öffentlich dokumentierten Spuren unterscheiden sich deutlich — wer nur nach einer bestimmten Datei sucht, übersieht die anderen Varianten. Die folgende Übersicht fasst zusammen, was bislang beschrieben wurde.

Ein guter Startpunkt ist das Logfile Ihres Webservers: Zugriffe auf die Batch-Schnittstelle sind bei einer normalen Unternehmenswebsite selten. Häufen sie sich im Zeitraum vor Ihrem Update, ist das ein deutliches Signal — und der Zeitstempel des ersten auffälligen Zugriffs sagt Ihnen, ab wann Sie in Dateien und Datenbank suchen müssen.

Für den ersten Durchgang gibt es ein quelloffenes Prüfwerkzeug von InstaWP, das gezielt nach den oben beschriebenen Konten und Webshell-Plugins sucht und standardmässig nur liest, ohne zu verändern. Es ersetzt keine gründliche Prüfung, beantwortet aber schnell die Frage, ob die bekannten Muster vorliegen.

Bereinigen oder neu aufsetzen? Die ehrliche Entscheidung

Diese Frage wird zu selten gestellt. Eine Bereinigung ist der Versuch, alles Fremde zu finden — und man weiss nie sicher, ob man alles gefunden hat. Eine Wiederherstellung aus einem nachweislich sauberen Stand ist der sichere Weg, kostet aber die Inhalte seit diesem Zeitpunkt. Die Entscheidung hängt an drei Faktoren:

Wenn Sie diese Entscheidung nicht allein treffen möchten: Wir prüfen die Installation, ordnen den Befund ein und übernehmen Bereinigung und Härtung — siehe WordPress Security & Härtung. Eine unvollständig gesäuberte Website wird erfahrungsgemäss erneut übernommen.

Der Bereinigungsablauf

Die folgenden Schritte richten sich an technisch versierte Betreiber. Legen Sie vorher eine vollständige Sicherung von Dateien und Datenbank an — auch von der befallenen Website, denn sie ist Ihr einziger Beweis, falls später Fragen zum Vorfall auftauchen.

1. Website offline nehmen. Wartungsmodus oder Sperre auf Serverebene — solange der Zugang offensteht, arbeiten Sie gegen einen aktiven Gegner.
2. Fremde Administratorkonten entfernen. Benutzerliste nach Rolle sortieren und jedes Administratorkonto einzeln bestätigen. Im Zweifel Rolle entziehen statt löschen — löschen kann Inhalte mitnehmen.
3. Dateisystem säubern. Über SSH oder FTP wp-content/plugins/, mu-plugins/, uploads/ und cache/ nach PHP-Dateien durchsuchen, die Sie nicht selbst angelegt haben. Im Upload-Verzeichnis hat PHP grundsätzlich nichts zu suchen.
4. Kern aktualisieren. Auf 6.8.6, 6.9.5 oder 7.0.2 heben, sofern noch nicht geschehen. Danach Themes und Plugins.
5. Alle Zugänge erneuern. Passwörter sämtlicher Administratoren, das Datenbank-Passwort (mit Nachtrag in wp-config.php) und die Zugangsdaten des Hostings.
6. Sitzungen beenden. Neue Sicherheitsschlüssel aus dem offiziellen WordPress-Salt-Generator in die wp-config.php eintragen. Damit fliegt jede offene Sitzung heraus — auch die des Angreifers.
7. Geplante Aufgaben prüfen. Ein Blick auf die Cron-Einträge zeigt Aufgaben, die sich selbst wieder einrichten.

# PHP-Dateien im Upload-Verzeichnis — dort gehoert keine hin
find wp-content/uploads -name "*.php"

# Zuletzt geaenderte PHP-Dateien unter wp-content
find wp-content -name "*.php" -mtime -30 -printf "%T+ %p\n" | sort

# Geplante Aufgaben auflisten (WP-CLI)
wp cron event list

# Administratorkonten auflisten (WP-CLI)
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Die Spalte user_registered ist dabei der schnellste Filter: Ein Administratorkonto, das im Juli 2026 entstanden ist, ohne dass jemand es angelegt hat, beantwortet die Frage nach dem Befall bereits.

Zwei Massnahmen, die die Eskalation brechen

Unabhängig von wp2shell gibt es zwei Einstellungen, die den Weg vom Einbruch zur dauerhaften Übernahme deutlich erschweren. Beide kosten nichts und stören den Normalbetrieb nicht.

Erstens: Installationen und Datei-Änderungen im Backend abschalten. Wer über ein gekapertes Administratorkonto kein Plugin mehr hochladen kann, verliert den bequemsten Weg zur Webshell.

// In wp-config.php — verhindert Editor, Installation und Updates ueber das Backend:
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

Beachten Sie: DISALLOW_FILE_MODS unterbindet auch reguläre Updates über das Backend. Das ist auf einer betreuten Installation mit Update-Prozess über die Kommandozeile sinnvoll — auf einer selbst gepflegten Website kann es dazu führen, dass Sicherheitsupdates liegen bleiben. Wählen Sie bewusst.

Zweitens: Dem Datenbank-Benutzer unnötige Rechte entziehen. WordPress braucht im Normalbetrieb kein FILE-Recht. Wo es gesetzt ist, kann eine SQL-Injection unter Umständen direkt Dateien auf die Platte schreiben.

-- Als Datenbank-Administrator, Benutzernamen anpassen:
REVOKE FILE ON *.* FROM 'wp_benutzer'@'localhost';
FLUSH PRIVILEGES;

Die weiteren Grundlagen — Zwei-Faktor-Anmeldung, kleine Angriffsfläche, Monitoring — fassen wir in den WordPress-Sicherheitsgrundlagen zusammen. Wie ein Backup aussieht, auf das man sich im Ernstfall wirklich verlassen kann, steht im Beitrag zu automatischen Backups.

Meldepflicht: was das Schweizer Datenschutzgesetz verlangt

Sobald auf der betroffenen Website Personendaten liegen — Kundenkonten, Bestellungen, Formulareingänge, Newsletter-Adressen — stellt sich neben der technischen auch eine rechtliche Frage. Artikel 24 des Schweizer Datenschutzgesetzes verlangt eine Meldung an den EDÖB, wenn eine Verletzung der Datensicherheit voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte der betroffenen Personen führt.

Drei Punkte werden dabei regelmässig verwechselt:

• Keine 72-Stunden-Frist. Anders als die europäische Datenschutz-Grundverordnung nennt das Schweizer Gesetz keine feste Stundenzahl, sondern verlangt die Meldung «so rasch als möglich».
• Nicht jeder Angriff ist meldepflichtig. Meldepflichtig sind eingetretene Verletzungen — ein abgewehrter oder erfolgloser Angriffsversuch fällt nicht darunter.
• Die Meldung hat einen Mindestinhalt: Art der Verletzung, deren Folgen sowie die ergriffenen oder vorgesehenen Massnahmen.

Der EDÖB stellt dazu einen eigenen Leitfaden und ein Meldeportal bereit. Ob im Einzelfall ein hohes Risiko vorliegt, ist eine juristische Beurteilung — bei sensiblen Daten oder grösseren Beständen lohnt sich fachlicher Rat, bevor entschieden wird. Dieser Abschnitt ordnet die Rechtslage ein und ersetzt keine Rechtsberatung.

Fazit

wp2shell hat gezeigt, wie schnell eine Standardinstallation ohne jedes Zutun des Betreibers angreifbar wird — und wie viel die erzwungenen automatischen Updates aufgefangen haben. Für die meisten Websites ist die Sache damit erledigt. Für die Minderheit, bei der das Update zu spät kam, beginnt die Arbeit erst: Ein Angreifer, der einmal ein Administratorkonto besass, verschwindet nicht durch eine neue Versionsnummer.

Die belastbarste Antwort auf diesen Vorfall ist unspektakulär: zeitnahe Updates, ein geprüftes Backup ausserhalb der Website und jemand, der hinschaut, wenn etwas auffällt. Genau diese Kombination ist der Unterschied zwischen einem ruhigen Nachmittag und einem Totalschaden — und der Kern einer betreuten WordPress-Website.

Die technische Einordnung der Lücke selbst haben wir im Beitrag zur wp2shell-Sicherheitslücke beschrieben.

Häufig gestellte Fragen zur Bereinigung nach wp2shell

Quellen

• WordPress.org News — WordPress 7.0.2 (Sicherheits-Release) (17. Juli 2026)
• Rapid7 — CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core (2026)
• NVD — CVE-2026-63030 (Bewertungen von WPScan und CISA-ADP)
• The Hacker News — WordPress wp2shell Exploitation Grows as Public Exploit Fuels Mass Scanning (2026)
• InstaWP auf GitHub — wp2shell-scan: Detect & clean up wp2shell compromise (2026)
• EDÖB — Leitfaden betreffend die Meldung von Datensicherheitsverletzungen nach Art. 24 DSG