WP2Shell: Die kritische WordPress-Core-Lücke und was jetzt zu tun ist

Das Wichtigste in 30 Sekunden

Betroffen: WordPress 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1, von der SQL-Injection allein auch 6.8. Gepatcht: 6.9.5, 7.0.2 und 6.8.6, erschienen am 17. Juli 2026.

Aktualisiert am 30.10.2026: Seit WP2Shell hat WordPress sechs weitere Sicherheitsreleases veröffentlicht, zuletzt 7.1.4 am 28. Oktober 2026. Ein Stand von 7.0.2 oder 6.9.5 schließt WP2Shell, ist heute aber nicht mehr sicher. Details im Abschnitt zum aktuellen Stand.

Sofort: Core-Version jeder betreuten Installation prüfen und alles unterhalb dieser Stände aktualisieren.

Danach: Das Update schließt die Lücke, entfernt aber keine bereits installierte Hintertür. Lief eine Installation im betroffenen Zeitraum öffentlich erreichbar, gehört eine Kompromittierungsprüfung dazu.

Worum es geht

Unter dem Namen WP2Shell wurden zwei Schwachstellen im WordPress-Core bekannt, die sich zu einer Angriffskette verbinden lassen. Sie beginnt bei der Verarbeitung von Batch-Anfragen der REST-API und endet bei ausführbarem Code auf dem Server.

Einzeln betrachtet ist jede der beiden ernst. In Kombination ergeben sie unauthentifizierte Remote-Code-Ausführung. Das bedeutet: Ein anonymer Angreifer ohne Benutzerkonto, ohne Passwort und ohne vorherigen Zugriff kann beliebigen Code auf dem Server ausführen. Das ist die Kategorie von Lücke, bei der die Frage nicht lautet, ob automatisierte Scanner deine Installation finden, sondern wann.

Betroffene Versionen

WordPress hat für diesen Fall erzwungene automatische Updates aktiviert. Das heißt aber nicht, dass jede Installation automatisch versorgt wurde: Wer Auto-Updates per WP_AUTO_UPDATE_CORE oder per Filter deaktiviert hat, wer eine Installation unter Versionskontrolle mit gepinntem Core betreibt, oder wer eine Composer-basierte Installation nutzt, bekommt diese Updates nicht.

WordPress 6.8 ist laut der Release-Ankündigung zu 7.0.2 nur von der ersten Schwachstelle betroffen, der SQL-Injection. Die vollständige Kette bis zur Codeausführung funktioniert dort nicht. Ein Grund zum Abwarten ist das nicht: 6.8.6 enthält den Fix und gehört genauso eingespielt.

Warum ausgerechnet professionelle Setups länger verwundbar waren

Bedrock-Installationen, in denen der Core über composer.json gepinnt ist, sind von erzwungenen Core-Updates ausgenommen. Wer nach dem Motto „Auto-Updates sind unprofessionell“ arbeitet, war in diesem Fall länger verwundbar als jede 08/15-Installation.

Der Ausweg ist kein Verzicht auf Versionskontrolle, sondern eine Constraint, die Patch-Releases durchlässt, kombiniert mit einer automatisierten Prüfung, die den Pull Request selbst erzeugt:

{
  "require": {
    "roots/wordpress": "~7.0.0"
  }
}

Der Tilde-Constraint ~7.0.0 erlaubt 7.0.1 und 7.0.2, blockiert aber den Sprung auf 7.1. Genau das ist gewollt: Security-Releases kommen durch, das Major-Release nicht. Dazu Dependabot oder Renovate auf das Repository ansetzen, damit ein neuer Patch-Stand binnen Stunden als Pull Request auftaucht, statt beim nächsten manuellen Blick in den Changelog.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: composer
    directory: "/"
    schedule:
      interval: daily
    allow:
      - dependency-name: "roots/wordpress"

Der entscheidende Schritt danach ist der, den die meisten auslassen: Ein Pull Request, der drei Wochen offen liegt, schützt genauso wenig wie gar keine Benachrichtigung. Core-Patch-Releases gehören in ein Zeitfenster von Stunden, nicht Tagen.

Stand 30.10.2026: was seitdem kam

