wp2shell: eine anonyme Anfrage und Ihr WordPress gehört nicht mehr Ihnen

Was genau gefunden wurde

Adam Kues aus dem Assetnote-Team (Searchlight Cyber) meldete eine Kette aus zwei Fehlern.

Der erste ist eine SQL-Injection im Parameter author__not_in der Klasse WP_Query, geführt als CVE-2026-60137. TF1T, dtro und haongo meldeten sie unabhängig voneinander. Für sich genommen erlaubt sie, aus der Datenbank Dinge auszulesen, die dort niemand herausgeben sollte.

Der zweite betrifft den Sammel-Endpunkt der REST-API unter /wp-json/batch/v1. Es ist eine Routenverwechslung, geführt als CVE-2026-63030 und eingestuft als CWE-436, ein Interpretationskonflikt. CVSS 9.8.

Zusammen ergeben sie eine nicht authentifizierte Code-Ausführung. Searchlight veröffentlicht die technischen Details bewusst nicht, um Verteidigern Zeit zu geben. Veröffentlicht wurde stattdessen eine Seite, auf der Sie Ihre Instanz prüfen können, sowie ein fertiges Plugin, das anonyme Anfragen an den Batch-Endpunkt abweist.

Cloudflare ergänzt einen wichtigen Punkt: Der verwundbare Pfad ist nur erreichbar, wenn die Instanz ohne persistenten Objekt-Cache läuft. Das trifft auf die meisten kleinen und mittleren Websites zu, denn Redis oder Memcached ist auf dieser Ebene selten.

Wen es betrifft

• Versionen 6.9.0 bis 6.9.4: für beide Fehler anfällig. Der Patch ist in 6.9.5.
• Versionen 7.0.0 und 7.0.1: für beide Fehler anfällig. Der Patch ist in 7.0.2.
• Der Zweig 6.8: nur für die SQL-Injection anfällig. Der Patch ist in 6.8.6.
• Älter als 6.8: nicht betroffen.
• Die Beta 7.1: behoben in 7.1 beta2.

WordPress hat die Sache ernst genug genommen, um erzwungene automatische Updates für die anfälligen Versionen zu aktivieren. Das ist die richtige Entscheidung, und gleich erkläre ich, warum sie das Thema trotzdem nicht abschließt.

Was das für Ihr Unternehmen bedeutet

Code-Ausführung auf einem Webserver ist mehr als eine verunstaltete Startseite. Der Angreifer bekommt einen PHP-Prozess und damit die Datei wp-config.php mit den vollständigen Zugangsdaten zur Datenbank. Diese Datenbank enthält üblicherweise Einträge aus Kontaktformularen, E-Mail-Adressen, manchmal Lebensläufe aus dem Karrierebereich, manchmal Bestelldaten, wenn WooCommerce im Spiel ist.

In der Praxis bedeutet das einen meldepflichtigen Datenschutzvorfall, 72 Stunden Frist zur Meldung an die Aufsichtsbehörde nach DSGVO und ein Gespräch mit der Geschäftsleitung darüber, warum eine Marketing-Website Bewerbungsdaten vorgehalten hat.

Dazu kommt Shared Hosting. Es bleibt selten bei einer einzigen übernommenen Instanz, denn Anbieter isolieren die Nachbarn im selben übergeordneten Verzeichnis schlechter, als es das Angebot verspricht.

Vier Dinge, die wir bei jedem solchen Patch sehen

Das Problem liegt selten im Update selbst. Es liegt in dem, was niemand gezählt hat.

Niemand weiß, wie viele WordPress-Instanzen er hat. Die Hauptwebsite steht immer im Inventar. Aber bei der Aufnahme der Angriffsfläche taucht regelmäßig eine Kampagnenseite von vor zwei Jahren auf einer eigenen Subdomain auf, eine Testkopie unter einer Adresse, die die Agentur abzuschalten vergessen hat, und ein Blog, den jemand einst „vorübergehend“ auf ein anderes Hosting verschoben hat. Diese Instanzen haben weder Eigentümer noch Monitoring, und genau sie laufen im nächsten Quartal noch mit Version 6.9.3.

