- Patchstack says Elementor versions 4.3.0 and 4.3.1 turned off a key safeguard, so one logged-in administrator clicking one crafted link could give an attacker a new administrator account.
- Patchstack says the flaw reached every REST route on the site, including WordPress core and other plugins, and a hidden setting was on by default for sites first installed on 3.32.0 or newer.
- Update Elementor to 4.3.2 or later, check which sites run 4.3.0 or 4.3.1, and review administrator accounts for any you do not recognize.
According to Patchstack, two specific Elementor releases, 4.3.0 and 4.3.1, turned off the single CSRF safeguard WordPress core applies to REST API requests authenticated by cookie. On a default install, Patchstack found that having a logged-in administrator click one specially built link was enough to hand an attacker a new administrator account. Elementor fixed the issue in version 4.3.2.
What the flaw allows
Patchstack credits the researcher Saggre with discovering and reporting the issue. No script, no hosted form and no page under the attacker's control was required to pull it off. A plain hyperlink dropped into an email, a chat thread or a comment section was enough: clicking it made the victim's browser carry out whatever REST API actions that person's account was authorized to perform.
Exposure reaches beyond the plugin
The bypass was evaluated before WordPress routed the request. Because of that timing, Patchstack says the exposure was not confined to Elementor's own endpoints; it covered every REST route on the site, including WordPress core routes and the routes added by any other installed plugin. 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.
Per Patchstack's analysis, scope tracked what the victim's own account could reach over REST, not what Elementor's code did, so plugins with no flaw of their own were still exposed through this route.
Why a settings review may not surface it
The affected code belongs to Elementor's Editor Events module. It sits behind an experiment marked hidden, so the toggle never shows up on Elementor's Experiments screen. Patchstack reports the feature shipped active by default on any site whose first Elementor installation was version 3.32.0 or newer. That means an untouched install, with no settings changed and no other plugin present, running 4.3.0 or 4.3.1 was exposed. Versions released before 4.3.0 never shipped the Editor Events proxy that carries the flaw, so they sit outside its reach.
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?
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Patchstack.
