Elementor CSRF-Schwachstelle ermöglicht Angreifern das Anlegen von Admin-Konten

Elementor, der am weitesten verbreitete Page-Builder für WordPress mit mehr als zehn Millionen aktiven Installationen, hat eine Cross-Site-Request-Forgery-(CSRF)-Schwachstelle gepatcht, die es einem einzigen Link ermöglichte, jede REST-API-Aktion auszuführen, zu der der angemeldete Benutzer berechtigt ist. Entdeckt von dem Forscher Saggre und an Patchstack gemeldet, betrifft die Schwachstelle nur die Versionen 4.3.0 und 4.3.1 des Elementor Website Builder Plugins. In einer Standard-WordPress-Installation kann ein Administrator, der im angemeldeten Zustand auf einen präparierten Link klickt, unwissentlich ein zweites Administratorkonto für einen Angreifer erstellen – ohne JavaScript, ohne Formular und ohne eine Seite, die der Angreifer kontrolliert. Patchstack hat Mitigationsregeln zum Schutz vor Ausnutzung herausgegeben.

In den betroffenen Versionen deaktiviert Elementor die einzige CSRF-Schutzmaßnahme des WordPress-Kerns für cookie-authentifizierte REST-API-Anfragen, wann immer die wörtliche Zeichenkette elementor/v1/events/ irgendwo in der Anfrage-URI erscheint. Da die Anfrage-URI die Query-Zeichenkette enthält und die Query-Zeichenkette von demjenigen geschrieben wird, der den Link zusammenstellt, kann sich jede REST-Anfrage selbst von diesem Schutz abmelden, indem sie einen harmlos aussehenden Parameter anhängt. Der anfällige Code befindet sich im Editor Events-Modul, das die Editor-Telemetrie von Elementor weiterleitet. Das Modul ist im Experiments-Bildschirm der Website ausgeblendet, aber standardmäßig für jede Website aktiviert, deren erste Elementor-Installation Version 3.32.0 oder höher war. Daher ist eine Standardinstallation von 4.3.0 oder 4.3.1 betroffen. Der Konstruktor des Moduls registriert den Filter bedingungslos, was bedeutet, dass keine Telemetrie-Einstellung auf der Website dies verhindert. Versionen vor 4.3.0 enthalten diesen Proxy nicht und sind nicht anfällig.

Das Kernproblem ist das Timing. Der Events-Proxy registriert zwei REST-Routen und möchte seine eigenen Anfragen von der REST-Nonce-Prüfung ausnehmen. Um dies zu erreichen, hängt er rest_authentication_errors mit Priorität 0 ein, bevor WordPress eine Route abgeglichen hat. Der Callback prüft, ob die rohe Anfrage-URI die Zeichenkette elementor/v1/events/ enthält, und verwendet eine nicht verankerte Teilstringsuche. Da die Query-Zeichenkette vollständig vom Angreifer kontrolliert wird, kann ein Parametername und -wert so gestaltet werden, dass diese Prüfung erfüllt wird, während die Anfrage an einen völlig anderen Endpunkt gesendet wird. Sobald die Prüfung bestanden ist, gibt der Callback true zurück, was allen späteren Authentifizierungshandlern, einschließlich der Nonce-Überprüfung des WordPress-Kerns, mitteilt, dass die Authentifizierung bereits erfolgreich war. Der permission_callback der Route wird weiterhin ausgeführt, sodass die Berechtigungen des Opfers bestimmen, was der Angreifer tun kann. Die Autorisierung bleibt intakt; nur der Nachweis der Absicht fehlt.

Der Angriff passt vollständig in eine URL, da der WordPress-Kern einen _method-Query-Parameter akzeptiert, der das HTTP-Verb überschreibt. Eine normale GET-Navigation kann daher Schreibvorgänge durchführen. Die Forscher von Patchstack demonstrierten eine URL, die einen neuen Benutzer mit der Administratorrolle erstellt: Die Anfrage zielt auf /wp-json/wp/v2/users und fügt _method=POST sowie Parameter für Benutzername, E-Mail, Passwort und Rollen hinzu. Der letzte Parameter, x=elementor/v1/events/, ist der einzige, der zählt. Ohne ihn gibt WordPress HTTP 401 mit rest_cannot_create_user zurück. Mit ihm gibt der Server HTTP 201 und ein Benutzerobjekt zurück, dessen roles-Array ["administrator"] ist. Der Forscher bestätigte auch, dass ein Marker, der ein Zeichen kürzer als der echte Namespace ist, elementor/v1/event/, abgelehnt wird, was jede andere Erklärung für den Unterschied ausschließt. Da ein einzelnes Anchor-Tag ausreicht, kann die Nutzlast überallhin geliefert werden, wo ein Link hin kann: eine E-Mail, eine Chat-Nachricht, ein Forumsbeitrag oder ein Kommentar auf einer unrelated Website. Das Opfer sieht einen normalen Link und eine JSON-Antwort.

