Elementor CVE-2026-62062: One Link Can Add an Admin

CVE-2026-62062 lets one link, opened by a logged-in WordPress user, perform any REST API action that user is allowed to perform. On a default site that means an administrator’s click creates a new administrator for the attacker.^[1] Only Elementor 4.3.0 and 4.3.1 are affected. Update to 4.3.2, then check for administrators added since September 22.^[1][2]

The exposure window is short. Elementor shipped 4.3.0 on September 22, 4.3.1 on September 23, and the fix, 4.3.2, on September 24.^[3] BleepingComputer, citing WordPress.org data, puts the number of sites on the two vulnerable releases at up to 2 million.^[4] No report we’ve seen mentions exploitation in the wild, but the technical write-up is public, and the attack is a single URL.^[1][4]

TL;DR: What to do right now

1. Check the Elementor version on every site. Anything on 4.3.0 or 4.3.1 needs 4.3.2 or later.^[2] Older releases are not affected.^[1]
2. List administrators and look at the registration dates. Anyone added on or after September 22 that you can’t account for gets removed and investigated.^[6]
3. Until every site is updated, don’t click links in pending comments, contact-form emails or chat messages while you’re logged in to wp-admin.^[1]
4. Agencies: run the version check across the fleet, not just the sites that auto-update. The loop below does it in one pass.
5. Keep the output with the date. It’s your record of which sites were exposed and for how long.

What CVE-2026-62062 does

The bug sits in Elementor’s Editor Events module, which proxies editor telemetry. In the two affected releases, it switches off WordPress core’s CSRF check for cookie-authenticated REST requests whenever the text elementor/v1/events/ appears anywhere in the request URI.^[1] The request URI includes the query string, and whoever writes the link controls the query string. So any REST request can opt out of the check by carrying a harmless-looking extra parameter.^[1]

Why a plain link is enough

Most REST CSRF bugs need a page that submits a form or runs script. This one doesn’t, because the REST API accepts a _method parameter that overrides the HTTP method.^[5] A normal click on a link can therefore create, change or delete data.^[1] Patchstack’s write-up puts it plainly:

It works as a plain anchor in an email, a chat message, or a comment.

Patchstack ^[1]

It isn’t limited to Elementor’s own endpoints

The bypass runs before WordPress picks a route, so it covers the whole REST API: core routes and every other plugin’s routes too.^[1] The researcher showed a new administrator account and a settings read that returned data instead of a 401.^[1] Anything the victim’s account can reach over REST is in scope, which is why the role of whoever clicks matters so much.

Are older Elementor sites safe?

Yes, if they never ran 4.3.0 or 4.3.1. Patchstack says the vulnerable code didn’t exist earlier:

Releases before 4.3.0 do not ship the Editor Events proxy at all

Patchstack ^[1]

The module is behind a hidden experiment, so you won’t find it on the Experiments screen. It’s on by default for sites whose first Elementor install was 3.32.0 or later, and a default 4.3.0 or 4.3.1 install is affected.^[1] Don’t try to reason your way out of the update. Just install 4.3.2.

How to check your sites

1. Check the Elementor version

With WP-CLI, run this from the site’s root. In wp-admin, the Plugins screen shows the same number.

wp plugin get elementor --field=version
# affected: 4.3.0, 4.3.1   fixed: 4.3.2+
wp plugin update elementor

2. Look for administrators added since September 22

The attack’s clearest result is an extra administrator.^[1] wp user list can filter by role and show the registration date.^[6]

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

Anything registered on or after September 22 that nobody on your team created needs attention. Remove the account, rotate passwords for the real admins, and review what changed on the site. A CSRF attack acts with the victim’s permissions, so also check settings and plugin lists, not just users.^[1]

3. Search the access logs

Patchstack’s advisory doesn’t publish indicators of compromise.^[1] The trigger string does have to appear in the URL, though, so it’s worth a search. Elementor’s own telemetry calls hit /wp-json/elementor/v1/events/ directly. What stands out is the string sitting in the query of a request to some other route. The log path below is an example; use your server’s.

LOG=/var/log/nginx/access.log
grep -E '\?.*elementor(/|%2F)v1(/|%2F)events' "$LOG" \
  | grep -v 'rest_route=/elementor/v1/events'

A hit isn’t proof of compromise, and no hits isn’t proof of safety, since many hosts rotate logs quickly. Treat it as a lead, and pair it with the user check above.

4. Agencies: check the whole fleet

Put your WP-CLI aliases (one per line, like @client1) in a file and check them together.

while read -r site; do
  echo "== $site"
  wp "$site" plugin get elementor \
    --field=version < /dev/null
done < sites.txt

Pay particular attention to sites with plugin auto-updates on. They’re the ones most likely to have picked up 4.3.0 on day one, and also the most likely to have 4.3.2 already. Confirm rather than assume.

Why the comment queue matters here

The delivery channel for this bug is a link a logged-in person will click. For most WordPress sites, the places strangers can put a link in front of an administrator are comments, contact forms and registration emails. We covered a different attack through the same door this week in Comment2Shell.^[7] The habit that protects you from both is the same: moderate from a clean state, and don’t follow links in unknown submissions while you’re signed in as an admin.

Zero Spam doesn’t patch Elementor, and it won’t stop an admin who opens a malicious link from their inbox. What it does is cut the spam and malicious submissions that reach your comment queue and forms, through the free WordPress plugin or the API, so there are fewer strange links in front of your team. If that’s useful, start on the free Explorer plan; code ZEROSPAM20 takes 20% off a paid license.^[8] For the wider picture, see our guide to stopping contact form spam.

FAQ

About Ben Marshall

Full-stack Developer & Engineering Manager

Ben Marshall is a full-stack developer and engineering manager who loves building solid software and helping teams do their best work. He’s equal parts builder and coach—focused on practical architecture, clean implementation, and making collaboration easier (and faster) for everyone.

• WordPress.org