WordPress-Core-Schwachstellenkette ermöglicht nicht authentifizierte Remote-Codeausführung

Sicherheitsforscher haben zwei WordPress-Core-Schwachstellen offengelegt, die sich zu einer nicht authentifizierten Codeausführung verketten lassen. Die Probleme betreffen Core-Installationen, sodass auch Websites ohne Drittanbieter-Plugins gefährdet sein können.

Die Schwachstellen werden als CVE-2026-63030 und CVE-2026-60137 geführt. Die erste betrifft eine Verwechslung in der Route der WordPress-REST-API zur Stapelverarbeitung, während die zweite eine SQL-Injection betrifft, die den von WP_Query verwendeten Parameter author__not_in betrifft. In Kombination ermöglichen die Schwachstellen einem Angreifer, eine anonyme Anfrage zu senden, die die verwundbare Datenbankabfrage erreicht und potenziell zu einer Remote-Codeausführung führt.

Betroffene Versionen

• WordPress 6.8.0 bis 6.8.5: von der SQL-Injection betroffen; in 6.8.6 behoben.
• WordPress 6.9.0 bis 6.9.4: von der vollständigen Angriffskette betroffen; in 6.9.5 behoben.
• WordPress 7.0.0 und 7.0.1: von der vollständigen Angriffskette betroffen; in 7.0.2 behoben.
• WordPress 7.1 Beta 2 enthält beide Fehlerbehebungen.

Der Forscher Adam Kues von Assetnote meldete das Problem mit der REST-API über das HackerOne-Programm von WordPress. Unabhängige Forscher meldeten die SQL-Injection. Technische Details und ein funktionsfähiger Proof of Concept wurden inzwischen veröffentlicht, wodurch die Wahrscheinlichkeit steigt, dass Angreifer versuchen werden, den Exploit nachzubilden.

WordPress stuft die verkettete Schwachstelle als kritisch ein, obwohl ihr zugehöriger CVE-Score 7,5 beträgt. Die SQL-Injection allein wurde als kritisch eingestuft. Bis zum 18. Juli waren keine bestätigten Ausnutzungen gemeldet worden, und das Problem war zu diesem Zeitpunkt nicht im Katalog der bekannten ausgenutzten Schwachstellen von CISA aufgeführt.

Empfohlene Maßnahmen

Administratoren sollten die installierte Version überprüfen und so bald wie möglich auf eine korrigierte Version aktualisieren, anstatt sich auf automatische Updates zu verlassen. Für den Codeausführungspfad ist Berichten zufolge das Fehlen eines persistenten Objekt-Caches erforderlich; Redis oder Memcached sollten jedoch nicht als Ersatz für das Einspielen von Patches betrachtet werden.

Bis die Updates installiert sind, können Organisationen erwägen, den anonymen Zugriff auf /wp-json/batch/v1 sowie auf den entsprechenden Pfad rest_route=/batch/v1 über eine Web Application Firewall zu blockieren. Die Deaktivierung des nicht authentifizierten Zugriffs auf die REST-API oder der Einsatz eines temporären Filters, der anonyme Stapelanfragen ablehnt, sind weitere Optionen. Diese Maßnahmen können jedoch legitime Integrationen beeinträchtigen und beseitigen die zugrunde liegende SQL-Injection nicht.