Elementor has shipped 4.3.2 to fix a cross site request forgery flaw rated 8.8 on the CVSS scale. If a logged in administrator clicks a crafted link while the vulnerable version is active, an attacker can make that administrator’s browser perform REST API actions on their behalf, including creating a new admin account. Only sites running Elementor 4.3.0 or 4.3.1 are affected, which still covers a very large number of installs given how quickly Elementor updates propagate.
What the flaw actually does
Patchstack published the advisory on 25 September 2026, crediting the researcher Saggre, in its write up of the cross site request forgery issue in Elementor. The root cause is a route check that was too loose. Elementor’s code looked for its own REST routes by searching the request URI for a matching substring, and the request URI includes the query string, which an attacker controls. Append the right text to a URL and a request that was never an Elementor route gets treated as one, and the nonce protection that WordPress would normally apply is bypassed.
The practical effect is privilege escalation without any authentication of the attacker’s own. The payload is a plain link. It needs no JavaScript, no form submission and no cross site scripting foothold. It can arrive in an email, a contract enquiry through your own site, a Slack message or a comment notification. The victim is the logged in user, and whatever their account can do through the REST API, the attacker can do.
Which versions are affected
The vulnerable range is narrow: 4.3.0 and 4.3.1. The fix is in 4.3.2. Anything older than 4.3.0 does not carry this particular bug, though an older Elementor will almost certainly carry others, so that is not a reason to sit still. The fix changes the check to validate the route WordPress has already resolved, rather than inspecting raw request text, which is the correct way to do it.
Because the affected range is only two releases, the sites most at risk are the well maintained ones that updated promptly to 4.3.0 or 4.3.1 and then paused. It is worth saying plainly to clients who assume a recent version number means a safe one.
How to check your own site
In wp-admin, go to Plugins and read the version next to Elementor. If it starts 4.3.0 or 4.3.1, update today. If you manage more than a handful of sites, WP-CLI is faster:
wp plugin get elementor --field=version
wp plugin update elementor --version=4.3.2Run the first command across your estate before you touch anything, so you have a record of which sites were exposed and for how long.
What to look for if you were running a vulnerable version
A successful attack leaves traces in the places you would expect. Check Users in wp-admin for accounts you do not recognise, particularly administrators created in the last fortnight, and sort by registration date rather than scanning the first page. Check Users for role changes on existing accounts. Check Settings, General for an altered admin email address, which is a common follow up step because it intercepts password resets. Check for unexpected plugins or must use plugins in wp-content/mu-plugins, and compare file modification dates under wp-content against your last deployment.
If anything looks wrong, treat it as a compromise rather than a curiosity: rotate all administrator passwords and application passwords, and rotate the salts in wp-config.php so existing login cookies stop working.
What to do if you cannot update immediately
Sometimes an update is genuinely blocked by a heavily customised build or an approval process that takes a few days. In that case reduce the blast radius. Cut the number of accounts holding the administrator role, since this flaw only grants what the victim’s account already has, and ask the people who do hold it to use a separate browser profile for wp-admin so a link opened from email is not opened in a logged in session.
None of that is a substitute for the patch. It buys hours, not weeks. Our WordPress maintenance work in Manchester exists largely because this cycle repeats every few weeks and someone has to own it.
The wider pattern this week
This is the second serious WordPress ecosystem issue in a fortnight. WordPress 7.1.2 shipped on 22 September 2026 to fix an unauthenticated path traversal leading to local file inclusion and, in some configurations, remote code execution. Patchstack reported the first exploitation attempts against its firewall at 11:49 UTC on the same day the patch was published, with volume rising more than tenfold inside 24 hours and a public scanning template circulating by day two.
The lesson is about time, not severity. The gap between a patch being public and the internet scanning for it is now measured in hours, which changes what a sensible update policy looks like: automatic updates for security releases, weekly rather than monthly review for everything else, and a tested rollback path so updating quickly is not frightening. If PHP support is also on your list, our note on WooCommerce moving to PHP 8.1 covers the other half of the same housekeeping job.
Getting someone to own this
Most sites that get hit are not badly built. They are unattended. If nobody is reading advisories on your behalf and acting on them within the day, that is the gap worth closing, and it is cheaper than the clean up. If you want a developer who handles this properly, get in touch with Strand Creative and we will take it off your desk.
FAQ
Was my site hacked if I was running Elementor 4.3.1?
Not necessarily. The flaw needs a logged in user with sufficient permissions to open an attacker’s link while the vulnerable version is active. Many sites were exposed and never targeted. Update to 4.3.2, then check your user list for unfamiliar administrator accounts and your admin email address for changes. If both look normal and your logs show nothing unusual, the realistic answer is that you were fine.
Do I need Elementor Pro updated as well, or just the free plugin?
This advisory concerns the main Elementor plugin, so 4.3.2 is the version to reach. In practice Pro and the free plugin are version matched in their major lines and expect to run together, so update both and clear your caches afterwards. Running a current free plugin against an old Pro build is a reliable way to create layout problems that look like a hack but are not.
Can a firewall protect me instead of updating?
A virtual patch from a reputable firewall can block known exploit shapes and is useful while you schedule the real fix. It is not equivalent protection, because it depends on a signature matching what the attacker actually sends. Treat it as cover for a day or two during a release freeze, never as a permanent answer. The patched plugin removes the flaw, a rule only hides it.
How quickly should security updates be applied on our site?
For plugin and core security releases, the same working day. Exploitation now begins within hours of a patch becoming public, as the WordPress 7.1.2 case showed in September. Enable automatic updates for security releases, keep a recent off server backup and a rehearsed rollback, and reserve manual review for feature releases where a visual regression is the real risk.
We use Divi or Salient rather than Elementor. Does this affect us?
Not this specific flaw, which is in Elementor’s own REST route handling. The underlying pattern, a permission check that trusts part of the request it should not, appears across the plugin ecosystem, so the housekeeping is the same. Know which page builder version each site runs, subscribe to advisories for the plugins you actually use, and act on them the day they land.
Photo by Towfiqu barbhuiya on Unsplash
