Elementor patches CSRF flaw in plugin versions 4.3.0 and 4.3.1 that can create admin accounts

What happened

Elementor has released version 4.3.2 of its Website Builder plugin for WordPress to fix a cross-site request forgery (CSRF) flaw that could be used to create an attacker-controlled administrator account [1]. The attack needs no credentials of its own: it borrows the session of a logged-in administrator who opens a crafted link [1].

Security firm Patchstack reported the issue to Elementor on 22 September after receiving it from a researcher credited as Saggre, and Elementor shipped a fix two days later [1]. Only versions 4.3.0 and 4.3.1 are affected. Elementor is active on roughly 10 million sites overall, and WordPress.org statistics cited by BleepingComputer put usage of those two specific versions at up to 2 million sites [1].

No CVE identifier had been assigned at the time of reporting, which is why this post carries no computed severity from NVD or CISA data. The Hacker News describes the flaw as high severity [2]; BleepingComputer’s report does not characterise its severity [1]. Neither source reports any exploitation in the wild of this particular bug.

Who is affected

• WordPress sites running Elementor Website Builder 4.3.0 or 4.3.1 [1].
• Sites on default installations are the ones where the reported outcome is a new administrator account [1].
• Releases before 4.3.0 do not contain the affected Editor Events proxy, so they are not vulnerable to this specific flaw. That is not a reason to stay on them: BleepingComputer notes that older Elementor versions carry other vulnerabilities, some of which have already been exploited [1].

The sources do not say whether Elementor Pro, or any of the many third-party add-on plugins that bundle Elementor components, ship the affected module separately.

How it works

According to Patchstack’s analysis as described by BleepingComputer, Elementor’s Editor Events module inspected the raw request URI looking for the elementor/v1/events/ path, and skipped WordPress’s REST nonce validation whenever that string was present [1].

The raw URI also contains query parameters an attacker controls. That means the marker string could simply be appended to a request aimed at some other REST endpoint, and the nonce check — the mechanism WordPress uses to prove a request was intentional — would be bypassed for that request too [1].

The consequence is a one-click attack. A logged-in user who opens the link performs whatever REST API action their account is allowed to perform [1]. For an administrator on a default install, that includes creating another administrator [1].

Two details make the delivery side easier than in a typical CSRF chain. Patchstack says exploitation does not depend on scripting, on hosting a malicious page, or on getting the victim to submit anything — a plain link is sufficient [1]. That link can arrive by email, chat message, or even a comment left on the target site [1].

The 4.3.2 fix stops the bypass from being triggered through the query string [1].

Why it matters in practice

CSRF is often filed under “needs user interaction, therefore low priority”. The user interaction here is an administrator clicking a link, which is a routine event, and the payload is a persistent account rather than a one-off action. Once a rogue administrator exists, removing the vulnerable plugin version does not remove the access.

The short exposure window helps. The affected code existed only in two releases, and the fix arrived two days after the private report [1]. Sites with automatic plugin updates enabled may already be on 4.3.2.

What to do

• Update Elementor Website Builder to 4.3.2 now on any site running 4.3.0 or 4.3.1 [1].
• Confirm the installed version after updating, from Plugins → Installed Plugins or with wp plugin get elementor --field=version over WP-CLI. Check every site in your estate, not just the ones you remember using Elementor.
• Review the user list for administrator accounts you did not create, and check recent user-creation events in your logs or audit plugin. Because the flaw produces a working admin account, this check matters even if you have already patched.
• Rotate credentials and application passwords for any administrator account you cannot account for, and force a re-login across the site if your stack supports it.
• If you are on a pre-4.3.0 release and were tempted to stay there, update to the current version instead. Older branches carry separate, known-exploited issues [1].
• Remind anyone with administrator rights not to open site-management links from email, chat or site comments while logged in. Doing WordPress administration in a separate browser profile reduces the blast radius of this class of bug.
• Treat the absence of a CVE as a tracking problem, not an all-clear. Record the fix internally against the plugin version rather than waiting for an identifier to appear in your vulnerability feed.