WordPress 7.0.2 behebt kritische nicht authentifizierte SQL-Injection

WordPress 7.0.2 behebt eine kritische nicht authentifizierte SQL-Injection-Schwachstelle, die in Kombination mit einem REST-API-Routenverwechslungsfehler Angreifern die vollständige Übernahme einer Website ermöglichen könnte, so die Sicherheitsfirma Patchstack. Das am 17. Juli 2026 veröffentlichte Release behebt zwei separate Probleme, die zusammen eine Kette für Remote-Code-Ausführung bilden. Patchstack hat separat bestätigt, dass die kombinierten Schwachstellen zu vollständigen Website-Übernahmen führen können, und beobachtet bereits aktive Exploit-Versuche in seinen Logs.

Die beiden Schwachstellen werden als CVE-2026-60137 für die SQL-Injection in WP_Query und CVE-2026-63030 für die REST-API-Batch-Routen-/Handler-Verwechslung verfolgt. Das erste Problem betrifft WordPress-Versionen 6.8 bis 7.0.1, während das zweite in 6.9 eingeführt wurde und ebenfalls bis 7.0.1 betrifft. Das WordPress-Kernteam veröffentlichte Fixes in drei Zweigen: WordPress 7.0.2 behebt beide, 6.9.5 ist ein Backport beider auf den 6.9-Zweig, und 6.8.6 ist von der Routenverwechslung nicht betroffen, enthält aber den SQL-Injection-Patch. Da die Schwachstelle nicht authentifiziert und massenausnutzbar ist, hat WordPress ein erzwungenes Update auf betroffene Websites ausgerollt, aber Website-Besitzer sollten dennoch bestätigen, dass sie eine gepatchte Version verwenden.

Der SQL-Injection-Fehler, gemeldet von den Forschern TF1T, dtro und haongo, liegt in der Art, wie WP_Query, die WordPress-Klasse, die Datenbankabfragen erstellt, die Abfragevariable author__not_in verarbeitet. In betroffenen Versionen wurde die Eingabe nur bereinigt, wenn sie als Array ankam. Wenn ein Angreifer erreicht, dass der Wert als Zeichenkette ankommt, wird die Integer-Bereinigung vollständig übersprungen. Die rohe Zeichenkette wird dann in ein Array umgewandelt, verknüpft und direkt in die SQL-WHERE-Klausel eingefügt, ohne ordnungsgemäßes Escaping oder Parameterisierung. Für sich genommen ist dies normalerweise nicht erreichbar, da die REST-API den Parameter author_exclude als Array von Ganzzahlen validiert. Aber die zweite Schwachstelle ändert diesen Verarbeitungspfad.

Der kritische REST-API-Fehler, gemeldet von Adam Kues von Assetnote / Searchlight Cyber, betrifft den Batch-Endpunkt in WP_REST_Server::server_batch_request_v1(). Dieser Endpunkt ermöglicht es einem Client, mehrere Unteranfragen in einem Aufruf zu bündeln. Der Handler erstellt zwei Arrays: eines für alle Anfragen und eines für passende Handler. Eine Index-Desynchronisation entsteht, weil Fehlereinträge nicht zum matches-Array hinzugefügt werden. Ein Angreifer kann zuerst eine Unteranfrage mit dem Pfad http:// senden, was die URL-Analyse fehlschlagen lässt und einen Fehler an Index 0 ohne entsprechenden Treffer erzeugt. Danach ist jede spätere Handler-Suche um eins verschoben. Durch Verschachteln eines zweiten Batches bringt der Angreifer eine Anfrage wie GET /wp/v2/posts?author_exclude= so unter, dass sie gegen einen anderen Handler validiert wird, den POST-Erstellen-Beitrags-Handler, wo author_exclude kein registrierter Sammlungsfilter ist und seine normale Array-von-Ganzzahlen-Validierung nie ausgeführt wird. Dann wird sie gegen den verschobenen Treffer für die GET-Sammlungsroute ausgeführt, wodurch die nicht authentifizierte Funktion get_items() mit einem nicht validierten author_exclude aufgerufen wird. Der Fix in 7.0.2 hält die Arrays index-ausgerichtet, indem er auch Fehler in das matches-Array aufnimmt, und fügt einen Re-Entrancy-Schutz hinzu, um zu verhindern, dass ein neuer Top-Level-REST-Zyklus startet, während ein Dispatch läuft.

Die kombinierte Kette ist schwerwiegend: Ein nicht authentifizierter Angreifer kann die SQL-Injection ohne Konto erreichen, und Patchstack sagt, dass die Kette zu vollständiger Website-Übernahme führen kann, einschließlich Remote-Code-Ausführung, was bedeutet, dass der Angreifer eigenen Code auf dem Server ausführen kann. Patchstack hat seine RapidMitigate-Regeln für virtuelles Patchen sofort bereitgestellt und Exploit-Versuche in seinen Logs gesehen. Aufgrund der aktiven Ausnutzung und der nicht authentifizierten Natur behandelte das WordPress-Kernteam dies als Problem mit höchster Priorität und rollte ein erzwungenes Update auf betroffene Websites aus. Für Leser, die ihre eigenen Websites verwalten, ist der unmittelbare Schritt, zu überprüfen, dass die Website WordPress 7.0.2, 6.9.5 oder 6.8.6 ausführt, je nach Zweig. Es ist auch ratsam, Benutzerkonten auf nicht erkannte Administrator- oder Editor-Konten zu überprüfen, da Angreifer, die dies ausnutzen, Benutzer erstellen oder erhöhen können. Verwaltete WordPress-Hosting-Dienste wie AEU Hosting sind darauf ausgelegt, WordPress-Installationen zu sichern, was automatische Updates und Schutz auf Serverebene umfassen kann, aber Website-Besitzer sollten dennoch ihre Version wie empfohlen bestätigen.