Angreifer nutzten WordPress-Core-RCE innerhalb von 90 Minuten aus

Laut neuer Forschung von Patchstack begannen Angreifer nur 90 Minuten nach Veröffentlichung des gepatchten Releases eine kritische Remote-Code-Execution-Kette (RCE) im WordPress-Core auszunutzen. Der Sicherheitsanbieter, der Web Application Firewall- und Schwachstellendienste für WordPress verkauft, gibt an, in den Tagen nach der Offenlegung mehr als 65.000 Ausnutzungsversuche gegen die beiden zugrunde liegenden Schwachstellen blockiert zu haben. Diese Versuche stammten von mehr als 1.500 eindeutigen IP-Adressen, und fast alle zielten auf ungepatchte Websites mit verwundbaren WordPress-Versionen. Die Geschwindigkeit, mit der die Angriffskampagne begann, zeigt, dass Website-Besitzer fast keine Zeit zwischen der Veröffentlichung eines Fixes und dem Versuch von Kriminellen, den Fehler auszunutzen, haben.

Der Vorfall betrifft zwei separate Schwachstellen, die zu einer einzigen Übernahme kombiniert werden können. Die erste, CVE-2026-60137, ist eine SQL-Injection in einem Teil von WordPress namens WP_Query über den Parameter author_exclude oder author__not_in. Eine SQL-Injection tritt auf, wenn ein Angreifer Datenbankbefehle in Eingaben platziert, die die Website dann ausführt; in diesem Fall ist die Injection schreibgeschützt, das heißt, sie kann Informationen aus der Website-Datenbank lesen, aber nicht direkt darauf schreiben. Diese Schwachstelle betrifft WordPress-Versionen 6.8 bis 7.0.1. Die zweite Schwachstelle, CVE-2026-63030, ist eine Routen- und Handler-Verwechslung im REST-API-Batch-Endpunkt unter /batch/v1. Die REST-API ist eine Möglichkeit für externe Programme, mit WordPress zu kommunizieren, und der Batch-Endpunkt ermöglicht das gleichzeitige Senden mehrerer Aktionen. Diese Schwachstelle betrifft die Versionen 6.9 bis 7.0.1. Für sich genommen gibt keine der beiden Schwachstellen einem Angreifer die volle Kontrolle. Aber wenn sie verkettet werden, ermöglicht die Batch-Verwechslung, dass eine nicht authentifizierte Anfrage die SQL-Injection an den normalen Datenprüfungen vorbeischmuggelt, und ein öffentlicher Exploit erstellt dann ein neues Administrator-Konto und erlangt schließlich Remote Code Execution. Die Fixes wurden in WordPress 7.0.2, 6.9.5 und 6.8.6 veröffentlicht. Ältere Zweige wie 6.1 und 6.2 sind nicht betroffen, da der verwundbare Code erst in 6.8 und 6.9 eingeführt wurde.

Die Telemetrie von Patchstack zeigt, wie schnell die Kampagne begann. Der Fix wurde etwa 1,5 Stunden vor der Tagging-Version 7.0.2 in den WordPress-Entwicklungs-Trunk übernommen. Da jeder die Codeänderungen beobachten kann, fungierte dieser Commit praktisch als öffentliche Offenlegung. Die ersten echten Ausnutzungsversuche erreichten die Sensoren von Patchstack etwa 90 Minuten nach der Veröffentlichung von 7.0.2 und drei Stunden nach dem Fix-Commit. In den folgenden Tagen blockierte Patchstack mehr als 65.000 Ausnutzungsversuche von über 1.500 eindeutigen IP-Adressen. Das Unternehmen stellt fest, dass seine RapidMitigate-Funktion nur auf Websites, die tatsächlich eine verwundbare Version ausführen, Schadensbegrenzungsregeln aktiviert und diese Regeln nach dem Patchen der Website entfernt, sodass die blockierten Versuche alle auf ungepatchte Systeme abzielten. Der Datenverkehr wurde auch innerhalb der Anwendung selbst beobachtet, was bedeutet, dass jede Netzwerk- oder Server-Firewall vor der Website die Anfrage bereits durchgelassen hatte. Kein einzelnes Netzwerk dominierte den Datenverkehr; das verkehrsreichste Netzwerk machte nur 6,45 Prozent aus, und die Top-Ten-Netzwerke zusammen etwa 22 Prozent. Die angreifenden IPs stammten hauptsächlich von Cloud- und VPS-Anbietern wie Vultr (Choopa), M247 und HostPapa. Fast der gesamte blockierte Datenverkehr war frühe SQL-Injection-Sondierung, aber auf einer ungeschützten Website würde dieselbe Anfrage bis zur Admin-Erstellung und Code-Ausführung fortgesetzt.

