Elementor 4.3.0–4.3.1 CSRF Vulnerability (CVE-2026-62062): What It Does and How to Fix It

Patchstack has disclosed a cross-site request forgery (CSRF) vulnerability in the free Elementor Website Builder plugin, affecting versions 4.3.0 and 4.3.1 and fixed in 4.3.2. It is tracked as CVE-2026-62062. If an administrator on an affected site opens a crafted link while logged in, the attacker can create a new administrator account for themselves. The admin doesn't have to fill in a form or run a script. Opening the link is enough.

The bug was only live for a couple of days, which cuts both ways. Few sites were exposed for long, but many sites that auto-update picked up 4.3.0 and 4.3.1 as soon as they shipped. This guide explains what the flaw is, why Patchstack rates it "medium priority" even though its CVSS score is 8.8, how to tell whether your site was affected, and what to check once you've updated.

TL;DR

• Affected: Elementor Website Builder (the free plugin) 4.3.0 and 4.3.1. Fixed in 4.3.2, released September 24, 2026.
• Impact: a logged-in administrator who opens a crafted link can unknowingly create an administrator account for the attacker. The link can arrive by email, chat, or a comment.
• Why it's serious: the bug switches off WordPress's REST API nonce check for every REST route on the site, including core and other plugins, not just Elementor's own routes.
• Elementor Pro users are affected too. Pro runs on top of the free plugin, so what matters is the version of the free plugin.
• What to do: update to 4.3.2 or later, then look for administrator accounts created on or after September 22, 2026.

What is the Elementor 4.3.1 CSRF vulnerability?

It's a flaw that lets an attacker get a logged-in WordPress user's browser to send requests to the site's REST API without the anti-CSRF protection WordPress normally requires. Because the site sees the victim's valid login cookie, those requests run with the victim's permissions. If the victim is an administrator, the attacker can do anything an administrator can do through the REST API. Patchstack's write-up shows the most direct outcome: creating a new user with the administrator role.

Here are the published details:

Elementor has 10+ million active installs on wordpress.org. Patchstack's article puts the number of affected sites at over 2 million, which roughly matches the sites that had installed 4.3.0 or 4.3.1 before the fix came out.

What changed in 4.3.0 to cause it?

Version 4.3.0 came out on September 22, 2026, and was a large release. Its changelog lists Elementor MCP support for AI tools, a new Accordion element, Background Video with locally uploaded files, and Default Styles for HTML tags. According to Patchstack, the release also added an Editor Events proxy inside Elementor's Events Manager, a module that forwards the editor's usage data through a REST endpoint under elementor/v1/events/.

That module is where the bug is. It's an Elementor "experiment" (a feature flag), but it's hidden, so it doesn't appear on the Experiments screen in wp-admin. Patchstack found that it's switched on by default for sites whose first Elementor install was version 3.32.0 or later. On those sites, a fresh 4.3.0 or 4.3.1 install with default settings is vulnerable.

How does the vulnerability work?

You don't need to understand the code to fix this, but the mechanism shows why the impact reaches well beyond Elementor, so it's worth a short look.

How WordPress normally blocks CSRF on the REST API

When you're logged in to wp-admin, your browser holds a login cookie. On its own, that cookie would let any website you visit send requests to your WordPress site as you. That's the classic CSRF problem. WordPress blocks it on the REST API by requiring a nonce, a short-lived token that only pages served by your own site know. A cookie-authenticated REST request without a valid nonce is treated as logged out.

Plugins are allowed to adjust this check through the rest_authentication_errors filter. That's a legitimate hook, but it's also a single point where one plugin can weaken authentication for the whole REST API.

What Elementor's new code got wrong

Elementor's events proxy used that filter to skip the nonce check for its own telemetry route. Patchstack found two mistakes in how it decided whether a request was "its own":