Ein erzwungenes Update und ein bestätigtes Update sind zweierlei. Ein Update des WordPress-Core kann still fehlschlagen: Dateirechte nach einer Migration, ein Container mit schreibgeschütztem Dateisystem, ein Eintrag WP_AUTO_UPDATE_CORE, den ein Entwickler vor drei Jahren auf false gesetzt hat, weil einmal etwas kaputtging. Danach hat es niemand rückgängig gemacht. Schauen Sie in das Panel und prüfen Sie die Versionsnummer.

Eine halbe Sperre ist keine Sperre. Der Endpunkt antwortet in zwei Formen: /wp-json/batch/v1 und ?rest_route=/batch/v1. Die zweite funktioniert selbst dort, wo sprechende Permalinks deaktiviert sind. Eine Regel sperrt den ersten Pfad, jemand hakt die Aufgabe ab, der zweite bleibt offen. Wir haben genau dieses Muster bei früheren REST-API-Patches gesehen, und ich rechne diesmal mit demselben.

Die Ruhe hält nicht an. Bis zum 18. Juli hat niemand funktionierenden Code veröffentlicht oder Ausnutzungsversuche im Netz bestätigt. Das bedeutet wenig. WordPress ist quelloffen, und die Pakete 7.0.1 und 7.0.2 liegen im öffentlichen Archiv nebeneinander. Der Vergleich zweier Versionen ist der übliche Weg vom stillen Patch zum funktionierenden Exploit, und das massenhafte Angreifen von WordPress ist seit Jahren ein regelmäßiges Geschäft.

Was heute zu tun ist

• Aktualisieren Sie den Core auf 7.0.2, 6.9.5 oder 6.8.6, je nach Zweig. Öffnen Sie danach das Panel und sehen Sie nach, welche Version tatsächlich läuft.
• Erstellen Sie eine Liste aller WordPress-Instanzen im Unternehmen, auch der Instanzen, die Sie nicht selbst betreuen. TLS-Zertifikate und DNS-Einträge sind der schnellste Weg, sich an vergessene Subdomains zu erinnern.
• Wenn ein Update heute nicht infrage kommt, sperren Sie den anonymen Zugriff auf beide Formen des Endpunkts oder installieren Sie das Plugin, das solche Anfragen in rest_pre_dispatch abweist. Das ist eine Zwischenlösung und kann funktionierende Integrationen beschädigen.
• Sichern Sie die Logs von Webserver, WAF und Hosting, bevor Sie irgendetwas anderes tun. Falls sich herausstellt, dass jemand schneller war, sind sie das einzige Beweismaterial.
• Prüfen Sie Administratorkonten, seit dem Einspielen der anfälligen Version geänderte Dateien, geplante WP-Cron-Aufgaben und Plugins, die niemand bewusst installiert hat.

Suchen Sie nicht nach fertigen Kompromittierungsindikatoren mit Dateinamen oder IP-Adressen. Die öffentlichen Meldungen nennen sie nicht, also ist alles, was unter diesem Stichwort kursiert, Raterei.

Ein Fazit für länger

Die REST-API von WordPress galt jahrelang als internes Interface des Block-Editors. Sie ist standardmäßig aktiv, antwortet anonym und wächst mit jeder Core-Version. Jedes Mal, wenn wir im Projekt fragen, ob jemand geprüft hat, was sich unter /wp-json ohne Anmeldung aufrufen lässt, lautet die Antwort „das ist doch nur eine API“.

Wie viele WordPress-Instanzen hat Ihr Unternehmen? Stellen Sie diese Frage im nächsten Teammeeting und zählen Sie, wie oft „vermutlich“ oder „das müssten wir bei der Agentur nachfragen“ fällt. Die Zahl dieser Vermutungen zeigt Ihre tatsächliche Angriffsfläche.