CSRF-Sicherheitslücke in Elementor: Ein Klick eines Administrators kann Angreifern volle Kontrolle über WordPress verschaffen
CSRF-Lücke in Elementor 4.3.0 und 4.3.1: Ein Admin-Klick genügt, um ein Admin-Konto anzulegen. Update auf 4.3.2 sofort installieren.
Illustration mit KI erzeugt
Eine Cross-Site-Request-Forgery-Sicherheitslücke im Elementor Website Builder ermöglicht es nicht angemeldeten Angreifern, angemeldete WordPress-Administratoren zu privilegierten Aktionen über die REST-API zu verleiten. Bei Standardinstallationen können Angreifer die Schwachstelle ausnutzen, um ein neues Administratorkonto unter ihrer Kontrolle anzulegen.
Betroffen sind die Elementor-Versionen 4.3.0 und 4.3.1. Elementor hat die Sicherheitslücke mit Version 4.3.2 behoben. Betreiber sollten das Update umgehend installieren.
Patchstack veröffentlichte am 25. September 2026 Einzelheiten zu der Schwachstelle. Demnach wurde Elementor am 22. September informiert, nachdem der Sicherheitsforscher „Saggre“ die Schwachstelle gemeldet hatte. Die gepatchte Version erschien zwei Tage nach der Benachrichtigung.
Eine Routenprüfung setzt einen wichtigen WordPress-Schutz außer Kraft
Die Schwachstelle steckt im Modul Editor Events von Elementor. Es prüft die rohe Request-URI auf folgenden Pfad:
elementor/v1/events/
Enthält die Zeichenfolge diese Angabe, umgeht das Modul die Validierung von WordPress-REST-Nonces. REST-Nonces helfen WordPress dabei, zu bestätigen, dass eine authentifizierte Anfrage bewusst vom angemeldeten Nutzer und nicht durch eine externe Partei ausgelöst wurde.
Die Schwachstelle liegt darin, wie Elementor die Route ermittelt. Statt sicher festzustellen, welcher REST-Endpunkt aufgerufen wird, durchsucht das Modul die gesamte, vom Angreifer beeinflussbare URI nach der erwarteten Zeichenfolge.
Auch Query-Parameter sind Teil dieser rohen URI. Ein Angreifer kann daher eine Anfrage an einen anderen REST-API-Endpunkt senden und elementor/v1/events/ in den Query-String einfügen. Elementor erkennt darin den vertrauenswürdig wirkenden Pfad und unterdrückt die Nonce-Prüfung, obwohl die Anfrage tatsächlich an einen anderen Endpunkt gerichtet ist.
Der Browser des Opfers sendet weiterhin dessen authentifizierte WordPress-Sitzung mit. Die REST-Anfrage wird deshalb mit den bestehenden Berechtigungen des Opfers ausgeführt.
Dabei handelt es sich nicht um eine Authentifizierungsumgehung, bei der sich ein Angreifer direkt als Administrator anmeldet. Vielmehr bringt ein CSRF-Angriff den Browser eines bereits angemeldeten Administrators dazu, im Auftrag des Angreifers zu handeln. Das praktische Ergebnis kann dennoch einer Kontoübernahme gleichkommen.
Ein einziger präparierter Link kann ein dauerhaftes Administratorkonto anlegen
Für einen erfolgreichen Angriff muss ein WordPress-Administrator angemeldet sein und anschließend eine vom Angreifer präparierte URL öffnen. Der Link kann per E-Mail oder Chat verschickt oder als Kommentar auf der angegriffenen Website platziert werden.
Für die Zustellung des Angriffs sind ungewöhnlich wenige Voraussetzungen nötig. Er benötigt weder:
- die Ausführung von JavaScript;
- eine vom Angreifer kontrollierte Website;
- ein verborgenes oder abgesendetes HTML-Formular;
- eine vorherige Anmeldung bei der angegriffenen WordPress-Website.
Ein einziger Klick reicht aus, sofern der Administrator eine aktive Sitzung hat.
Bei einer Standardinstallation von WordPress kann die gefälschte REST-Anfrage ein weiteres Administratorkonto anlegen. Damit erhält der Angreifer dauerhaften Zugriff, der nicht von der Sitzung des Opfers abhängt. Selbst wenn der ursprüngliche Schadlink nie wieder geöffnet wird, bleibt das neu angelegte Konto bestehen, bis die Verantwortlichen es entdecken und entfernen.
Ein vom Angreifer kontrolliertes Administratorkonto kann Zugriff auf Website-Inhalte, Konfigurationen und Nutzerdaten ermöglichen. Je nach Website-Konfiguration und zusätzlichen Sicherheitsmaßnahmen kann es auch den Zugriff auf die Verwaltung von Plugins und Themes erlauben. Welche konkreten Aktionen Angreifer nach einer Kompromittierung in der Praxis durchgeführt haben, ist nicht bekannt.
Für diese Schwachstelle wurden weder eine öffentliche Schweregradbewertung noch eine CVE-Kennung vergeben. Auch Informationen zu einer aktiven Ausnutzung in freier Wildbahn wurden nicht veröffentlicht. Es gibt keinen bekannten Eintrag im Katalog der CISA zu aktiv ausgenutzten Sicherheitslücken und keine genannte Frist zur Behebung für US-Bundesbehörden.
Bis zu zwei Millionen Websites könnten betroffene Versionen einsetzen
Der Elementor Website Builder ist auf etwa 10 Millionen Websites aktiv. Laut den Nutzungsstatistiken von WordPress.org könnten bis zu 2 Millionen Websites Versionen verwenden, die von der Schwachstelle betroffen sind.
Der betroffene Versionsbereich ist eng begrenzt, aber relevant:
| Elementor-Version | Status |
|---|---|
| 4.3.0 | Verwundbar |
| 4.3.1 | Verwundbar |
| 4.3.2 | Behoben |
| Älter als 4.3.0 | Von dieser speziellen Sicherheitslücke im Modul Editor Events nicht betroffen |
Versionen vor 4.3.0 enthalten den verwundbaren Editor-Events-Proxy nicht. Auf eine ältere Version auszuweichen, ist jedoch keine sichere Lösung. Diese Versionen weisen andere Sicherheitslücken auf, darunter auch bereits aktiv ausgenutzte Schwachstellen.
Die richtige Maßnahme ist daher ein Upgrade auf 4.3.2, kein Downgrade.
Die große Installationsbasis von Elementor erhöht die Wahrscheinlichkeit für opportunistische Scans und massenhaft verbreitete Köder. Angreifer müssen nicht unbedingt wissen, ob ein Administrator gerade angemeldet ist. Sie können Links breit streuen und darauf warten, dass einer davon einen Nutzer mit einer aktiven privilegierten Sitzung erreicht.
Version 4.3.2 schließt die Umgehung über den Query-String
Elementor 4.3.2 verhindert, dass Angreifer den Query-String nutzen, um eine andere REST-Anfrage so erscheinen zu lassen, als richte sie sich an die Editor-Events-Route. Administratoren sollten die installierte Version überprüfen und sich nicht allein auf eine vermeintlich aktivierte automatische Update-Funktion verlassen.
Die wichtigsten Maßnahmen zur Behebung sind:
- Elementor Website Builder auf Version 4.3.2 aktualisieren.
- Sicherstellen, dass Version 4.3.0 und 4.3.1 nirgendwo mehr aktiv sind, auch nicht auf Staging- oder weiteren WordPress-Installationen.
- Administratorkonten überprüfen und nach Nutzern suchen, die nicht bewusst angelegt wurden.
- Kürzliche Kontoänderungen und REST-Anfragen untersuchen, sofern geeignete Protokolle verfügbar sind.
- Aktive Administratorsitzungen beenden und Zugangsdaten zurücksetzen, falls unbefugte privilegierte Aktivitäten festgestellt werden.
Das einzige konkrete Anfrageartefakt, das für diese Schwachstelle genannt wurde, ist die Zeichenfolge:
elementor/v1/events/
Verantwortliche können in Webserver-, Reverse-Proxy-, Web-Application-Firewall- und Anwendungsprotokollen nach dieser Zeichenfolge suchen, wenn sie unerwartet in Query-Strings oder bei Anfragen an andere REST-Endpunkte auftaucht. Ihr bloßes Auftreten ist kein Beweis für eine Kompromittierung, da auch legitimer Elementor-Datenverkehr dieselbe Route verwenden kann. Entscheidend ist der Kontext: Der tatsächliche Endpunkt, die Position im Query-String, der Antwortstatus und die Aktivitäten des zugehörigen Kontos sollten gemeinsam geprüft werden.
Websites sollten außerdem nach kürzlich hinzugefügten Administratorkonten suchen, insbesondere nach Konten mit unbekannten Namen oder E-Mail-Adressen oder einem auffälligen Erstellungszeitpunkt. Die verfügbaren Informationen enthalten keine konkreten schädlichen Benutzernamen, IP-Adressen oder sonstigen kampagnenspezifischen Indikatoren.
Das größere Risiko ist eine über Administratoren vermittelte Kompromittierung
Diese Schwachstelle gehört zu einer Angriffsklasse, bei der der Browser eines vertrauenswürdigen Administrators als Ausführungsmechanismus dient. Der Angreifer knackt weder das Passwort des Administrators noch stiehlt er direkt dessen Sitzungscookie. Stattdessen ermöglicht eine unzureichende Anfragevalidierung, dass ein präparierter Link die bestehende Sitzung des Administrators für eine privilegierte Aktion nutzt.
Bei diesem Angriffsmuster sind herkömmliche Schutzmaßnahmen gegen Phishing relevant. Doch Vorsicht bei Links ist kein Ersatz für das Einspielen von Sicherheitsupdates. Links lassen sich tarnen, kürzen oder an Stellen einbetten, an denen Administratoren regelmäßig klicken. Da weder JavaScript noch eine eigens eingerichtete bösartige Website erforderlich ist, benötigt ein Angreifer zudem weniger Infrastruktur.
Vor Kurzem war WordPress bereits von einer weiteren Sicherheitslücke betroffen, bei der ein Besuch missbraucht werden konnte, um die Installation eines Themes zu erzwingen und so möglicherweise eine größere Angriffskette in Gang zu setzen. Das Problem wurde als Click2Shell beschrieben: ein Angriff, bei dem der Besuch eines Administrators die erzwungene Installation eines Themes auslöst.
Für Elementor-Nutzer ist die Abhilfe eindeutig: Version 4.3.2 installieren. Auch ohne CVE-Kennung oder Schweregradbewertung ist die Sicherheitslücke dringend zu behandeln, da sie standardmäßig die Erstellung eines vom Angreifer kontrollierten Administratorkontos ermöglicht.
Quellen
Dieser Artikel ist eine eigenständige Aufbereitung auf Basis der folgenden Quellen.
