CVE-2026-62062: Elementor CSRF-Lücke erzeugt Admin-Konten per Link, Update auf 4.3.2 jetzt einspielen

Veröffentlicht: 01.10.2026 · Letzte Aktualisierung: 01.10.2026

Was ist passiert

Im kostenlosen WordPress-Plugin Elementor Website Builder steckt eine Cross-Site-Request-Forgery-Lücke, über die ein Angreifer ohne eigenes Konto ein neues Administratorkonto auf einer fremden Seite anlegen kann. Betroffen sind ausschließlich die Versionen 4.3.0 und 4.3.1, geschlossen wurde die Lücke in Version 4.3.2, aktuell ist 4.3.3 vom 30.09.2026.

Veröffentlicht wurde die Schwachstelle am 25.09.2026 durch den Sicherheitsdienstleister Patchstack, der auch auf die enorme Reichweite hinweist: Über 2 Millionen Websites laufen auf einer der beiden anfälligen Versionen. Entdeckt und gemeldet hat die Lücke der Sicherheitsforscher Saggre. Sie trägt die Kennung CVE-2026-62062 und einen CVSS-Basiswert von 8.8, also die Einstufung hoch. Die Schwachstellenklasse ist CWE-352, Cross-Site Request Forgery.

Das Tückische an dieser Lücke ist nicht ihre Komplexität, sondern ihre Einfachheit. Der gesamte Angriff passt in einen einzigen Link. Kein Formular, kein JavaScript, keine vom Angreifer kontrollierte Seite. Es genügt, dass eine eingeloggte Person mit ausreichenden Rechten einen präparierten Link öffnet, etwa aus einer E-Mail, einer Chat-Nachricht oder einem Forenbeitrag.

Technische Details: ein Teilstring hebt die Nonce-Prüfung auf

Cross-Site Request Forgery, kurz CSRF, bezeichnet einen Angriff, bei dem der Browser eines eingeloggten Nutzers ohne dessen Wissen eine Aktion auf einer Website ausführt, weil die Website nicht prüft, ob die Anfrage wirklich gewollt war. Genau diese Prüfung fällt in Elementor 4.3.0 und 4.3.1 aus, und zwar nicht nur für Elementor selbst, sondern für die gesamte REST-Schnittstelle der Seite.

Wie Elementors Editor-Events-Proxy die REST-Authentifizierung umgeht

Um die Ursache zu verstehen, muss man wissen, wie WordPress seine REST-Schnittstelle gegen gefälschte Anfragen schützt. Für Anfragen, die per Session-Cookie authentifiziert werden, gibt es genau eine CSRF-Schutzmaßnahme: die Prüfung einer sogenannten Nonce, eines kurzlebigen Einmal-Tokens, das belegt, dass die Anfrage tatsächlich aus der WordPress-Oberfläche stammt und nicht von einer fremden Seite untergeschoben wurde. Diese Prüfung läuft über den Filter rest_authentication_errors.

Elementor betreibt in den betroffenen Versionen ein Modul namens Editor Events, das Telemetriedaten des Editors weiterreicht. Dieses Modul meldet eigene REST-Routen an und möchte seine eigenen Anfragen von der Nonce-Prüfung ausnehmen. Dafür hängt es sich mit Priorität 0, also ganz vorne, in genau diesen Filter ein. Die Logik dahinter prüft, ob es sich um eine eigene Anfrage handelt, und zwar so: Sie liest $_SERVER['REQUEST_URI'] aus und sucht darin per ungeankerter Teilstringsuche nach der Zeichenkette elementor/v1/events/. Findet sie diese irgendwo im String, gibt der Filter true zurück.

Dabei treffen zwei Fehler aufeinander. Erstens läuft diese Prüfung, bevor WordPress die angefragte Route überhaupt aufgelöst hat. Zu diesem Zeitpunkt existiert noch keine saubere Route zum Vergleichen, es gibt nur den rohen URI-String. Und $_SERVER['REQUEST_URI'] enthält nicht nur den Pfad, sondern auch den Query-String, also den Teil hinter dem Fragezeichen. Dieser Query-String wird vollständig von demjenigen geschrieben, der den Link zusammenbaut. Der Angreifer kontrolliert also exakt den Text, in dem gesucht wird.

