website security

Elementor vulnerability: update to 4.3.2, then check your admins

The Elementor vulnerability in 4.3.0 and 4.3.1 lets a crafted link create a WordPress admin. Update to 4.3.2, then check Users for anyone you do not know.

You saw the headline: one click on a crafted link can hand a stranger a new administrator account on a WordPress site built with Elementor. Now you are wondering whether you clicked something odd this week, or whether someone on your team did. The fix is short. This Elementor vulnerability affects versions 4.3.0 and 4.3.1 of the Elementor plugin, and version 4.3.2 closes it. Update first, then open your Users screen and look for any administrator nobody at your business created. The risk only applies when the person who opened the link was logged in to WordPress at the time, with enough permissions to do damage. Both checks take minutes, and you can do them yourself before you call anyone. What follows walks you through each step, and what to do if you find something you do not recognize.

Key Takeaways

Update to 4.3.2 or later

Elementor 4.3.0 and 4.3.1 are the affected versions, and 4.3.2, released September 24, 2026, fixes the flaw.

Then check your administrators

Open Users, filter to Administrator, and look for any name, email or creation date you cannot explain.

The click only matters if someone was logged in

The crafted link borrows a logged-in user's session, so the danger depends on who opened it and what their account could do.

Record before you delete

If an unknown admin turns up, write down its details, then remove it and reset passwords, sessions and keys.

Which Elementor versions are affected, and what fixes it?

The affected versions are Elementor 4.3.0 and 4.3.1, the free Elementor Website Builder plugin. The fixed version is 4.3.2, released on September 24, 2026. Anything from 4.3.2 onward is past this flaw.

The facts come from Patchstack, the security firm that handled the report. Its vulnerability record for this Elementor CSRF flaw lists it as CVE-2026-62062 with a severity score of 8.8 out of 10, credits a researcher named Saggre, and marks it patched in 4.3.2. Patchstack says it received the report on September 22, 2026 and published its advisory on September 25, 2026.

The Elementor CSRF flaw at a glance
DetailWhat the record says
PluginElementor Website Builder (the free Elementor plugin)
Affected versions4.3.0 and 4.3.1
Fixed version4.3.2, released September 24, 2026
IdentifierCVE-2026-62062, per Patchstack
Severity score8.8 (CVSS)
TypeCross-site request forgery (CSRF)
ReportedSeptember 22, 2026, by researcher Saggre
Advisory publishedSeptember 25, 2026
Exploitation reportedNone as of September 26, 2026; Patchstack expects it
DetailPlugin
What the record saysElementor Website Builder (the free Elementor plugin)
DetailAffected versions
What the record says4.3.0 and 4.3.1
DetailFixed version
What the record says4.3.2, released September 24, 2026
DetailIdentifier
What the record saysCVE-2026-62062, per Patchstack
DetailSeverity score
What the record says8.8 (CVSS)
DetailType
What the record saysCross-site request forgery (CSRF)
DetailReported
What the record saysSeptember 22, 2026, by researcher Saggre
DetailAdvisory published
What the record saysSeptember 25, 2026
DetailExploitation reported
What the record saysNone as of September 26, 2026; Patchstack expects it

What about Elementor Pro? Patchstack's advisory names the Elementor plugin and does not list Elementor Pro as affected by this flaw. Keep Pro updated anyway, because a different, earlier flaw did hit it. SecurityWeek reported on September 5, 2026 that an Elementor Pro file-upload flaw, CVE-2026-32475, fixed in Pro 4.2.2 on August 19, was being exploited. That is a separate problem, but if you run Pro, confirm it is on 4.2.2 or later while you are in the Plugins screen.

OWASP, the open security project, describes cross-site request forgery as an attack that forces a logged-in user to carry out actions they did not intend on a site that trusts them. In plain words, the link does not break in. It borrows the person who clicked it.

When you are logged in to WordPress, your browser holds a login cookie. Any request your browser sends to your site carries that cookie, even a request that started from a link in an email. WordPress normally blocks forged requests with a check that proves the request came from your own dashboard. Patchstack found that Elementor 4.3.0 and 4.3.1 could switch that check off when a request contained a particular string. So, a crafted link opened by a logged-in administrator could tell the site to do something, and the site would treat it as a real instruction from that administrator.

According to Patchstack's write-up of the Elementor flaw, the forged request can do anything through the WordPress REST API that the clicking user's account is allowed to do. Creating a second administrator account is the example that made the headlines. Patchstack also notes the link can arrive as a plain link in an email, a chat message or a comment.

A face-down phone beside an opened blank envelope on a wooden kitchen table.
The link can arrive anywhere; what matters is who was logged in when it was opened.