Seit dem WP2Shell-Patch vom 17. Juli 2026 hat WordPress sechs weitere Sicherheitsreleases veröffentlicht. Die Versionen 6.9.5 und 7.0.2 schließen WP2Shell, sind aber selbst längst nicht mehr aktuell. Wer eine Installation auf diesem Stand angehalten hat, etwa über einen zu eng gesetzten Composer-Constraint, ist heute wieder verwundbar, nur gegen andere Lücken.

Am schwersten wiegt 7.1.2. Laut der Ankündigung auf wordpress.org konnte ein nicht angemeldeter Angreifer unter bestimmten Bedingungen erreichen, dass beim Auflösen eines Seiten-Templates eine lokale PHP-Datei außerhalb der Theme-Verzeichnisse eingebunden wird, mit möglicher Codeausführung als Folge. Das ist dieselbe Schwereklasse wie WP2Shell, keine Anmeldung nötig.

Für 7.1.2, 7.1.3 und 7.1.4 hat das WordPress-Team die Korrekturen auf alle noch unterstützten Zweige zurückportiert, derzeit bis 4.7. Wer nicht auf 7.1 wechseln kann, bekommt also auch auf 6.8, 6.9 oder 7.0 einen gepatchten Stand, allerdings nur mit der jeweils neuesten Version dieses Zweigs. Die Regel aus dem Composer-Abschnitt gilt damit weiter: Patch-Releases durchlassen, sofort einspielen.

Wie schnell wurde ausgenutzt?

Funktionierende Proof-of-Concept-Exploits tauchten innerhalb weniger Stunden nach der Offenlegung am 17. Juli 2026 auf. Innerhalb von drei Tagen nahm die US-Behörde CISA beide CVEs in den Katalog der bekannten ausgenutzten Schwachstellen auf, was aktive Angriffe bestätigt, und setzte Bundesbehörden eine Patch-Frist zum 24. Juli. Mehrere Sicherheitsanbieter meldeten parallel massenhafte Scan- und Angriffsversuche.

Das Zeitfenster zwischen „Lücke öffentlich“ und „Lücke wird massenhaft ausgenutzt“ betrug also nicht Wochen, sondern Stunden bis Tage. Für die Praxis heißt das: Ein Wartungsintervall von „einmal im Monat Updates“ ist bei Core-Sicherheitslücken dieser Klasse zu langsam.

Prüfen, ob deine Installation betroffen war

Version prüfen

wp core version

Oder ohne WP-CLI im Backend unter Dashboard → Aktualisierungen. Steht dort eine Version aus den betroffenen Bereichen, muss sofort aktualisiert werden.

Core-Dateien gegen das Original prüfen

Der schnellste verlässliche Test auf manipulierte Core-Dateien ist wp core verify-checksums. Der Befehl lädt die offiziellen Prüfsummen des installierten Release von wordpress.org und meldet jede Abweichung, auch neu hinzugefügte Dateien:

$ wp core verify-checksums
Warning: File doesn't verify against checksum: wp-includes/load.php
Warning: File should not exist: wp-includes/js/dist/vendor/wp-polyfill-fmt.php
Error: WordPress installation doesn't verify against checksums.

Die erste Zeile bedeutet: Eine Core-Datei wurde verändert. Die zweite ist der typischere Fund bei einer Kompromittierung, nämlich eine eingeschleuste Datei mit unauffälligem Namen an einem Ort, an dem niemand hinsieht. Eine saubere Installation antwortet mit Success: WordPress installation verifies against checksums.

Zwei Einschränkungen: Der Befehl prüft nur den Core, nicht Plugins und Themes, und er schlägt auch dann an, wenn jemand aus legitimen Gründen eine Core-Datei angefasst hat. Beides ändert nichts daran, dass ein Fund hier immer untersucht gehört.

Weitere Spuren

Ein Update schließt die Lücke, entfernt aber keine Hintertür, die vorher installiert wurde. Worauf zu achten ist:

• Unbekannte Administratorkonten: wp user list --role=administrator
• Kürzlich geänderte PHP-Dateien: find . -name "*.php" -mtime -30 -ls
• PHP-Dateien in Upload-Verzeichnissen: In /wp-content/uploads/ hat keine einzige .php-Datei etwas zu suchen
• Unerwartete geplante Aufgaben: wp cron event list
• Unbekannte Must-Use-Plugins in /wp-content/mu-plugins/. Ein beliebter Ort für Persistenz, weil diese Plugins im Backend nicht deaktivierbar angezeigt werden

