wp2shell: WordPress-Exploit prüfen und absichern

Nachtrag

Die kurze Sicherheitsmeldung zu wp2shell fasst die unmittelbaren Maßnahmen zusammen. Inzwischen sind weitere Details zur betroffenen Versionsspanne und zur sicheren Wiederherstellung bekannt. Dieser Beitrag ergänzt die Kurzmeldung mit einer konkreten Prüfliste, typischen Anzeichen und den nächsten Schritten bei Verdacht.

Wenn Ihre WordPress-Website seit dem 17. Juli 2026 nicht aktualisiert wurde, sollten Sie jetzt nicht abwarten: Die Sicherheitslücke „wp2shell“ kann auf bestimmten WordPress-Versionen ohne Login ausgenutzt werden. Angreifer benötigen dafür weder ein Passwort noch ein anfälliges Plugin.

Das heißt nicht automatisch, dass Ihre Seite kompromittiert ist. Es heißt aber: Version prüfen, Sicherheitsupdate einspielen und bei Anzeichen eines Angriffs sorgfältig aufräumen. Dieser Beitrag erklärt die Lage ohne Sicherheitsjargon und mit einer klaren Reihenfolge.

Was ist wp2shell?

„wp2shell“ ist der Name für eine Kombination aus zwei Fehlern im WordPress-Kern, also nicht in einem einzelnen Theme oder Plugin. Zusammen können sie es einem nicht angemeldeten Angreifer ermöglichen, Schadcode auf dem Webserver auszuführen. In der IT heißt das „Remote Code Execution“: Jemand kann aus der Ferne Befehle auf dem Server ausführen.

WordPress hat die Lücken am 17. Juli 2026 geschlossen. Die technischen Kennungen lauten CVE-2026-63030 und CVE-2026-60137. Die offizielle WordPress-Mitteilung stuft das Paket als Sicherheitsrelease ein und empfiehlt ein sofortiges Update. Für betroffene Installationen wurden zwar erzwungene Hintergrundupdates aktiviert, verlassen Sie sich darauf aber nicht blind: Prüfen Sie die tatsächlich installierte Version selbst. WordPress nennt die betroffenen Versionszweige und die Updates hier.

Welche WordPress-Versionen sind betroffen?

Installierte WordPress-Version	Risiko durch wp2shell	Was Sie tun sollten
Älter als 6.8	Nicht von diesen beiden Lücken betroffen	Allgemeine Updates trotzdem planen
6.8.0 bis 6.8.5	SQL-Injection-Lücke betroffen, nicht die vollständige Codeausführungs-Kette	Sofort auf mindestens 6.8.6 aktualisieren
6.9.0 bis 6.9.4	Vollständige wp2shell-Angriffskette betroffen	Sofort auf mindestens 6.9.5 aktualisieren
7.0.0 bis 7.0.1	Vollständige wp2shell-Angriffskette betroffen	Sofort auf mindestens 7.0.2 aktualisieren
6.8.6, 6.9.5, 7.0.2 oder neuer	Für wp2shell gepatcht	Zusätzlich auf Spuren eines früheren Zugriffs prüfen

Wichtig: Auch eine aktualisierte Seite sollte geprüft werden, wenn sie vor dem Update öffentlich erreichbar und verwundbar war. Das Update schließt die Lücke, entfernt aber keinen bereits abgelegten Schadcode und keinen unberechtigt angelegten Benutzer.

So prüfen Sie, ob Ihre Website gefährdet war

Melden Sie sich in WordPress an und öffnen Sie Dashboard → Aktualisierungen. Dort sehen Sie die WordPress-Version und können das Core-Update direkt starten. Alternativ steht die Version häufig unten im Administrationsbereich.

Falls Sie keinen Zugang zum WordPress-Backend haben, kann Ihr Hosting-Support die Version in der Regel feststellen. Bei professioneller Betreuung sollte außerdem in einer Verwaltungsoberfläche oder im Wartungsprotokoll stehen, wann das Sicherheitsupdate eingespielt wurde.

Wenn Ihre Website eine der betroffenen Versionen hatte und erst nach dem 17. Juli aktualisiert wurde, behandeln Sie sie vorsorglich als potenziell betroffen. Das ist keine Aussage, dass ein Angriff stattgefunden hat; es legt nur den Umfang der Prüfung fest.

Typische Symptome: Woran erkenne ich einen möglichen Befall?

Es gibt kein einzelnes, sicheres sichtbares Zeichen. Angreifer versuchen oft, unauffällig zu bleiben. Diese Auffälligkeiten sind aber ein guter Anlass für eine technische Prüfung:

Im Menü Benutzer erscheint ein Administrator-Konto, das Sie nicht kennen.
Es wurden Plugins oder Themes installiert, die niemand aus Ihrem Team freigegeben hat.
Ihre Website leitet Besucher auf fremde Seiten weiter, zeigt Spam, Pop-ups oder seltsame Suchergebnisse.
Im Dateimanager des Hostings finden sich neue oder kürzlich geänderte PHP-Dateien, besonders in Upload-Ordnern oder unbekannten Verzeichnissen.
Sicherheits- oder Server-Logs zeigen ungewöhnliche Zugriffe, auffällige POST-Anfragen oder viele Fehler rund um die REST-API.
Es gibt unbekannte geplante Aufgaben (WordPress-Cronjobs), geänderte E-Mail-Adressen oder unerwartete Datenbankeinträge.
Die Seite ist plötzlich langsam, liefert Fehler oder der Hoster meldet verdächtige Aktivität.

