Elementor CSRF Flaw Lets Attackers Create Admin Accounts

Elementor, the most widely used page builder for WordPress with more than ten million active installations, has patched a cross-site request forgery (CSRF) vulnerability that let a single link execute any REST API action the logged-in user is allowed to perform. Discovered by researcher Saggre and reported to Patchstack, the flaw affects only versions 4.3.0 and 4.3.1 of the Elementor Website Builder plugin. On a stock WordPress installation, an administrator who clicks a crafted link while logged in can unknowingly create a second administrator account for an attacker, with no JavaScript, no form, and no page under the attacker's control. Patchstack has issued mitigation rules to protect against exploitation.

In the affected releases, Elementor disables WordPress core's only CSRF protection for cookie-authenticated REST API requests whenever the literal string elementor/v1/events/ appears anywhere in the request URI. Because the request URI includes the query string, and the query string is written by whoever composes the link, any REST request can opt itself out of that protection by appending a harmless-looking parameter. The vulnerable code lives in the Editor Events module, which proxies Elementor's editor telemetry. The module is hidden from the site's Experiments screen, but it is turned on by default for every site whose first Elementor installation was version 3.32.0 or later, so a default install of 4.3.0 or 4.3.1 is affected. The module's constructor registers the filter unconditionally, meaning no telemetry setting on the site prevents it. Releases before 4.3.0 do not ship this proxy and are not vulnerable.

The core problem is timing. The events proxy registers two REST routes and wants its own requests exempted from the REST nonce check. To achieve that, it hooks rest_authentication_errors at priority 0, before WordPress has matched any route. The callback checks whether the raw request URI contains the string elementor/v1/events/, using an unanchored substring search. Since the query string is entirely attacker-controlled, a parameter name and value can be crafted to satisfy this check while the request is dispatched to a completely different endpoint. Once the check passes, the callback returns true, which tells every later authentication handler, including WordPress core's own nonce verification, that authentication has already succeeded. The route's permission_callback still runs, so the victim's own permissions decide what the attacker can do. Authorization remains intact; only the proof of intent is gone.

The attack fits entirely inside a URL because WordPress core accepts a _method query parameter that overrides the HTTP verb. A normal GET navigation can therefore perform writes. Patchstack's researchers demonstrated a URL that creates a new user with the administrator role: the request targets /wp-json/wp/v2/users and adds _method=POST, plus parameters for username, email, password, and roles. The final parameter, x=elementor/v1/events/, is the only part that matters. Without it, WordPress returns HTTP 401 with rest_cannot_create_user. With it, the server returns HTTP 201 and a user object whose roles array is ["administrator"]. The researcher also confirmed that a marker one character short of the real namespace, elementor/v1/event/, is rejected, ruling out any other explanation for the difference. Because a single anchor tag is sufficient, the payload can be delivered anywhere a link can go: an email, a chat message, a forum post, or a comment on an unrelated site. The victim sees a normal link and a JSON response.

The impact is broader than Elementor's own endpoints. The bypass runs before WordPress routes the request, so it applies to the entire REST API surface of the site: WordPress core routes and the routes of every other plugin installed alongside it. Creating an administrator through /wp/v2/users is the clearest demonstration, but Patchstack's report also showed that GET /wp-json/wp/v2/settings turns from HTTP 401 into HTTP 200 with the site settings in the response body. Any action the victim's account can perform over REST is in scope, including endpoints belonging to plugins that did nothing wrong.

Elementor fixed the vulnerability in version 4.3.2. The replacement check reads $wp->query_vars['rest_route'], which is the route WordPress actually resolved after rewriting, with the query string already separated out. No attacker-composed text remains in the value being tested. The comparison also changed from a loose substring search to an anchored check that the route begins with /elementor/v1/events/. An is_string guard closes the door on submitting rest_route as an array. Both the input source and the anchored comparison matter; fixing only one would have left a smaller version of the same bug.

The root cause is a mismatch between a question and the data available to answer it. The code wanted to know whether a request was for its own route, but it asked at a point in the request lifecycle where WordPress had not yet decided that, and settled for a substring search over a string the client controls. Two lessons generalize beyond Elementor. First, $_SERVER['REQUEST_URI'] is attacker-controlled input, not routing metadata; any security decision based on it needs the query string removed and the comparison anchored. Second, rest_authentication_errors is a shared channel, and returning a truthy value on it is not a local opt-out; it asserts success to every handler downstream, including WordPress core's nonce verification. A filter that only ever needs to say 'no opinion' should return the original result unchanged. Patchstack received the report on 2026-09-22, Elementor released version 4.3.2 on 2026-09-24, and the public advisory was published on 2026-09-25. The recommendation is to update Elementor to version 4.3.2 or above immediately.

For website owners, this vulnerability is a reminder that widely used plugins are attractive targets and that a single outdated plugin can put an entire site at risk. Managed WordPress hosting services such as AEU Hosting, which provides secured end-to-end managed WordPress hosting, can be a helpful part of a security routine that includes prompt plugin updates and monitoring.