Wenn der Verdacht sich bestätigt

Eine kompromittierte Installation wird nicht bereinigt, indem man die gefundene Datei löscht. Angreifer legen in der Regel mehrere Persistenzmechanismen an. Das saubere Vorgehen:

1. Seite vom Netz nehmen oder in den Wartungsmodus versetzen.
2. Vollständiges Backup ziehen, auch vom kompromittierten Zustand, für die spätere Analyse.
3. Alle Passwörter zurücksetzen: WordPress-Benutzer, Datenbank, FTP/SFTP, Hosting-Panel.
4. Core, Plugins und Themes aus offiziellen Quellen neu einspielen, nicht aus dem vorhandenen Dateibestand.
5. wp-content/uploads auf ausführbare Dateien prüfen und bereinigen.
6. Datenbank auf eingeschleuste Inhalte prüfen, insbesondere wp_options (active_plugins, siteurl, home) und wp_users.
7. Salts und Security Keys in der wp-config.php neu generieren, damit bestehende Sessions ungültig werden.
8. Erst dann wieder online gehen.

Die ausführliche Fassung dieses Ablaufs steht in WordPress gehackt: Erste Hilfe in 5 Schritten.

Und der Punkt, den viele vergessen: Wenn personenbezogene Daten betroffen sein könnten, greift die Meldepflicht nach Artikel 33 DSGVO mit einer Frist von 72 Stunden. Die Frist läuft ab Kenntnis, nicht ab Abschluss der Bereinigung.

Was der Fall über Reaktionszeiten sagt

Core-Lücken dieser Schwere sind bei WordPress selten. Die weitaus meisten Kompromittierungen laufen über veraltete Plugins, nicht über den Core, wie der Überblick zu den häufigsten WordPress-Angriffsvektoren zeigt. Genau deshalb ist dieser Fall lehrreich: Er trifft auch Installationen, die alles richtig gemacht haben, was Plugin-Hygiene angeht.

Was du schützt, ist nicht die Abwesenheit von Lücken, sondern die Geschwindigkeit, mit der du reagieren kannst. Wer für siebzig Installationen einzeln per Hand in siebzig Backends klickt, braucht Tage. Wer zentral verwaltet und Security-Releases automatisiert einspielt, braucht Minuten. Wie so ein Ablauf konkret aussieht, steht in WordPress-Updates sicher ausrollen.

Fazit

Prüf jetzt die Core-Version jeder Installation, die du betreust. Alles unterhalb 6.9.5 beziehungsweise 7.0.2 ist für WP2Shell verwundbar und wird seit dem 17. Juli 2026 aktiv angegriffen. Ausreichend ist heute aber nur die neueste Version des jeweiligen Zweigs, Stand 30.10.2026 also 7.1.4 oder der aktuelle Backport. Und wenn eine Installation seit der Offenlegung auf einer betroffenen Version lief, reicht das Update allein nicht aus.

Dann gehört eine Kompromittierungsprüfung dazu, und die ist mehr als ein Blick auf die Versionsnummer. Wenn du dir bei einer Installation nicht sicher bist, prüft ein WordPress-Sicherheitscheck von Hand Zugänge, Dateien und Serverumgebung und ordnet jeden Befund nach Risiko ein. Steht eine Seite bereits sichtbar unter Befall, ist die Bereinigung der schnellere Weg.

---

Quellen

• Tenable: wp2shell WordPress Core Pre-Auth RCE FAQ
• WordPress.org: Release-Ankündigung zu 7.0.2 vom 17. Juli 2026
• WordPress.org: Sicherheitsrelease 7.1.2 vom 22. September 2026, abgerufen am 30.10.2026
• WordPress.org: Sicherheitsrelease 7.1.4 vom 28. Oktober 2026, abgerufen am 30.10.2026
• WordPress.org: alle Release-Ankündigungen, abgerufen am 30.10.2026
• Rapid7: CVE-2026-63030 wp2shell, Remote Code Execution in WordPress Core
• Qualys ThreatPROTECT: Exploited in the Wild