Ein POST-Request übernimmt eine Standard-WordPress-Seite. Heute auf 7.0.2 patchen.

Am 17. Juli veröffentlichte WordPress Version 7.0.2 – und das war kein normales Point-Release. Es schließt eine Angriffskette, die Forscher wp2shell nannten: zwei Sicherheitslücken, die zusammen einem anonymen Angreifer ermöglichen, Code auf einer Standard-WordPress-Installation auszuführen. Kein Login. Kein anfälliges Plugin. Kein seltsames Theme. Ein einziger präparierter POST an die REST-API, und der Server kann mit einem neuen Administratorkonto und einer Shell enden, die auf Befehle antwortet.

Die Kette umfasst zwei CVEs. CVE-2026-63030 ist eine Route/Handler-Verwechslung im REST-API-Batch-Endpunkt, als kritisch eingestuft und in Version 6.9 eingeführt. CVE-2026-60137 ist eine SQL-Injection in der WP_Query-Behandlung von author__not_in, als hoch eingestuft, und reicht bis zurück zu Version 6.8. Jede für sich ist bereits ein Problem. In Kombination hebt die Batch-Endpunkt-Verwechslung die Validierung von der Ausführung ab und leitet nicht validierte Eingaben direkt in die SQL-Injection – das Ergebnis ist Pre-Authentication-Remote-Code-Execution. WordPress hat erzwungene Auto-Updates für betroffene Seiten aktiviert, was zeigt, wie ernst das Core-Team das Risiko einschätzt. Patchstack berichtet, dass in den eigenen Logs bereits Ausnutzungsversuche zu sehen sind.

Hier ist die Versionsübersicht. Die vollständige RCE-Kette betrifft die Versionen 6.9.0 bis 7.0.1. Der 6.8-Zweig enthält nur die SQL-Injection, nicht die Route-Verwechslung, die sie ohne Login erreichbar macht. Fixes sind in 6.8.6, 6.9.5 und 7.0.2 gelandet, sowie ein 7.1 beta2 für alle, die den nächsten Branch testen. Die Route-Verwechslung wurde von Adam Kues bei Assetnote, dem Forschungsarm von Searchlight Cyber, über das HackerOne-Programm von WordPress gemeldet. Die SQL-Injection wurde separat von TF1T, dtro und haongo gemeldet.

Warum diese Lücke schlimmer ist als eine gewöhnliche WordPress-CVE

Die meisten WordPress-Sicherheitslücken stecken in Plugins. Diese lassen sich prüfen, einfrieren oder entfernen. Diese hier steckt im Core, auf einer Standard-Installation, und ist vor der Authentifizierung erreichbar. Diese Kombination ist selten – und genau das Profil, das Angreifer zuerst automatisieren. Ein Pre-Auth-Core-Bug in der Plattform, die einen Großteil des Webs betreibt, ist ein Massen-Scan-Ereignis, kein gezielter Angriff. Öffentliche Proof-of-Concept-Skripte erschienen innerhalb eines oder zweier Tage nach der Offenlegung, und erzwungene Updates erreichen nur Seiten, bei denen Auto-Update aktiviert ist und die tatsächlich eine Verbindung herstellen. Viele tun das nicht.

Es gibt ein operatives Detail, das der Erwähnung wert ist. Berichte über den Bug halten fest, dass der RCE-Pfad am leichtesten erreichbar ist, wenn eine Seite keinen persistenten Objekt-Cache betreibt – was bei vielen kleinen und mittelgroßen Installationen die Standardeinstellung ist. Die Seiten, die am wenigsten abgehärtet sind, sind daher am stärksten gefährdet. Das deckt sich mit dem, was wir bei Pentesting-Engagements für Gaming-Studios sehen: Das eigentliche Risiko liegt meist in der langweiligen Standardkonfiguration, nicht in dem exotischen Sonderfall, über den alle nachdenken.

Was Sie diese Woche tun sollten

Erstens: Patchen Sie. Wenn Sie WordPress 6.8 bis 7.0.1 irgendwo betreiben, wechseln Sie jetzt zu 7.0.2 oder dem entsprechenden Backport 6.9.5 oder 6.8.6 – nicht beim nächsten Wartungsfenster. Bestätigen Sie dann, dass das Update tatsächlich angewendet wurde. Erzwungene Auto-Updates können hinter einem Reverse-Proxy oder auf einem gesperrten Dateisystem stillschweigend fehlschlagen – prüfen Sie daher die gemeldete Version, anstatt darauf zu vertrauen, dass der Mechanismus seinen Job erledigt hat.

Zweitens: Gehen Sie davon aus, dass die Zeit zwischen der Veröffentlichung von 6.9 und dem 17. Juli ein offenes Fenster war, und suchen Sie nach Anzeichen dafür, dass jemand hindurchgegangen ist. Prüfen Sie auf Administratorbenutzer, die Sie nicht kennen, unerwartete Dateien unter wp-content/plugins/ und ausgehende Verbindungen vom Webhost, die Sie sich nicht erklären können. Ein sauberer Patch macht eine bereits stattgefundene Kompromittierung nicht rückgängig, und dieser Bug hinterlässt einem Angreifer genau die Art von beständigem Zugang, der ein Update überlebt.

Drittens: Platzieren Sie eine Kontrolle vor der Anwendung, nicht nur darin. Cloudflare hat am Tag der Offenlegung eine Notfall-WAF-Regel eingeführt. Wenn wir Cloudflare für Kunden konfigurieren, die DDoS-Schutz und eine WAF benötigen, verschafft eine verwaltete Regel für eine frische Core-CVE wie diese Stunden oder Tage Deckung, während ein Patch eine Flotte von Sites durchläuft. Aus unserer Arbeit mit Reiseplattformen wissen wir: Dieses virtuelle Patch-Fenster ist oft der Unterschied zwischen einer Reaktion innerhalb von Minuten und einer Reaktion im Nachhinein.

Für Teams, die allgemein mit PHP entwickeln, ist die eigentliche Lektion eine über Vertrauensgrenzen. Diese Kette funktionierte, weil eine Validierungsschicht und eine Ausführungsschicht unterschiedlicher Meinung darüber waren, was die Anfrage enthielt. Wir sehen dieselbe Art von Bug ständig in benutzerdefinierten Anwendungen: Eingaben werden an einer Stelle geprüft und an einer anderen verarbeitet, und die beiden driften auseinander, bis ein Angreifer etwas dazwischenschiebt. In unserer PHP- und Docker-Arbeit ist die Gewohnheit, die dies auffängt, jeden Request als feindlich zu behandeln, bis genau die Schicht, die die Abfrage ausführt, ihn erneut validiert hat. Eine Validierung, die drei Funktionen von der Datenbank entfernt stattfindet, ist keine Validierung, auf die Sie sich verlassen können.

Wir führen diese Art von Pre-Auth-Review für Enterprise-Kunden mit echten Compliance-Anforderungen durch, und der Hintergrund unseres Teams liegt darin, den Request zu finden, der nicht funktionieren sollte, es aber tut. Wenn „Wir haben gepatcht, aber wir sind nicht sicher, ob vorher nichts eingedrungen ist“ vertraut klingt, sprechen Sie uns an.