Three things had to line up for a click to cause harm: the site was on 4.3.0 or 4.3.1, the person who clicked was logged in to that WordPress site, and their account had enough permissions for the request. An editor's account cannot create an administrator, because WordPress roles and capabilities limit what each role can do. An administrator's account can. That is why the check below starts with the administrator list. The attacker also never sees your password. The flaw uses your open session, so changing your password afterward is part of the cleanup, not proof that nothing happened.

What should you do in the next ten minutes?

The first response is a short routine you can run yourself. It moves you from "I think we are fine" to a written record of what you checked. Do it from a clean start: type your site's login address yourself rather than clicking a link in a news story or an email. The four steps below cover the update, the admin list and a quick record.

The ten-minute Elementor check

  1. 1

    Minutes 1 to 2, record the version

    Log in directly, open Plugins, find Elementor and write down the version number you see before changing anything.

  2. 2

    Minutes 3 to 5, back up and update

    Take or confirm a backup, then update Elementor to 4.3.2 or later. If Elementor Pro is installed, update it too.

  3. 3

    Minute 6, confirm and set auto-updates

    Reload Plugins, confirm the new version number, and check whether automatic updates are on for Elementor.

  4. 4

    Minutes 7 to 10, check administrators

    Open Users, filter to Administrator, and read every username, email address and registration date.

Update Elementor the safe way

Elementor's own guide to updating Elementor and Elementor Pro recommends backing up before you update and keeping both plugins current. A backup matters for a simple reason: if the update clashes with your theme or another plugin, you can roll back to a working site instead of rebuilding a page by hand. After the update, open a few key pages, such as the home page and your contact form, and make sure they still look and work the way they did.

While you are in Plugins, look at the auto-update setting for Elementor. With automatic updates on, the next security fix installs itself instead of waiting for someone to notice a headline. If you have held off on auto-updates because a past update broke something, that is a real concern, and it is a reason to schedule a regular update check rather than leave the plugin untouched.

A closed laptop beside a small external backup drive and a cup of coffee on a worn wooden desk.
A backup first turns a risky update into a routine one.

Read your administrator list line by line

Open Users in your WordPress dashboard and select the Administrator filter at the top of the list. For each account, ask three questions. Do you know who this is? Do you recognize the email address? Does the date it was created make sense?

Pay the closest attention to administrators created on or after September 22, 2026, the day the flaw was reported, or after any click you are worried about. An account with a random-looking username, an email on a domain you do not use, or a creation date nobody can explain deserves a closer look. Also glance at the full user list, not only administrators, for accounts created recently that nobody requested.

Beyond users, Patchstack's point that the forged request could do anything the clicking account could do means a few settings are worth a look too. Check the administrator email under Settings, the list of active plugins and themes, and any scheduled actions or security log your site keeps. You are looking for changes nobody on your team made.

What if you find an admin account you did not create?

An unknown administrator changes the job. It is no longer a plugin update; it is an incident, and the order of your next steps matters. The goal is to shut the door without throwing away the evidence of how it was opened.

Write it down before you remove it

Before you delete anything, record the account's username, email address, creation date and role. Take screenshots. Note anything else that looks changed: a new plugin, a different administrator email, a setting nobody touched. If your host or a security plugin keeps logs, save a copy covering the days around the account's creation date. Deleting the account first can erase the only trail showing what it did.

Then shut the door behind it

Once the details are recorded, disable or remove the account. Reset the passwords for every legitimate administrator, and log out all sessions so any stolen session stops working. Replace application passwords and any API keys the site uses, such as those connecting it to a payment, email or form service. Then look for plugins, themes or files that were added or changed. If you are not sure what to look for, our walk-through of the first 24 hours after a website is hacked covers the steps in order.

A plain manila folder, a small ring of keys and a closed laptop on an otherwise bare desk.
Record the account first, then remove it, then change every key.

Updating Elementor removes this particular opening. It does not undo anything done before the update, and it does not prove the site was untouched. That is why the admin check matters even after you see 4.3.2 in your Plugins list.

Is this Elementor flaw being exploited right now?

No exploitation of this flaw had been reported as of September 26, 2026. Patchstack rates it as "expected to become exploited" and says flaws of this kind are used in mass campaigns, so treat it as urgent to patch. That is a warning about what is likely, not a report that attacks are happening.

The official list to watch is the CISA Known Exploited Vulnerabilities Catalog, where the U.S. Cybersecurity and Infrastructure Security Agency lists flaws with confirmed attacks. CVE-2026-62062 did not appear in the catalog material reviewed for this post. Absence from that list does not mean no one will ever try it, so it is a reason to update now rather than a reason to wait.