Zweitens ist die Rückgabe von true schlimmer als nur das Überspringen einer einzelnen Prüfung. Der Filter rest_authentication_errors ist ein gemeinsam genutzter Kanal, dessen Wert durch alle angehängten Prüfungen weitergereicht wird. Jede gut gebaute Prüfung beginnt mit der Frage, ob eine frühere Prüfung bereits entschieden hat. Gibt Elementor mit Priorität 0 ein true zurück, bedeutet das für alle nachgelagerten Prüfungen: Die Authentifizierung war bereits erfolgreich. Die Nonce-Prüfung von WordPress wird damit nie erreicht, und jedes Sicherheits-Plugin, das denselben Filter zur Härtung nutzt, wird gleich mit übergangen. Die CSRF-Prüfung entfällt dadurch für jede beliebige REST-Route, nicht nur für die Elementor-eigene.

Der Angriff in einer Zeile

In der Praxis heißt das: Der Angreifer hängt an eine ganz andere REST-Anfrage einfach einen harmlos aussehenden Parameter an, der die magische Zeichenkette enthält. Die eigentliche Anfrage zielt zum Beispiel auf den Endpunkt zum Anlegen neuer Benutzer, der Zusatz-Parameter mogelt den Teilstring in den URI. Im Klartext sieht die Anfrage so aus:

POST /?rest_route=/wp/v2/users&x=elementor/v1/events/

Der Parameter x spielt inhaltlich keine Rolle, sein Name ist beliebig, seine Position ebenso. Entscheidend ist allein, dass die Zeichenkette elementor/v1/events/ irgendwo im URI auftaucht. Damit schaltet sich die Anfrage selbst von der CSRF-Prüfung frei. Weil WordPress zusätzlich einen Parameter akzeptiert, mit dem sich die HTTP-Methode überschreiben lässt, genügt sogar ein einfacher Linkaufruf per Browser-Navigation, um eine schreibende Aktion auszulösen. Der gesamte Angriff passt damit in eine URL.

Es ist kein JavaScript nötig, kein Formular, kein Nutzerklick über das Öffnen des Links hinaus. Der Browser des eingeloggten Administrators liefert das Session-Cookie automatisch mit, und WordPress behandelt die Anfrage so, als käme sie aus der eigenen Oberfläche. Übrig bleibt nur die Rechteprüfung des Endpunkts, die fragt, was der aktuelle Nutzer darf. Da der Administrator eingeloggt ist, fällt diese Antwort großzügig aus. Was fehlt, ist allein der Nachweis, dass die Aktion gewollt war, und genau diesen Nachweis hebelt die Lücke aus. Das Ergebnis ist ein neues Benutzerkonto mit Administratorrechten, das der Angreifer frei gewählt hat.

Was der Patch in 4.3.2 ändert

Der Fix in Version 4.3.2 ist kurz, aber an beiden entscheidenden Stellen korrekt. Statt den rohen, vom Angreifer beeinflussbaren URI auszuwerten, liest die Prüfung nun die tatsächlich aufgelöste Route aus $wp->query_vars['rest_route']. Das ist der Wert, den WordPress nach dem Routing ermittelt hat, mit bereits abgetrenntem Query-String. Es steckt also kein vom Client geschriebener Text mehr in dem, was geprüft wird.

Der zweite Teil betrifft den Vergleich selbst. Aus der ungeankerten Teilstringsuche wurde ein geankerter Vergleich mit strpos(...) === 0. Der Namensraum muss jetzt am Anfang der Route stehen, nicht irgendwo in ihr. Ohne diese zweite Änderung wäre eine kleinere Variante desselben Fehlers geblieben. Zusätzlich stellt der Patch sicher, dass die Route tatsächlich eine Zeichenkette ist, und schließt damit auch den Weg, bei dem der Routen-Parameter als Array untergeschoben wird.

Wer ist betroffen

Betroffen sind ausschließlich Websites, auf denen das kostenlose Plugin Elementor Website Builder in Version 4.3.0 oder 4.3.1 läuft. Versionen vor 4.3.0 enthalten das anfällige Editor-Events-Modul noch nicht und sind damit nicht betroffen. Das anfällige Modul ist in den betroffenen Versionen im Standard aktiv, es wird über eine versteckte Funktion gesteuert, die für neue Installationen ab einer bestimmten Version voreingestellt eingeschaltet ist und auf der Experimente-Seite nicht einmal sichtbar auftaucht. Eine Standardinstallation von 4.3.0 oder 4.3.1 ist also betroffen, ohne dass irgendeine Einstellung verändert wurde.

