Erst durchatmen, dann handeln: der komplette Ablauf vom sauberen Rollback bis zum Erneuern aller Zugänge – erklärt am echten Fall der Sicherheitslücke wp2shell.
Bei einem Angriff auf deine WordPress-Website spielst du zuerst ein sauberes Backup von vor dem Angriff zurück, aktualisierst WordPress sofort auf die gepatchte Version und erneuerst danach alle Passwörter und API-Schlüssel. Wichtig ist außerdem: Prüfe, ob unbekannte Admin-Benutzer angelegt wurden oder fremde Dateien auf dem Server liegen – sonst kann der Angreifer trotz Rollback zurückkommen.
Das klingt im ersten Moment beängstigend, und man gerät schnell in Panik. Deshalb erst einmal durchatmen. Mit einem klaren Ablauf bekommst du die Situation Schritt für Schritt in den Griff – und genau den zeige ich dir hier.
Was gestern bei einer Kundin passiert ist
Gestern meldete sich eine Kundin bei mir. Sie schickte mir den Screenshot einer E-Mail ihres Hosting-Anbieters (united-domains) – mit der schlichten Frage: „Ist das echt?“
In der Mail hieß es, man habe „bei einer Sicherheitsprüfung konkrete Hinweise gefunden, dass ihr WordPress durch diesen Angriff kompromittiert wurde“. Konkret ging es um die Sicherheitslücke wp2shell. Weiter stand dort:
„Angreifer könnten Daten in Ihrer WordPress-Installation eingesehen, verändert oder gelöscht haben. Das betrifft insbesondere Passwörter und Zugangsdaten (z. B. API-Keys, Token) für alle Programme und Erweiterungen (Plugins), die mit Ihrer Website verbunden sind.“
Kurz zur Einordnung, damit du weißt, worum es geht: wp2shell ist keine Panikmache, sondern eine reale, Mitte Juli 2026 bekannt gewordene Schwachstelle im WordPress-Kern. Angreifer können darüber ohne Login und ohne installierte Plugins Schadcode ausführen – das BSI hat davor gewarnt. Genau so eine Mail kann also echt sein. Muss sie aber nicht. Deshalb ist der erste Schritt nicht das Rollback, sondern die Prüfung.
Schritt 1: Ist die E-Mail überhaupt echt?
Bevor du irgendetwas anklickst oder herunterlädst: Prüfe, ob es sich nicht um eine Phishing-Mail handelt.
Bei meiner Kundin war die Absenderadresse unauffällig, und – noch wichtiger – im Dashboard ihres Hosters tauchte zusätzlich eine deutliche Warnung auf. Das war das entscheidende Signal, dass die Mail echt ist.
Mein Tipp, wenn du dir unsicher bist: Klick keine Links in der Mail an. Logge dich stattdessen direkt (über die dir bekannte Adresse) in dein Hosting-Dashboard ein und leite die Mail an den Support deines Hosters weiter mit der kurzen Frage, ob sie wirklich von ihnen stammt.
Schritt 2: Beweis sichern – aber nicht wiederherstellen
Zieh zuerst ein Backup der aktuellen (möglicherweise kompromittierten) Seite. Das ist deine Sicherung für den Fall der Fälle – du spielst dieses Backup aber nicht wieder ein, weil darin ja der Angriff stecken könnte.
Schritt 3: Rollback auf ein sauberes Backup
Jetzt spielst du ein Backup von vor dem Angriffsdatum ein. Bei meiner Kundin lag der passende Stand rund eine Woche zurück – und zum Glück sind dabei keine wichtigen Änderungen verloren gegangen.
Genau deshalb empfehle ich: alle 14 Tage ein Backup, und zusätzlich immer dann, wenn du an der Website arbeitest oder Updates gemacht werden. So hast du im Ernstfall nie einen weit zurückliegenden Stand.
Schritt 4: Sofort auf die gepatchte Version aktualisieren (nicht vergessen!)
Das ist der Schritt, den viele überspringen – und der entscheidet, ob der Angriff wirklich vorbei ist. Ein Backup von vor dem Angriff enthält dieselbe verwundbare WordPress-Version. Spielst du es zurück und tust sonst nichts, ist deine Seite sofort wieder angreifbar.
Deshalb: direkt nach dem Rollback WordPress auf die abgesicherte Version updaten. Bei wp2shell ist das WordPress 7.0.2 (bzw. 6.9.5 für die 6.9-Reihe). Am besten setzt du die Seite dafür kurz in den Wartungsmodus. Erst dann bist du aus der Gefahrenzone.
Schritt 5: Seite prüfen und fremde Zugänge entfernen
Klick dich einmal durch die Seite und prüfe, ob alles funktioniert. Geh dann ins Backend und schau dir die Benutzer an:
Tauchen dort Admins auf, die niemand von euch angelegt hat? Sofort löschen. Das ist ein deutliches Zeichen, dass der Angriff erfolgreich war – oder dass dein Backup-Stand doch schon nach dem Angriff lag. Wirf in diesem Fall auch einen Blick auf den Dateibestand: Bei Angriffen wie wp2shell hinterlassen Angreifer gern versteckte Dateien (sogenannte Webshells), die ein reines Inhalts-Rollback nicht immer entfernt. Im Zweifel hilft hier ein Malware-Scan (z. B. mit Wordfence, dazu unten mehr) oder eine saubere Neuinstallation.
Schritt 6: Passwörter und API-Schlüssel erneuern
Zum Abschluss:
- Passwörter aller Admin-Konten ändern
- Passwörter der verknüpften E-Mail-Adressen ändern
- alle API-Schlüssel neu generieren und austauschen
Damit sind alle Zugänge, die der Angreifer eventuell mitgelesen hat, wertlos.
Fazit
Obwohl WordPress nach Bekanntwerden der Lücke sehr zeitnah das Sicherheitsupdate 7.0.2 herausgebracht hat und ich alle von mir betreuten Websites aktualisiert hatte, konnte es trotzdem zu Angriffsversuchen kommen. Der Grund: Die ersten Angriffe liefen schon wenige Stunden nach Veröffentlichung der Lücke – schneller, als viele reagieren konnten.
Genau das zeigt, warum regelmäßige Wartung so wichtig ist: Nicht, weil sie jeden Angriff zu 100 % verhindert, sondern weil du im Ernstfall aktuelle Backups, kurze Update-Wege und einen klaren Plan hast. Dann sind es Stunden statt Tage – und deine Seite ist schnell wieder sicher.
Meine Tool-Empfehlungen
Zwei Plugins, die ich in dem Zusammenhang immer wieder empfehle:
Wordfence – für den Sicherheits-Scan. Damit scannst du deine Website einmal komplett durch. Es vergleicht deine WordPress-, Theme- und Plugin-Dateien mit dem Original und erkennt veränderte oder eingeschleuste Dateien. Eine Einschränkung solltest du kennen: Der Scanner arbeitet vor allem dateibasiert und erkennt tiefe Veränderungen direkt in der Datenbank (etwa Schadcode in der Tabelle wp_options) nicht zuverlässig. Er ersetzt also keine gründliche Prüfung – aber einen Scan solltest du auf jeden Fall durchführen.
UpdraftPlus – für regelmäßige Backups. Hier stellst du in wenigen Klicks ein, in welchem Rhythmus Backups erstellt werden (ich empfehle mindestens alle 14 Tage), und wählst aus, wo sie gespeichert werden – zum Beispiel in einer Cloud getrennt von deinem Hosting. Genau das ist der Punkt: Ein Backup, das getrennt vom Server liegt, rettet dich, wenn der Server selbst betroffen ist.
Wie ich dir dabei helfe
Wenn du so eine Mail bekommst und nicht sicher bist, was echt ist und was zu tun ist: Genau dafür bin ich da. Ich prüfe die Situation, übernehme Rollback, Update und das Erneuern aller Zugänge – und sorge dafür, dass deine Seite danach wirklich sauber ist.
Und damit es gar nicht erst so weit kommt, halte ich in meinen Wartungspaketen deine Website aktuell: Updates zuerst, regelmäßige Backups, im Blick behalten, was sich tut. Melde dich gern – ich schaue mir deine Seite an.