If your site runs Elementor and it updated itself sometime in the last week, there was a window of roughly two days where a single link in your inbox could have handed a stranger an administrator account on your website. No password guessing, no malware, no form to fill in. You click, and the site quietly creates a second admin for somebody else.
That window has closed. Elementor 4.3.2 fixes it. But “it’s fixed” and “you are on the fixed version” are two different sentences, and the gap between them is worth ten minutes of your morning.
The short version
- The bug affects Elementor (the free Website Builder plugin) versions 4.3.0 and 4.3.1 only.
- It is fixed in 4.3.2, released 24 September 2026.
- It is tracked as CVE-2026-62062. A CVE is just the industry’s serial number for one specific vulnerability, so everyone can be sure they are talking about the same thing.
- It is rated 8.8 out of 10 on the standard severity scale, which puts it in the “high” band.
- If you are on 4.3.2 or later, or on anything older than 4.3.0 (the whole 3.x line, for instance), you were never exposed to this particular bug.
Elementor is active on more than 10 million sites. Going by WordPress.org’s own statistics, the two affected releases reached up to around 2 million of them before the patch landed. The details are in Patchstack’s advisory, which is the primary source for everything below, and the vulnerability record itself is in the Patchstack database and on WPScan.
What actually goes wrong
WordPress protects sensitive actions with something called a nonce: a one-time token stitched invisibly into the page you are looking at. When your browser asks WordPress to do something serious, like create a user, WordPress looks for that token. If it is missing, WordPress assumes the request did not really come from you, and refuses.
That check is what stops cross-site request forgery, usually shortened to CSRF. It is an attack where someone else’s link or page makes your logged-in browser perform an action on your site, using your own session. From the server’s point of view a legitimate administrator is doing something perfectly normal. It has no way of knowing you did not mean it.
Elementor 4.3.0 introduced a module that reports editor activity back to the plugin. To let its own requests through without friction, it told WordPress to skip the nonce check whenever the text elementor/v1/events/ appeared in the web address of the request.
The problem is the whenever. The check looked at the entire address, including the query string — the part after the question mark that anybody can write whatever they like into. So bolting a meaningless parameter like ?x=elementor/v1/events/ onto the end of any request to the site made that request exempt from the nonce check.
Not just Elementor’s requests. Every route on the site’s REST API, which is the set of behind-the-scenes web addresses WordPress and its plugins use to talk to themselves. WordPress core’s routes, and every other plugin’s routes too. Including the built-in one for creating users.
The practical effect: a logged-in administrator opening one crafted link would create a brand new administrator account, controlled by whoever sent the link. Patchstack puts it plainly — “One link, opened by a logged-in WordPress user, makes that user carry out any REST API action their account is permitted to perform.”
Why this one is nastier than most
Most CSRF attacks need scaffolding. A web page the attacker controls, a hidden form on it, a bit of JavaScript to submit that form without you noticing. That scaffolding is a real barrier, because it means getting you onto a dodgy website first.
This one needed none of it. It was a plain link. It could sit in an email, a Slack message, a text, or a comment left on your own site. Exactly the sort of link a busy person clicks without a second thought, especially when it is dressed up as a WordPress notification, a plugin licence warning or an invoice.
That is why “high severity” here is not analyst hand-wringing. The attack is nearly free to send, and it only needs one distracted click from one person who happens to be logged in at the time.
How exposed were you, really?
This is the part that will settle it for most people, and it is oddly reassuring. The three releases came out on consecutive days:
- 4.3.0 on 22 September 2026, a large feature release
- 4.3.1 on 23 September 2026
- 4.3.2 on 24 September 2026, the fix
The researcher, who goes by Saggre, reported the flaw through Patchstack on 22 September — the same day the vulnerable version shipped. Elementor patched it two days later. The public advisory followed on 25 September, after the fix was already available. That is close to the best-case version of how this process is supposed to run, and Elementor deserves credit for the turnaround.
So the vulnerable window was short. Short is not zero, though, and 4.3.0 was a headline release that plenty of people installed the moment it appeared.
The changelog will not tell you this is urgent
One detail worth carrying forward: the 4.3.2 changelog on WordPress.org does not say “fixes a serious security flaw”. It says “strengthened data handling security protocols”, sitting quietly between a background-video fix and a styling fix. If you skim changelogs to judge whether an update is urgent, this is a good reminder that you often cannot tell from the changelog.
Is anybody actually exploiting it?
As things stand, no confirmed attacks have been reported. Both BleepingComputer and The Hacker News noted at the time of publication that the flaw was not known to be exploited in the wild, and no evidence of real-world use has surfaced since. Treat that as the current state of reporting, not a guarantee.
Two honest caveats. First, proof-of-concept code demonstrating the attack is now circulating publicly, and historically that shortens the gap between disclosure and opportunistic scanning. Second, “no confirmed attacks” is not the same thing as “nothing happened to your site”. CSRF leaves very little behind, because as far as the server is concerned the request came from a legitimately logged-in administrator.
We are not suggesting your site is compromised. It almost certainly is not. We are saying the check is cheap, and cheap checks on unconfirmed risks are how you avoid expensive ones.
What to do this week
- Check your Elementor version. WordPress admin, then Plugins. If it reads 4.3.0 or 4.3.1, update now. If it reads 4.3.2 or higher, you are patched and you can stop worrying about this one.
- Read your user list properly. Users, then All Users, then filter to Administrators. Every account there should be a person you can name out loud. Anything you do not recognise, or anything created in the last week that you did not create, deserves a hard look before you touch it.
- Check the email addresses, not just the usernames. A standard trick is to leave the username looking plausible while the email quietly points somewhere else.
- Take a backup before you change anything, so you have something to compare against and something to roll back to.
- Turn on automatic updates for Elementor if they are off. In a two-day window like this one, auto-updates are the whole difference between exposed and not.
If you were running 4.3.0 or 4.3.1 and you or a colleague clicked something unexpected last week, do steps two and three carefully rather than at a glance, and change the passwords on your administrator accounts while you are in there.
The wider point
Nothing here was Elementor being cavalier with your data. It was a shortcut inside one module that turned out to have a far wider blast radius than whoever wrote it imagined, and it was found, reported and fixed inside 48 hours. That part of the system worked.
What the system cannot do is press the update button on your site, or notice that your administrator list has four people in it when your business has three. That is somebody’s job, and on a lot of small business sites it is quietly nobody’s.
If you would rather it was not yours, that is the sort of thing we look after: watching the advisories, patching inside the window, and checking the user list afterwards. Either way, go and look at your Elementor version first.
Next step
Find out what a scanner sees on your site.
Run a free, non-invasive scan in about a minute. You'll get a plain-English security grade and the fixes that matter, no signup required.