Besonders exponiert sind drei Konstellationen. Multisite-Installationen, weil hier mehrere Seiten unter einer Verwaltung hängen und ein einziges erfolgreiches Admin-Konto weitreichenden Zugriff eröffnet. Agentur-Portfolios, weil dort viele Installationen parallel betreut werden und die Wahrscheinlichkeit steigt, dass irgendwo eine anfällige Version läuft. Und Seiten mit vielen Redaktionskonten, denn der entscheidende Faktor ist die Teamgröße: Jeder eingeloggte Nutzer mit dem Recht, Benutzer anzulegen, genügt als Opfer, und je mehr Menschen Zugang haben, desto höher die Chance, dass jemand einen präparierten Link öffnet.

Ein verbreitetes Missverständnis betrifft Elementor Pro. Die kostenpflichtige Erweiterung ist für diese Lücke nur in Kombination mit dem betroffenen kostenlosen Core-Plugin relevant, denn die Schwachstelle sitzt im kostenlosen Core, nicht in Pro. Wer Pro einsetzt, hat zwangsläufig auch das kostenlose Elementor installiert und muss dessen Version prüfen. Die reine Pro-Versionsnummer sagt über diese Lücke nichts aus. Unabhängig davon war Elementor Pro erst im August 2026 selbst Ziel aktiver Angriffe über eine Upload-Lücke, unsere Analyse dazu finden Sie im Beitrag zu CVE-2026-32475 in Elementor Pro.

Timeline

• 22.09.2026: Patchstack erhält die Meldung des Forschers Saggre zu den Versionen 4.3.0 und 4.3.1.
• 24.09.2026: Elementor veröffentlicht Version 4.3.2, die statt des rohen Request-URI die aufgelöste REST-Route auswertet.
• 25.09.2026: Patchstack veröffentlicht die Analyse samt Hinweis auf über 2 Millionen betroffene Seiten, kurz darauf berichtet die internationale Fachpresse.
• Ende September 2026: Öffentliches Proof-of-Concept-Material inklusive Testumgebung taucht auf, die Lücke wird in Exploit-Suchmaschinen gelistet.
• 30.09.2026: Elementor veröffentlicht Version 4.3.3 als aktuellen Stand.

Sofortmaßnahmen

1. Version prüfen und sofort aktualisieren. Öffnen Sie im WordPress-Backend unter Plugins die Liste der installierten Erweiterungen und kontrollieren Sie die Versionsnummer von Elementor. Steht dort 4.3.0 oder 4.3.1, besteht akuter Handlungsbedarf: Spielen Sie mindestens Version 4.3.2 ein, besser direkt die aktuelle 4.3.3. Jede Version vor 4.3.0 ist von dieser Lücke nicht betroffen, sollte aber aus anderen Gründen ohnehin aktuell gehalten werden.
2. Alternativ per WP-CLI prüfen und aktualisieren. Auf dem Server geht beides in zwei Befehlen:

   wp plugin get elementor --field=version
   wp plugin update elementor

   Prüfen Sie nach dem Update die Versionsnummer erneut und stellen Sie sicher, dass die neue Version auch tatsächlich aktiv ist.

3. Benutzerliste auf unbekannte Administratoren prüfen. Gehen Sie unter Benutzer alle Konten mit der Rolle Administrator durch, inklusive Registrierungsdatum: Ein Konto, das in den letzten Tagen angelegt wurde und das niemand im Team zuordnen kann, ist das deutlichste Angriffssignal. Per WP-CLI:

   wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

4. Bei einem Fund: Konto entfernen und Zugänge härten. Löschen Sie das unbekannte Administratorkonto und übertragen Sie dessen Inhalte bei Bedarf auf ein vertrauenswürdiges Konto. Setzen Sie anschließend die Passwörter aller legitimen Administratoren zurück, erneuern Sie die Security-Salts in der wp-config.php und beenden Sie damit alle offenen Sitzungen. So wird auch ein bereits mitgenutztes Session-Cookie wertlos.
5. Application Passwords und API-Schlüssel prüfen und rotieren. Kontrollieren Sie in den Benutzerprofilen, ob unbekannte Anwendungspasswörter angelegt wurden, und rotieren Sie API-Schlüssel von Diensten, die mit Admin-Rechten an der Seite hängen. Ein Angreifer, der kurz Administratorrechte hatte, kann sich darüber einen dauerhaften Zugang eingerichtet haben, der das Löschen seines Kontos überdauert.
6. Serverseitige Logs durchsuchen. Suchen Sie in den Zugriffsprotokollen nach Anfragen an den Benutzer-Endpunkt in Kombination mit der Elementor-Zeichenkette, zum Beispiel so:

   grep "rest_route=/wp/v2/users" access.log | grep "elementor"

   Beachten Sie, dass die Zeichenkette im Log auch URL-codiert auftauchen kann (etwa als elementor%2Fv1%2Fevents), prüfen Sie also beide Schreibweisen. Das genaue Log-Format und den Pfad der Logdatei entnehmen Sie Ihrer Hosting-Umgebung.