Keines dieser Symptome beweist für sich allein wp2shell. Umgekehrt schließt eine optisch unauffällige Website einen Befall nicht aus. Bei einem Verdacht sollten Sie nicht nur „ein Security-Plugin drüberlaufen lassen“, sondern Benutzer, Dateien, Datenbank und Logs gemeinsam prüfen.

Sofortmaßnahmen: Was jetzt zu tun ist

Gehen Sie in dieser Reihenfolge vor:

Aktuellen Stand sichern. Erstellen Sie ein vollständiges Backup aus Dateien und Datenbank, bevor Sie aufräumen oder zurückspielen. Dieses Backup kann später bei der Analyse helfen. Speichern Sie bei deutlichem Verdacht auch relevante Server- und Sicherheitslogs.
WordPress Core unverzüglich aktualisieren. Installieren Sie mindestens 6.8.6, 6.9.5 oder 7.0.2 – besser die aktuelle stabile Version, wenn Ihr Setup dafür bereit ist.
Plugins und Themes aktualisieren. Aktualisieren Sie anschließend alle Erweiterungen und löschen Sie nicht benötigte, insbesondere ungenutzte Themes und Plugins. Eine schlanke, gepflegte Installation reduziert die Angriffsfläche; dazu passt auch mein Beitrag zum WordPress Plugin-Management.
Zugänge absichern. Ändern Sie die Passwörter aller WordPress-Administratoren, des Hostings, SFTP/SSH und der Datenbank. Prüfen Sie die Benutzerliste und entfernen Sie unbekannte Konten. Aktivieren Sie, wo möglich, Zwei-Faktor-Anmeldung.
Auf Spuren prüfen. Kontrollieren Sie geänderte Dateien, installierte Erweiterungen, geplante Aufgaben, Weiterleitungen und die Datenbank. Bei bestätigtem oder ernsthaftem Verdacht sollte ein Profi die Bereinigung begleiten.
Danach testen und überwachen. Prüfen Sie wichtige Seiten, Formulare, Shop oder Buchungsstrecke. Behalten Sie Logs, Uptime und Warnmeldungen in den nächsten Tagen besonders im Blick.

Wenn ein sofortiges Update ausnahmsweise technisch nicht möglich ist, kann eine Web Application Firewall den anonymen Zugriff auf den REST-API-Batch-Endpunkt vorübergehend blockieren. Das ist lediglich eine Notmaßnahme, kein Ersatz für das Sicherheitsupdate.

Backup vor dem 17. Juli einspielen – ist das sinnvoll?

Ja, das kann bei einem bestätigten Befall ein sinnvoller Teil der Wiederherstellung sein, wenn seit dem 17. Juli keine kritischen, legitimen Änderungen vorgenommen wurden – etwa neue Bestellungen, Formulareinträge, Buchungen, Inhalte oder Benutzerkonten.

Ein Backup von vor dem 17. Juli kann einen bekannten sauberen Ausgangspunkt liefern. Spielen Sie es aber nicht unüberlegt sofort live ein. Sonst gehen aktuelle Daten verloren, und ein möglicherweise noch verwundbarer Stand wird erneut veröffentlicht.

Die sichere Reihenfolge lautet:

Den aktuellen Stand inklusive Datenbank und Logs sichern.
Das alte Backup zunächst in einer Testumgebung prüfen und wiederherstellen.
WordPress Core, Plugins und Themes dort sofort aktualisieren.
Aktuelle, nachweislich legitime Inhalte oder Geschäftsdaten gezielt übernehmen.
Alle Zugänge ändern und die bereinigte Seite erst dann wieder live schalten.

Bei Shops, Mitgliederbereichen oder vielen Änderungen seit dem Stichtag ist eine gezielte Bereinigung häufig besser als ein vollständiges Zurückrollen. Die richtige Entscheidung hängt vom Schaden, den vorhandenen Backups und den seitdem entstandenen Daten ab.

So schützen Sie Ihre WordPress-Seite langfristig

wp2shell zeigt vor allem eines: Auch der WordPress-Kern braucht zeitnahe Sicherheitsupdates. Eine robuste Basis besteht aus automatisierten, extern gespeicherten Backups, einer regelmäßigen Update-Routine, möglichst wenigen gut gepflegten Erweiterungen, starken individuellen Passwörtern und Zwei-Faktor-Anmeldung für Admin-Konten.

Für geschäftskritische Websites empfehle ich außerdem eine Staging-Umgebung: Dort lassen sich Updates vor dem Livegang testen. Wie Sie Backups, Updates und Kontrollen in einen überschaubaren Ablauf bringen, lesen Sie in meiner WordPress-Wartungsroutine.

Fazit: Nicht abwarten, aber besonnen handeln

Prüfen Sie Ihre WordPress-Version jetzt und aktualisieren Sie betroffene Installationen sofort. Wenn die Seite zwischen dem 17. Juli und dem Update verwundbar online war, prüfen Sie sie zusätzlich auf Spuren eines Zugriffs. Ein Backup von vor dem 17. Juli kann bei fehlenden kritischen Änderungen eine gute Grundlage sein – aber nur zusammen mit Updates, Zugangsschutz und einer sauberen Prüfung.

Sie möchten nicht selbst einschätzen, ob Ihre Website betroffen ist, oder brauchen Hilfe bei Prüfung, Bereinigung und sicherer Wiederherstellung? Ich stehe Ihnen dabei gern zur Seite. Kontaktieren Sie mich, dann schauen wir gemeinsam auf den tatsächlichen Zustand Ihrer WordPress-Seite.