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

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.

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.

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.

Die unbequeme Einordnung

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 vierzig Installationen einzeln per Hand in vierzig 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 verwundbar und wird seit dem 17. Juli 2026 aktiv angegriffen. Jeder Tag, den eine betroffene Version noch online steht, ist ein Tag zu viel. 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.

---

Quellen

• Tenable: wp2shell WordPress Core Pre-Auth RCE FAQ
• WordPress.org: Release-Ankündigung zu 7.0.2 vom 17. Juli 2026
• Rapid7: CVE-2026-63030 wp2shell, Remote Code Execution in WordPress Core
• Qualys ThreatPROTECT: Exploited in the Wild