Die Auswirkungen sind breiter als die eigenen Endpunkte von Elementor. Die Umgehung läuft, bevor WordPress die Anfrage weiterleitet, und gilt daher für die gesamte REST-API-Oberfläche der Website: WordPress-Kernrouten und die Routen jedes anderen installierten Plugins. Das Erstellen eines Administrators über /wp/v2/users ist die klarste Demonstration, aber der Bericht von Patchstack zeigte auch, dass GET /wp-json/wp/v2/settings von HTTP 401 zu HTTP 200 mit den Website-Einstellungen im Antworttext wird. Jede Aktion, die das Konto des Opfers über REST ausführen kann, liegt im Geltungsbereich, einschließlich Endpunkten von Plugins, die nichts falsch gemacht haben.

Elementor hat die Schwachstelle in Version 4.3.2 behoben. Die Ersatzprüfung liest $wp->query_vars['rest_route'], was die Route ist, die WordPress nach dem Rewriting tatsächlich aufgelöst hat, wobei die Query-Zeichenkette bereits getrennt ist. Kein vom Angreifer zusammengestellter Text bleibt in dem getesteten Wert. Der Vergleich änderte sich auch von einer lockeren Teilstringsuche zu einer verankerten Prüfung, dass die Route mit /elementor/v1/events/ beginnt. Ein is_string-Wächter schließt die Tür für die Übermittlung von rest_route als Array. Sowohl die Eingabequelle als auch der verankerte Vergleich sind wichtig; die Behebung nur eines Aspekts hätte eine kleinere Version desselben Fehlers hinterlassen.

Die Grundursache ist eine Diskrepanz zwischen einer Frage und den verfügbaren Daten, um sie zu beantworten. Der Code wollte wissen, ob eine Anfrage für seine eigene Route bestimmt war, fragte jedoch an einem Punkt im Anfrage-Lebenszyklus, an dem WordPress dies noch nicht entschieden hatte, und begnügte sich mit einer Teilstringsuche über eine Zeichenkette, die der Client kontrolliert. Zwei Lehren lassen sich über Elementor hinaus verallgemeinern. Erstens ist $_SERVER['REQUEST_URI'] vom Angreifer kontrollierte Eingabe, keine Routing-Metadaten; jede Sicherheitsentscheidung, die darauf basiert, erfordert die Entfernung der Query-Zeichenkette und einen verankerten Vergleich. Zweitens ist rest_authentication_errors ein gemeinsamer Kanal, und die Rückgabe eines truthy-Werts darauf ist kein lokales Opt-out; es bestätigt jedem nachgelagerten Handler, einschließlich der Nonce-Überprüfung des WordPress-Kerns, den Erfolg. Ein Filter, der nur 'keine Meinung' sagen muss, sollte das ursprüngliche Ergebnis unverändert zurückgeben. Patchstack erhielt den Bericht am 22.09.2026, Elementor veröffentlichte Version 4.3.2 am 24.09.2026 und die öffentliche Mitteilung wurde am 25.09.2026 veröffentlicht. Die Empfehlung lautet, Elementor sofort auf Version 4.3.2 oder höher zu aktualisieren.

Für Website-Besitzer ist diese Schwachstelle eine Erinnerung daran, dass weit verbreitete Plugins attraktive Ziele sind und dass ein einziges veraltetes Plugin eine gesamte Website gefährden kann. Managed WordPress Hosting-Dienste wie AEU Hosting, die sicheres End-to-End Managed WordPress Hosting anbieten, können ein hilfreicher Teil einer Sicherheitsroutine sein, die zeitnahe Plugin-Updates und Überwachung umfasst.