wp2shell: Kritische WordPress-Sicherheitslücke (CVE-2026-63030) — sofort patchen und bereinigen

Am 17. Juli 2026 hat WordPress mit den Versionen 7.0.2, 6.9.5 und 6.8.6 eine kritische Sicherheitslücke im CVSS-Höchstbereich (9.8) geschlossen — genannt «wp2shell». Über eine Verwechslung in der REST-Batch-Schnittstelle konnten anonyme Angreifer ohne Login Schadcode auf einer ganz normalen WordPress-Installation ausführen: kein Plugin, kein Benutzerkonto, keine besondere Konfiguration nötig.

WordPress hat automatische Updates erzwungen, und das hat viele Seiten geschützt. Trotzdem sind bereits innerhalb von 24 Stunden nach der Veröffentlichung aktive Angriffe beobachtet worden. Und wer die Lücke abbekommen hat, steht vor einem oft übersehenen Problem: Ein Update schliesst das Loch, entfernt aber keine Hintertür, die ein Angreifer vorher hinterlassen hat.

Was ist die wp2shell-Lücke?

wp2shell ist eine Angriffskette aus zwei Schwachstellen im WordPress-Core: einer Routen-Verwechslung in der REST-Batch-Schnittstelle (CVE-2026-63030), die die Berechtigungsprüfung umgeht, und einer SQL-Injection in WP_Query über den Parameter author__not_in (CVE-2026-60137). Verkettet erlauben sie einem nicht angemeldeten Angreifer, aus der Ferne beliebigen Code auszuführen (Remote Code Execution).

Die Batch-Schnittstelle (/wp-json/batch/v1) kam mit WordPress 6.9 und bündelt mehrere API-Aufrufe in eine Anfrage, um die Performance zu verbessern. Genau auf diesem Pfad lässt die Routen-Verwechslung eine anonyme Anfrage an der Zugriffskontrolle vorbei. Entdeckt und verantwortungsvoll gemeldet wurde die Kette von Adam Kues von Searchlight Cyber (ehemals Assetnote).

Wie gefährlich ist das wirklich?

Sehr. Der Angriff braucht keine Vorbedingungen: keine Anmeldedaten, keine installierten Plugins, keine besondere Einstellung — eine Standard-Installation genügt. Deshalb der Höchst-Schweregrad. Weil bereits ein funktionierender Angriffscode öffentlich kursiert und Angriffe unmittelbar nach der Veröffentlichung liefen, hat WordPress erzwungene automatische Updates aktiviert. Das ist selten und unterstreicht die Dringlichkeit.

Für die meisten Seiten mit aktivem Auto-Update ist die eigentliche Lücke damit bereits geschlossen. Das grössere Risiko liegt jetzt bei zwei Gruppen: Seiten, auf denen automatische Updates deaktiviert sind, und Seiten, die in dem kurzen Fenster vor dem Patch bereits kompromittiert wurden.

Für Webseitenbetreiber: Was bedeutet das für Ihre Website?

Prüfen Sie zuerst, welche WordPress-Version läuft (unter Dashboard → Aktualisierungen oder Werkzeuge → Website-Zustand). Steht dort 6.8.6, 6.9.5 oder 7.0.2, ist die Lücke geschlossen. Falls nicht: sofort aktualisieren — im Zweifel nach einer kurzen Sicherung. Danach die Frage, die viele vergessen: Wurde meine Seite in der Zwischenzeit angegriffen? Anzeichen sind unbekannte Administrator-Konten, seltsame Dateien im Verzeichnis /wp-content/ oder plötzliche Weiterleitungen und Spam-Inhalte.

Wenn Sie unsicher sind oder Auffälligkeiten sehen: warten Sie nicht ab. Wir prüfen Ihre Installation, bereinigen sie bei Bedarf und härten sie ab — siehe WordPress Security & Härtung. Wer die Seite dauerhaft aktuell und überwacht halten will, ist mit einer laufenden WordPress-Wartung gut aufgestellt — genau solche Notfall-Updates spielen wir dort sofort ein. Wie Sie Updates generell sicher einspielen, zeigt unser Update-Leitfaden; die wichtigsten Sicherheits-Grundlagen fassen wir separat zusammen.

Für Agenturen und Entwickler: die technische Einordnung

Die Kette nutzt die Routen-Verwechslung auf /wp-json/batch/v1, um die Autorisierung zu umgehen, und darüber die SQL-Injection in WP_Query (author__not_in). Hat der MySQL-Benutzer das FILE-Recht, lässt sich per INTO OUTFILE eine PHP-Webshell direkt auf die Platte schreiben — aus SQL-Injection wird Code-Ausführung. Zwei defensive Sofortmassnahmen, die den Kern der Eskalation adressieren: dem Datenbank-Benutzer das FILE-Recht entziehen (WordPress braucht es im Normalbetrieb nicht) und Datei-Edits im Backend abschalten.