The severity score works the same way. A CVSS score of 8.8 describes how bad the flaw could be under a standard scoring method. It does not measure whether attackers are using it. Your action does not change either way: update, then check your administrators.

How do you lower the risk of the next one?

This flaw needed three things: an out-of-date plugin, a logged-in user, and a powerful account. You can shrink each of those, and none of them requires new software. The changes below are small, and they help with the next plugin flaw, not only this one.

Keep fewer administrator accounts

Every administrator account is one more person whose click could act with full control of the site. Go through your administrator list and ask whether each person needs that level. Someone who only writes blog posts can be an Author or Editor. Someone who left the business should not have an account at all. The WordPress roles and capabilities page describes what each role can do, so you can match access to the work each person does.

A single brass key set apart from a small pile of spare keys on a plain wooden shelf.
Fewer full-access accounts means fewer clicks that can act with full control.

Make updates a habit, not a reaction

A regular update routine, whether that is auto-updates, a weekly check, or a website maintenance plan that includes tested updates, means the next fix goes in before the headline reaches you. Pair it with backups you have actually restored at least once, so an update that goes wrong costs you minutes instead of a day. Our earlier post on what to do when a WordPress plugin vulnerability warning appears covers the general routine for any plugin.

Log out when you are done

CSRF works on a live session. OWASP's CSRF prevention guidance notes that HTTPS alone does not stop it, because the request travels over your secure connection like any other. The site's software has to do the blocking, which is what 4.3.2 restores. On your side, logging out of the WordPress dashboard when you finish editing means a stray link opened later has no session to borrow.

Check what you know about the Elementor flaw

Pick an answer to begin.

1. Which Elementor versions are affected by this CSRF flaw?

2. What had to be true for a clicked link to create an admin account?

3. You find an administrator nobody created. What comes first?

Frequently Asked Questions About elementor vulnerability

Is Elementor 4.3.1 safe to keep running?

No. Elementor 4.3.0 and 4.3.1 are the affected versions. Update to 4.3.2 or later, which Patchstack lists as the fixed release.

What is the Elementor CSRF vulnerability?

It is a cross-site request forgery flaw, CVE-2026-62062 in Patchstack's record, that lets a crafted link make a logged-in user's browser carry out actions on the site that the user never intended, such as creating a new administrator.

Does this Elementor security update apply to Elementor Pro?

Patchstack's advisory names the free Elementor plugin and does not list Elementor Pro as affected. Keep Pro updated anyway; a separate Pro flaw fixed in version 4.2.2 was reported as exploited in September 2026.

Did the attacker get my password?

The flaw does not steal passwords. It borrows an open login session. Reset administrator passwords and log out all sessions anyway if you find an account you do not recognize.

How do I check for an Elementor admin account flaw on my site?

Open Users in your dashboard, filter to Administrator, and review every username, email and creation date, especially anything created on or after September 22, 2026.

Is the Elementor vulnerability being exploited?

No exploitation had been reported as of September 26, 2026. Patchstack expects it to be exploited, so update now rather than waiting.

What This Means for You

If your site runs Elementor, the job today is short: confirm the version, update to 4.3.2 or later, and read your administrator list for anyone you cannot explain. The danger from a clicked link depends on whether the person was logged in and what their account could do, which is why the admin check matters as much as the update. If everything checks out, write down what you looked at and when, and you are done.

The lasting win is a site where updates go in on schedule, only the people who need full control have it, and a backup is ready when something goes wrong. Next time a plugin headline lands, you will already know the steps and how long they take.

If you find an admin account nobody created, cannot update without breaking the site, or have no backups or logs to check, that is where we come in. At Web Leveling, our website security audit reviews your users, settings, plugins and logs, records what we find, and closes what needs closing. We work with small and medium businesses across the country and overseas. Tell us what you found in your Users list, and we will help you work out what it means.

Terms

Words from the Elementor flaw

Tap a term to see what it means.

Cross-site request forgery (CSRF). An attack that tricks a logged-in user's browser into sending a request the user did not intend.

CVE. A public identifier given to a known security flaw, such as CVE-2026-62062.

CVSS. A 0 to 10 severity score for a security flaw; it describes how bad a flaw could be, not whether it is being used.

REST API. The channel WordPress and its plugins use to take instructions, such as creating a user, from requests sent to the site.

Session. The logged-in state your browser keeps after you sign in, carried by a login cookie.

Administrator role. The WordPress role with full control of a site, including creating other users.

Known Exploited Vulnerabilities Catalog. CISA's public list of flaws with confirmed attacks.