Affected Elementor releases: 2 (4.3.0 and 4.3.1) (Source: Patchstack (September 27, 2026))
Elementor Website Builder versions 4.3.0 and 4.3.1 disabled the only CSRF protection WordPress applies to cookie-authenticated REST API requests, according to a Patchstack analysis. On a stock installation, a logged-in administrator who opens one crafted link creates a second administrator account for the attacker. Elementor fixed the issue in version 4.3.2.
What the flaw allows
Patchstack credits the researcher Saggre with discovering and reporting the issue. The link needs no JavaScript, no form and no page under the attacker's control. It works as a plain anchor in an email, a chat message or a comment, and it makes the user carry out any REST API action their account is permitted to perform.
Exposure reaches beyond the plugin
The bypass is evaluated before WordPress routes the request. Patchstack says it therefore applies to the entire REST API surface of the site: WordPress core routes and the routes of every other plugin installed alongside Elementor. The researcher showed a user-creation request that returned HTTP 401 without the bypass parameter and HTTP 201 with it, along with a user whose role was administrator. A separate request for site settings went from HTTP 401 to HTTP 200.
Patchstack's analysis notes that anything the victim's account can reach over REST is in scope, including endpoints belonging to plugins that did nothing wrong.
Why a settings review may not surface it
The affected code belongs to Elementor's Editor Events module. It is gated behind an experiment marked hidden, so the experiment does not appear on Elementor's Experiments screen at all. Patchstack reports that it is switched on by default for every site whose first Elementor installation was 3.32.0 or later. A default install of 4.3.0 or 4.3.1, with no settings changed and no other plugin present, is affected. Releases before 4.3.0 do not ship the Editor Events proxy and are not affected.
Only two releases carry the flaw. Patchstack does not say how many sites run 4.3.0 or 4.3.1, so the exposed share of that base is unknown.
Cause and fix
Patchstack traces the cause to a check that ran before WordPress had matched a route. The code searched the raw request URI for the string elementor/v1/events/ and, on a match, told WordPress that authentication had already succeeded. The URI includes the query string, which is written by whoever composes the link. Returning success at that point also skipped WordPress core's nonce check.
Authorization still applied. The route's own permission check asks what the current user may do, and a logged-in administrator's cookie answers that generously. In Patchstack's words, only the proof of intent is gone. Version 4.3.2 tests the route WordPress actually resolved and requires the namespace to sit at its start. Patchstack recommends updating to 4.3.2 or above, and says it has issued mitigation rules for its own users.
What to ask your team
First: which of our WordPress sites, including those run by agencies or subsidiaries, have Elementor installed, and which version is on each? Any site on 4.3.0 or 4.3.1 needs to move to 4.3.2 or above.
Second: for sites that ran either affected release, have administrator accounts been reviewed for entries nobody recognises? The flaw's stated outcome is a second administrator account.
Third: because the hidden experiment does not appear on Elementor's Experiments screen, how do we confirm exposure from the installed version instead of the settings page?
Fourth: do administrators open links from email and chat while logged in to the site? If they do, what compensating controls, such as separate browser sessions for admin work, are in place until patching is confirmed?