1. It looked at the raw request URL, including the query string. The check searched REQUEST_URI for the text elementor/v1/events/ anywhere in the string. An attacker could call any REST route and add that text as a throwaway query parameter, and the check would match.
2. It ran before WordPress had worked out which route was being called. The rest_authentication_errors filter fires before routing is resolved. So the code was trying to answer "is this my route?" before WordPress knew what the route was.

When the check matched, the code told WordPress authentication had passed. That skipped the nonce check for whatever route was actually being requested: core's user endpoints, other plugins' endpoints, anything.

Why a single click is enough

CSRF attacks usually need a hidden form or some JavaScript to send a POST request. This one doesn't. WordPress's REST API accepts a _method query parameter that overrides the HTTP method, so a plain GET request (clicking a link) can be treated as a write. Patchstack notes the attack works as an ordinary link in an email, a chat message, or a comment, with no JavaScript needed.

We're not reproducing the request here. Patchstack's advisory already goes further than a site owner needs, and the details don't change what you should do.

How 4.3.2 fixes it

According to Patchstack, the patched code reads the route WordPress actually resolved (rest_route from the parsed query), not the raw URL. It requires the Elementor namespace to be at the start of the route, not just anywhere in it, and it adds a type check on the route value. That's the right fix. The bypass now only applies to the one route it was meant for.

Why "medium priority" when the CVSS score is 8.8?

This is the part of the advisory that confuses people, and it matters when you're deciding how fast to act.

CVSS measures how bad the result is when the attack succeeds. An attacker creating an administrator account means full control of the site, so confidentiality, integrity, and availability are all rated high. Hence 8.8.

Patchstack's priority rating is a separate label that answers a different question: how urgently should most sites patch compared with other open issues? This attack needs a specific person to do something: a logged-in administrator has to open the attacker's link. It can't be sprayed across the internet by a bot the way an unauthenticated file upload can. That need for user interaction is why a high-impact bug can still get a medium priority label.

Don't read "medium" as "can wait." Getting a site admin to click a link is some of the easiest social engineering there is. Agency staff, freelancers, and store owners open links from clients and contact forms all day. And a link in a comment waiting for moderation is exactly what an admin will look at. The fair summary is that this won't be mass-exploited by bots, but a targeted attacker only needs one click.

Is your site affected?

Go through these questions in order.

1. Is the free Elementor plugin installed? This includes every Elementor Pro site, because Pro requires the free plugin.
2. Was it on 4.3.0 or 4.3.1 at any point? Those versions were current from September 22 to September 24, 2026. A site that was still on 4.2.x the whole time and jumped straight to 4.3.2 was never exposed through this bug.
3. Was the Events Manager experiment active? Per Patchstack, it's on by default for sites first set up on Elementor 3.32.0 or later. Older sites may not have had it enabled. Because it's a hidden experiment, you can't easily confirm its state from the dashboard, so don't count on it as your protection.
4. Did anyone with admin rights use the site while it was vulnerable? The attack only works while an administrator is logged in.

To check your current version with WP-CLI:

wp plugin get elementor --field=version

If you manage several sites, check them all at once:

wp plugin list --name=elementor --fields=name,status,version,update_version

If the version is 4.3.0 or 4.3.1, update now. If it's 4.3.2 or later, you're patched, but read the next section anyway if the site was on an affected version at any point.

How to fix it: update Elementor to 4.3.2 or later

The only complete fix is the update. As of this writing, 4.3.2 is the current version on wordpress.org. It requires WordPress 6.8+ and PHP 7.4+. Those requirements may change in later releases.

Important: Take a backup before updating a production site, even for a security release. On MagicWP you can take an on-demand backup from the site dashboard first.

From wp-admin, go to Plugins, find Elementor, and click Update now. From WP-CLI:

wp plugin update elementor
wp plugin get elementor --field=version

The 4.3.2 changelog doesn't mention a CSRF fix by name. Its only security line is "Improved code security in data handling," next to several unrelated fixes. That's common for plugin vendors, and it means someone skimming changelogs to decide which updates are urgent would easily miss this one. Go by the advisory, not the changelog wording.

