Was wp2shell tatsächlich anrichtet

Als Adam Kues von Assetnote eine präparierte Anfrage an eine gewöhnliche WordPress-Installation schickte, führte der Server seinen Code aus. Kein Konto, kein Passwort, kein Plugin, keine ungewöhnliche Einstellung. Die Forscher nannten die Kette wp2shell, WordPress vergab CVE-2026-63030, und beide Seiten stuften sie als kritisch ein.

Der Angriff verbindet zwei Schwächen in der Batch-Route der REST-API: eine Verwirrung beim Routing, die einem nicht angemeldeten Aufrufer Zugriff auf eigentlich geschützte Codepfade gibt, und eine darüber erreichbare SQL-Injection. Verkettet machen sie aus einer anonymen HTTP-Anfrage eine Codeausführung, das schwerste Ergebnis, das eine Web-Lücke haben kann.

Warum der automatische Patch nicht die Ziellinie ist

WordPress veröffentlichte 6.9.5 und 7.0.2 am 17. Juli 2026 und erzwang die Updates angesichts der Schwere, statt auf einen Klick der Betreiber zu warten. Das ist richtig, und die meisten Seiten sind nun geschlossen. Es verdeckt aber die schwierigere Frage.

Eine Lücke ohne Anmeldung bedeutet, dass jeder im Netz sie vor Ihrem Patch nutzen konnte, und die Installation des Fixes macht das nicht rückgängig. War Ihre Seite im Zeitfenster erreichbar und ungepatcht, entfernte das Update die Tür, aber nicht das, was hindurchging: ein untergeschobenes Admin-Konto, eine geplante Aufgabe, eine Webshell im Upload-Ordner.

Warum fast jeder Seitenbetreiber betroffen ist

Das steckte im Kern, der Software, die jede WordPress-Seite ausführt, also hängt die Gefährdung nicht an einem Nischen-Plugin oder Theme. WordPress betreibt fast 40 Prozent des Webs, und deshalb ist eine einzelne Kernlücke dieser Klasse ein Massenereignis und kein Randfall.

Die Versionen 6.9.0 bis 6.9.4 und 7.0.0 bis 7.0.1 waren für wp2shell anfällig. Der zweite Fehler, eine SQL-Injection im Parameter author__not_in von WP_Query mit CVSS 9.1, reicht bis 6.8 zurück, sodass eine Seite, die einige Monate kein Update einspielte, das größere der beiden Zeitfenster trug.

Was EU-Regeln daraus machen

Für ein europäisches Unternehmen ist die Lücke nicht nur technisch. Liegen hinter der Seite personenbezogene Daten, gibt Ihnen die DSGVO 72 Stunden, um Ihre Aufsichtsbehörde zu benachrichtigen, sobald Sie von einer Verletzung erfahren, und 'wir können es nicht ausschließen' liegt näher an diesem Wissen als an Beruhigung.

Für wesentliche und wichtige Einrichtungen unter NIS2 löst ein Vorfall dieser Schwere eine eigene Frühwarn- und Meldefrist aus, und Aufsichtsbehörden erwarten zunehmend Nachweise der Erkennung, nicht nur ein Patch-Protokoll. Ein erzwungenes Auto-Update ist eine Verteidigung, die Sie nicht gewählt haben; ob Sie danach auf Kompromittierung geprüft haben, steht in Ihrem Protokoll.

Die Prüfung, die jetzt ansteht

Bestätigen Sie, dass die Seite auf 6.9.5 oder 7.0.2 läuft, und behandeln Sie dann das Zeitfenster als die eigentliche Arbeit. Prüfen Sie im Juli angelegte Admin-Konten und Anwendungspasswörter, sehen Sie geplante Aufgaben und kürzlich geänderte PHP-Dateien durch, und ziehen Sie die Webserver-Logs auf ungewöhnliche POST-Anfragen an die REST-API rund um das Veröffentlichungsdatum.

Wenn Sie Managed WordPress nutzen, fragen Sie Ihren Hoster schriftlich, wann der Patch kam und ob er Angriffsversuche gegen Ihre Seite sah. Die ehrliche Antwort auf 'wurden wir getroffen' kommt selten sofort, aber die Betreiber, die diese Woche fragen, müssen nächstes Quartal keinen stillen Einbruch erklären.

Weiterlesen: Ein totes Gebäude kostet mehr als ein Lösegeld  |  Ihre Sandbox fiel einen Monat vor der Warnung