Der Datenverkehr ergab ein klares Bild davon, wie Angreifer vorgingen. Fast 97 Prozent dessen, was Patchstack blockierte, zielte auf den REST-Batch-Endpunkt. Angreifer nutzten zwei Hauptwege, um dorthin zu gelangen: /?rest_route=/batch/v1 und /wp-json/batch/v1, wobei der erste häufiger war. Sie streuten auch Pfadvarianten wie /index.php?rest_route=/batch/v1, /wp/?rest_route=/batch/v1, /blog/?rest_route=/batch/v1 und /wp-json?rest_route=/batch/v1, um einfache Filterregeln zu umgehen. Etwa drei Viertel der blockierten Anfragen enthielten einen SQL-Injection-Versuch im Parameter author_exclude, und die Payloads verwendeten gemischte Groß-/Kleinschreibung, Inline-Kommentare, datenbankspezifische Bedingungskommentare und URL-Kodierung, um sich zu verstecken. Die Forscher teilten die Anfragen in zwei Gruppen ein. Die viel größere Gruppe waren Validierungssonden wie AND (1=1), AND (1=2) oder OR SLEEP(5), um zu prüfen, ob eine Website verwundbar war, bevor mehr Aufwand betrieben wurde. Eine viel kleinere, aber ernstere Gruppe trug die vollständige veröffentlichte Privilegieneskalationskette und ging direkt auf die Administrator-Erstellung zu, mit einer Batch-Anfrage, die POST /wp/v2/users aufrufen und Rollen auf Administrator setzen würde. Diese Versuche mit vollständiger Kette stammten von nur drei IP-Adressen: 129.121.77.134, 91.202.233.61 und 125.164.233.50.

Patchstack berichtet auch, dass seine eigenen RapidMitigate-Regeln für die beiden Schwachstellen in dem Moment bereitgestellt wurden, als der Hinweis herauskam, bevor die ersten Versuche eintrafen. Während der Kampagne wurden 99,9 Prozent aller blockierten Versuche durch diese beiden spezifischen WordPress-Core-Schwachstellenregeln gestoppt, während zusätzliche generische Regeln kaum registriert wurden. Dieses Ergebnis zeigt, dass Root-Cause-Regeln die Angriffe abfingen, bevor sie generische Auffangnetze erreichen konnten.

Für alle, die immer noch WordPress 6.9 bis 7.0.1 ohne den Patch ausführen, ist das Ergebnis schwerwiegend. Der öffentliche Exploit, der als Tool mit dem Spitznamen wp2shell verbreitet wird, nutzt die schreibgeschützte SQL-Injection, um Daten zu fälschen, auf die WordPress dann reagiert. Er sät Beiträge und eine Customizer-Änderung, die zu einem frischen Administrator-Konto führen. Sobald ein Angreifer dieses Admin-Konto hat, kann er sich anmelden, ein Plugin hochladen, das tatsächlich eine Web-Shell ist, und Code auf dem Server ausführen. Patchstack gibt an, unabhängig verifiziert zu haben, dass die kombinierten Schwachstellen zu einer vollständigen Site-Übernahme einschließlich Remote Code Execution führen. Website-Besitzer sollten nach unbekannten Administrator-Konten, unerwarteten Plugins, zufälligen PHP-Dateien im Uploads-Verzeichnis und allem Unerwarteten im mu-plugins-Ordner suchen, der automatisch lädt und nicht auf dem normalen Plugins-Bildschirm erscheint.