If you run Elementor Pro

Update the free Elementor plugin. That's where the vulnerable code is. The 4.3.2 changelog also mentions better update stability between Core and Pro, so if Pro shows a version-mismatch notice after the update, update Pro as well. Don't roll the free plugin back to 4.3.1 to clear the notice.

If you can't update right away

There's no officially documented workaround, and the setting that controls the vulnerable module isn't in the dashboard. If an update has to wait (for example, a staging review is required first), reduce the risk until it's done:

• Don't open unexpected links while logged in as an administrator. Use a private window or a lower-privilege account for reading email and moderating comments.
• Log out of wp-admin when you're not using it, so there's no active session for a forged request to use.
• Deactivate Elementor temporarily if the site can go without it for a short while. Pages built with Elementor won't render properly while it's off, so this is a last resort for a few hours, not a long-term fix.

Apply the real update as soon as you can. Staging is useful here: clone the site to staging, update there, check the key pages, then update production.

After updating: check whether anyone used the hole

Updating closes the hole, but it doesn't undo anything done through it. The most likely thing an attacker would leave behind is exactly what the advisory describes: an extra administrator account. Check that first.

1. List every administrator and when it was created

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Look closely at any account registered on or after September 22, 2026. Treat any admin you don't recognize as hostile until you've confirmed otherwise with the rest of your team. The same list is in wp-admin under Users → All Users, filtered by the Administrator role, but WP-CLI shows the registration date directly.

Also check roles that can do almost as much damage, such as Editor or custom roles with manage_options:

wp user list --fields=ID,user_login,roles,user_registered --orderby=registered --order=DESC | head -n 20

2. Search your access logs for the bypass pattern

The attack leaves a clear trace: REST API requests that include elementor/v1/events/ in the query string while calling a different route. A rough search:

grep -E "(wp-json|rest_route=)" /path/to/access.log | grep "elementor/v1/events/" | grep -v "wp-json/elementor/v1/events"

Change the log path to match your server. Anything this returns deserves a closer look, especially requests to wp/v2/users. Normal editor telemetry calls the events route directly, so it's filtered out by the last grep -v. A clean result is reassuring but not proof. Logs rotate, and some setups don't log query strings.

3. If you find a rogue account

Don't just delete it and carry on. An attacker with admin access can install a plugin, add a file, or change code in minutes, and deleting the account removes none of that. Treat it as a compromise:

• Put the site in maintenance mode or restrict access.
• Take a backup of the site in its current state before cleaning, so you have evidence.
• Compare what's installed against what should be there:

wp plugin list --fields=name,status,version
wp core verify-checksums
wp plugin verify-checksums --all

• Look for recently changed PHP files, especially in wp-content/uploads, where PHP should never be:

find wp-content -name "*.php" -newermt "2026-09-22" -print

• Once the site is clean, delete the rogue account, reset every administrator password, and rotate the security keys in wp-config.php:

wp config shuffle-salts

Rotating the salts logs out every session, including any the attacker might still hold.

If you have a clean backup from before September 22, 2026, restoring it and then updating Elementor is often faster and more reliable than cleaning by hand. You'll lose any content added since then, so weigh that before choosing.

What this bug says about plugin risk

There are three lessons here that go beyond this one plugin.

One plugin can weaken the whole REST API. The vulnerable code was meant to affect one telemetry route and ended up affecting every route on the site. Hooks like rest_authentication_errors apply site-wide. When you review a plugin, or write one, any code that loosens authentication for "just our endpoint" deserves careful scrutiny, because checking the wrong input turns "just ours" into "everyone's."

Hidden, on-by-default features add risk you can't see. Site owners can't audit a feature that isn't shown anywhere in settings. The Events Manager experiment was turned on for newer installs without the owner ever choosing it. This isn't unusual in large plugins, but it means your real exposure is decided by the vendor's defaults, not your settings.