-- In der Datenbank als root (Benutzernamen anpassen):
REVOKE FILE ON *.* FROM 'wp_user_name'@'localhost';
FLUSH PRIVILEGES;

// In wp-config.php — verhindert Plugin-/Theme-Editor und -Installation:
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

Kompromittierte Seite bereinigen: Schritt für Schritt

Die folgenden Schritte fassen einen ausführlichen Community-Bereinigungsleitfaden aus dem r/Wordpress-Forum zusammen und ordnen ihn ein. Sie richten sich an technisch versierte Betreiber. Machen Sie vor jeder Änderung ein vollständiges Backup von Dateien und Datenbank. Wenn Sie sich unsicher sind, überlassen Sie die Bereinigung besser uns — eine unvollständig gesäuberte Seite wird oft erneut übernommen.

1. Dateisystem säubern (per FTP/SSH). Angreifer legten laut dem Leitfaden Webshells mit kryptischen Namen (z. B. e042u9xy9ra1.php) im Cache-Ordner /wp-content/cache/ ab und tarnten Hintertüren als Sicherheits-Patch in /wp-content/mu-plugins/ (etwa galex_patch.php). Entfernen Sie alle Dateien, die Sie nicht selbst angelegt haben, und prüfen Sie auch /wp-content/plugins/ auf unbekannte Einträge.
2. Core aktualisieren. Auf 6.8.6, 6.9.5 oder 7.0.2 heben — das schliesst die eigentliche Lücke in der Batch-Schnittstelle.
3. Benutzer, Passwörter und Sitzungen. Alle Passwörter neu setzen (besonders Administratoren) und das MySQL-Passwort ändern (in wp-config.php nachziehen). Neue Secret-Keys aus dem offiziellen Salt-Generator in wp-config.php eintragen — das wirft alle aktiven Sitzungen (auch die des Angreifers) hinaus. Prüfen Sie die Benutzerliste auf heimlich angelegte Admin-Konten.
4. Datenbank bereinigen. Der Leitfaden beschreibt manipulierte Einträge mit fixem Datum 2020-01-01 00:00:00 und einer Payload auf example.invalid. Prüfen Sie vor dem Ausführen, ob Ihr Tabellen-Präfix wirklich wp_ ist.

-- Gefälschte Changesets und Menü-Einträge entfernen:
DELETE FROM wp_posts WHERE post_type = 'customize_changeset' AND post_date = '2020-01-01 00:00:00';
DELETE FROM wp_posts WHERE post_type = 'nav_menu_item'      AND post_date = '2020-01-01 00:00:00';
-- Schädliche Metadaten entfernen:
DELETE FROM wp_postmeta WHERE meta_value LIKE '%example.invalid%';

Zum Abschluss absichern: dem Datenbank-Benutzer das FILE-Recht entziehen und Datei-Edits abschalten (siehe die beiden Code-Beispiele weiter oben). Danach die Seite auf verbliebene Spuren scannen — im Zweifel aus einem nachweislich sauberen Backup wiederherstellen.

Fazit

wp2shell zeigt zwei Dinge deutlich. Erstens: Sicherheit ist kein einmaliger Zustand, sondern läuft mit — die erzwungenen Auto-Updates haben viel abgefangen, aber nur dort, wo sie aktiv waren. Zweitens: Bei einem echten Treffer ist das Update erst der Anfang; die eigentliche Arbeit ist die saubere Bereinigung und Härtung. Genau dieses Zusammenspiel aus schnellem Patchen, Überwachung, geprüften Backups und Härtung ist der Kern einer betreuten WordPress-Seite — und der Unterschied zwischen ein paar Stunden Aufwand und einem Totalschaden.

Häufig gestellte Fragen zu wp2shell

Quellen

• WordPress Security Team — REST API batch-route confusion and SQL injection leading to RCE (offizielles Advisory) (2026)
• WordPress.org News — WordPress 7.0.2 (Sicherheits-Release) (17. Juli 2026)
• SecureLayer7 — wp2shell: Pre-Auth RCE (CVE-2026-63030 / CVE-2026-60137) (2026)
• Help Net Security — Two new high severity WordPress vulnerabilities, patch immediately (18. Juli 2026)
• r/Wordpress (Community-Leitfaden) — Guide: Complete cleanup and securing of WordPress (2026)