7. Dateisystem auf nachgelagerte Hintertüren prüfen. Ein Angreifer mit Admin-Konto kann Plugins installieren oder Dateien verändern. Prüfen Sie das Dateisystem auf unbekannte Plugin-Ordner und kürzlich geänderte PHP-Dateien und vergleichen Sie Core- und Plugin-Dateien gegen die Originale, per WP-CLI etwa mit wp core verify-checksums und wp plugin verify-checksums --all. Im Zweifel gehört diese Forensik in erfahrene Hände.
8. Automatische Updates für Sicherheitsreleases absichern. Wo es der Betrieb erlaubt, sollten sicherheitsrelevante Plugin-Updates zeitnah und zuverlässig eingespielt werden. In betreuten Umgebungen übernimmt das ein definierter Update-Prozess mit Prüfung und Protokoll.

Einschätzung von CMS ADMINS

Diese Lücke ist ein Lehrstück darüber, wie ein kleiner Denkfehler eine riesige Angriffsfläche öffnet. Der eigentliche Fehler ist nicht exotisch, sondern alltäglich: Eine Prüfung stellt die richtige Frage, nämlich ob eine Anfrage für die eigene Route bestimmt ist, aber sie stellt sie zum falschen Zeitpunkt und auf Basis von Daten, die der Angreifer kontrolliert. Dass daraus eine CSRF-Lücke mit Wirkung auf die gesamte REST-Schnittstelle wird und nicht nur auf den Elementor-eigenen Endpunkt, hebt den Fall über eine gewöhnliche Plugin-Schwachstelle hinaus.

Der CVSS-Wert von 8.8 trifft die Gefahr aus unserer Sicht gut, unterschätzt aber die praktische Verführungskraft des Angriffs. Ein funktionierender Exploit ist eine URL, nicht mehr. Solche Angriffe lassen sich breit streuen, in Mails, in Kommentaren, in Nachrichten, und sie brauchen nur einen einzigen unaufmerksamen Klick einer eingeloggten Person mit Benutzerrechten. In einer kleinen Ein-Personen-Site ist dieses Risiko überschaubar, in einem Team mit mehreren Redakteuren und Administratoren wird es schnell real.

Die gute Nachricht lautet: Der Patch ist eindeutig, er behebt die Ursache sauber, und es gibt bislang keine Meldung über eine bestätigte Massenausnutzung, die Lücke steht nicht im CISA-Katalog der aktiv ausgenutzten Schwachstellen, und der EPSS-Wert liegt mit 0,13 Prozent derzeit niedrig. Wer jetzt zügig auf 4.3.2 oder 4.3.3 aktualisiert und die Benutzerliste kontrolliert, ist auf der sicheren Seite. Das Zeitfenster zwischen öffentlicher Analyse mit Proof of Concept und automatisierten Angriffswellen ist bei derart einfachen Lücken erfahrungsgemäß kurz. Abwarten ist hier keine Strategie.

Für Agenturen mit vielen Kundenprojekten ist der entscheidende Punkt nicht das einzelne Update, sondern der Überblick. Wer nicht binnen Minuten beantworten kann, auf welchen der eigenen Seiten Elementor in welcher Version läuft, hat kein Update-Problem, sondern ein Inventarproblem. Genau dafür arbeiten wir im White-Label-Modell für Digital- und Marketingagenturen: zentrale Übersicht über alle Installationen, definierte Update-Fenster, dokumentierte Patches. Ergänzend filtert auf unseren Systemen eine Web Application Firewall bekannte Angriffsmuster bereits vor dem PHP-Prozess, sodass eine präparierte Anfrage im Idealfall gar nicht erst durchkommt. Wie wir Betrieb und Absicherung zusammen denken, beschreiben unsere Seiten zur WordPress-Wartung, zur WordPress-Sicherheit und zum nginx-Hosting in Deutschland.