Fast auto-updates cut both ways. Sites that auto-update got the bug on day one and the fix on day three. Sites on manual updates may have skipped the bug entirely, but they'd also be slow to get the fix for the next flaw that's already public. For widely used plugins, automatic updates plus a quick post-update check of admin accounts and error logs is still the better trade. The goal isn't avoiding every bad release. It's keeping the window short.

Frequently Asked Questions

Which Elementor versions are vulnerable to CVE-2026-62062?

Only versions 4.3.0 and 4.3.1 of the free Elementor Website Builder plugin are affected. Version 4.3.2, released September 24, 2026, fixes it. Earlier releases such as 4.2.x don't include the vulnerable events proxy code and aren't affected by this bug, though you should still move to the current version because older releases have their own patched issues.

Is Elementor Pro affected?

Yes, indirectly. The vulnerable code is in the free Elementor plugin, and every Elementor Pro site runs the free plugin underneath. If your Pro site has the free plugin at 4.3.0 or 4.3.1, it's vulnerable. The fix is to update the free Elementor plugin to 4.3.2 or later, and to update Pro too if it shows a compatibility notice afterwards.

Can this be exploited without anyone logged in?

No. The attacker doesn't need an account, but they need a logged-in user, ideally an administrator, to open a crafted link. The forged request runs with that user's permissions. If nobody with admin rights opened such a link while the site was on 4.3.0 or 4.3.1, the vulnerability couldn't have been used to create an admin account.

Why does Patchstack call it medium priority if the CVSS score is 8.8?

The two numbers measure different things. CVSS 8.8 reflects the impact of a successful attack, which is full site takeover. Patchstack's priority rating reflects how urgently sites need to patch compared with other issues, and it takes into account that this attack needs a specific user to click a link. It can't be automated against thousands of sites the way an unauthenticated upload flaw can.

Is CVE-2026-62062 being exploited in the wild?

As of the September 25, 2026 coverage, no active exploitation had been reported. That can change quickly once technical details are public, so check the current status with Patchstack or other vulnerability databases before assuming you're safe. Regardless of reports, check your administrator list for accounts created since September 22.

Can I just disable the Events Manager experiment instead of updating?

Not easily, and it isn't a recommended fix. The experiment is hidden, so it doesn't appear on Elementor's Experiments screen, and no official workaround has been published. Updating to 4.3.2 is the supported fix. If you truly can't update for a few hours, stay logged out of wp-admin when you're not using it and don't open unfamiliar links while logged in as an admin.

Does updating remove an attacker who already got in?

No. The update closes the hole, but accounts, plugins, or files an attacker added stay in place. After updating, list every administrator account and its registration date, look for unfamiliar plugins and recently modified PHP files, and if you find anything, treat the site as compromised: clean it or restore a pre-September 22 backup, then reset passwords and rotate the salts.

Is this the same as CVE-2026-87902?

No. CVE-2026-87902 is a separate WordPress vulnerability that was reported as actively probed in September 2026. It has nothing to do with Elementor. CVE-2026-62062 is the Elementor 4.3.0–4.3.1 CSRF flaw covered here. Search results around the same dates mix the two up, so check the CVE number against the plugin before acting on any advice.

Conclusion

The Elementor 4.3.1 CSRF vulnerability is a small coding mistake with a big effect. A check meant to exempt one telemetry route ended up switching off the REST API's CSRF protection for the whole site, and the only thing standing between an attacker and a new admin account was one click from a logged-in administrator. The fix is simple: update the free Elementor plugin to 4.3.2 or later. The follow-up matters just as much: check your administrator accounts for anything created since September 22, 2026.

If you'd rather not track plugin advisories site by site, MagicWP's managed WordPress hosting includes security features like a WAF, malware scanning, and isolated containers, plus on-demand backups before any change. Keeping plugins current and checking who has admin rights is still your job, though, whichever host you use.