Es gibt auch eine Warnung bezüglich der Schadensbegrenzungsregeln selbst. Laut Patchstack hatten fast alle Web Application Firewall-Regeln, die in den ersten Stunden nach der Offenlegung veröffentlicht wurden, eine kritische blinde Stelle. Die Regeln suchten nach batch/v1 in der Anfrage-URL, da der öffentliche Proof-of-Concept-Code den Endpunkt so erreichte. Aber WordPress registriert rest_route als öffentliche Abfragevariable und liest diese Variablen aus dem POST-Body, bevor es sie aus der Query-String liest. Daher kann ein Angreifer eine einfache POST-Anfrage an das Website-Root senden, mit rest_route=/batch/v1 im Formular-Body und der Batch-Payload daneben, und WordPress leitet das Ganze an den Batch-Endpunkt. Die URL enthält nie batch/v1, sodass jede Regel, die nur die URL inspiziert, eine harmlose Anfrage an das Website-Root sieht und durchlässt. Eine Regel, die nur die URL prüft, kann mit einer kleinen Anfrageänderung umgangen werden. Patchstack entdeckte diese Lücke und behandelte sie als koordinierte Offenlegung, indem es zuerst betroffene Sicherheitsanbieter und das WordPress-Sicherheitsteam benachrichtigte, damit Hosts und DNS-Level-WAF-Anbieter ihre Regeln aktualisieren konnten, bevor der Bericht veröffentlicht wurde. Patchstack sagt, dass seine eigenen ersten Regeln dieselbe Lücke hatten, und hat sie nun aktualisiert, um nach der Batch-Route zu suchen, wo immer WordPress sie akzeptiert, sowohl in der URL als auch im POST-Body. Ab etwa 17:00 UTC am 21. Juli begann Patchstack, Ausnutzungsversuche zu sehen, die diese alternativen Formen verwendeten, mit rest_route und dem verschachtelten Anfragen-Array im POST-Body. Andere Hosts sahen dasselbe Muster und meldeten, dass ihre ursprünglichen URL-only-Regeln umgangen wurden.

Die wichtigsten Erkennungsindikatoren für diese Kampagne umfassen jede Anfrage an den Batch-Endpunkt in irgendeiner Form, wie /wp-json/batch/v1, ?rest_route=/batch/v1 oder rest_route=/batch/v1 im POST-Body, plus die Pfadvarianten. Webmaster sollten auch nach einem nicht ganzzahligen author_exclude-Wert suchen, insbesondere mit UNION, SLEEP( oder Kommentar-verschleiertem AND/OR, und die Schreibweisen author.exclude und author exclude abgleichen, da WordPress diese zurück zu author_exclude normalisiert. Jeder privilegierte REST-Schreibvorgang, der in einem Batch-Body verschachtelt ist, am häufigsten POST /wp/v2/users mit "roles":["administrator"], ist eine Flagge wert. Nachträglich umfassen Anzeichen einer Kompromittierung einen neuen Administrator, den Sie nicht erstellt haben, ein kürzlich hinzugefügtes Plugin, das Sie nicht erkennen, eine zufällige PHP-Datei unter wp-content/uploads oder wp-content/plugins und unerwartete Dateien in wp-content/mu-plugins.

Die wichtigste Lektion ist das Timing. Neunzig Minuten von einem öffentlichen Patch bis zur Live-Ausnutzung lassen keine Zeit, ein Wartungsfenster zu planen, ein Update zu testen und sicher auszurollen. Deshalb sind virtuelles Patchen und sofortiges Aktualisieren wichtig. Aktualisieren Sie auf WordPress 7.0.2, 6.9.5 oder 6.8.6, sobald Sie können, und wenn das in Tagen statt Minuten gemessen wird, stellen Sie sicher, dass etwas in der Zwischenzeit die Lücke füllt. Für Website-Besitzer, die verwaltetes WordPress-Hosting mit integrierter Sicherheit benötigen, bietet AEU Hosting (https://albhosting.eu) verwaltetes WordPress-Hosting mit durchgängiger Sicherheit, das helfen kann, das Expositionsfenster zu reduzieren, während ein Core-Update angewendet wird.