Bleibt der rechtliche Teil, der gern vergessen wird. Legt ein Angreifer über diese Lücke ein Administratorkonto an und greift anschließend auf personenbezogene Daten zu, etwa auf Benutzerprofile, Kommentardaten mit E-Mail-Adresse oder Kundeninformationen, liegt eine Verletzung des Schutzes personenbezogener Daten nach Artikel 33 DSGVO vor. Diese ist der zuständigen Aufsichtsbehörde grundsätzlich binnen 72 Stunden zu melden, sofern nicht voraussichtlich kein Risiko besteht. Dafür brauchen Sie belastbare Logs und eine nachvollziehbare Analyse, und beides entsteht nicht rückwirkend. Wo Ihre Daten liegen und wer technisch Zugriff hat, ist damit keine Glaubensfrage, sondern eine Betriebsvoraussetzung. Warum wir Serverstandort und Betreiberstruktur in Deutschland für mehr als ein Verkaufsargument halten, erläutern wir unter digitale Souveränität.

Häufige Fragen

Welche Elementor-Version ist sicher?

Sicher ist Version 4.3.2 und jede spätere Version, aktuell ist 4.3.3 vom 30.09.2026. Betroffen sind ausschließlich 4.3.0 und 4.3.1. Alle Versionen vor 4.3.0 enthalten das anfällige Modul nicht und sind von dieser Lücke nicht betroffen, sollten aber aus allgemeinen Sicherheitsgründen trotzdem aktuell gehalten werden.

Bin ich auch betroffen, wenn ich Elementor Pro nutze?

Die Lücke sitzt im kostenlosen Core-Plugin Elementor Website Builder, nicht in Elementor Pro. Da Pro aber nur zusammen mit dem kostenlosen Core funktioniert, ist entscheidend, welche Version dieses Core-Plugins installiert ist. Prüfen Sie in der Plugin-Liste die Versionsnummer von Elementor, nicht die von Elementor Pro.

Muss ich etwas tun, wenn ich nur wenige Nutzerkonten habe?

Ja. Das Risiko sinkt mit der Teamgröße, aber es verschwindet nicht. Solange eine Person mit dem Recht, Benutzer anzulegen, eingeloggt einen präparierten Link öffnen kann, ist die Seite angreifbar. Das Update ist in jedem Fall die richtige und schnellste Maßnahme.

Wie erkenne ich, ob meine Seite bereits angegriffen wurde?

Der deutlichste Hinweis ist ein unbekanntes Administratorkonto in der Benutzerliste, oft mit fremdem Benutzernamen oder fremder E-Mail-Adresse. Prüfen Sie außerdem die Zugriffsprotokolle auf auffällige Anfragen an den Benutzer-Endpunkt der REST-Schnittstelle sowie neu angelegte Anwendungspasswörter. Im Zweifel hilft eine saubere forensische Durchsicht mehr als eine Momentaufnahme.

Reicht es, Elementor vorübergehend zu deaktivieren?

Das Deaktivieren des Plugins entfernt den anfälligen Code aus dem aktiven Betrieb und ist als kurzfristige Notbremse vertretbar, wenn ein Update nicht sofort möglich ist. Die bessere und dauerhafte Lösung ist das Update auf 4.3.2 oder höher, weil Sie damit die Funktion behalten und zugleich die Ursache beseitigen.

Fazit

CVE-2026-62062 ist keine komplizierte Lücke, und genau das macht sie gefährlich. Ein einziger Link, ein eingeloggter Administrator, ein fremdes Admin-Konto. Die Reichweite von über 2 Millionen anfälligen Seiten und das öffentlich verfügbare Proof-of-Concept-Material sorgen dafür, dass diese Schwachstelle nicht lange unbeachtet bleibt. Der Patch ist da, er ist eindeutig, und er ist in Minuten eingespielt. Prüfen Sie Ihre Elementor-Version, aktualisieren Sie auf mindestens 4.3.2, und kontrollieren Sie Ihre Administratorkonten. Wenn Sie den Überblick über viele Installationen behalten oder die Prüfung und den Patch in verlässliche Hände geben möchten, übernehmen wir das im Rahmen unserer WordPress-Wartung für Sie.

Quellen

• Patchstack, Cross-Site Request Forgery in Elementor Plugin Affecting 2 Million+ Sites
• CVE.org, CVE-2026-62062
• NVD, CVE-2026-62062
• WordPress.org, Elementor, Changelog und Installationszahlen
• FIRST EPSS, Exploit-Prediction-Werte