How Securitycheck Pro blocked the Elementor rogue-admin CSRF (v4.3.0 – 4.3.1)

TL;DR - A cross-site request forgery (CSRF) flaw in the Elementor page builder (versions 4.3.0 and 4.3.1, patched in 4.3.2) lets an attacker create a full administrator account just by getting a logged-in admin to open a crafted link. No form, no JavaScript, no attacker-controlled site is required. Elementor is installed on roughly 10 million sites, and the vulnerable branch was running on up to 2 million of them. We reproduced the attack in our lab against a stock WordPress install with Elementor 4.3.1, and Securitycheck Pro's Forbid new admin accounts protection detected the unauthorized administrator the moment it appeared and removed it automatically. Here is exactly what happened and why layered protection matters.

What is the Elementor CSRF flaw?

• Affected software: Elementor (free) page builder
• Affected versions: 4.3.0 and 4.3.1 only
• Fixed in: 4.3.2
• Class: CSRF (Cross-Site Request Forgery) leading to unauthenticated privilege escalation / rogue administrator creation
• Prerequisite: a logged-in administrator (or another high-privilege user) opens a crafted link
• Reported by: researcher "Saggre" via Patchstack (22 Sep 2026); patched two days later

In plain language: WordPress protects state-changing REST requests with a nonce - a one-time token that proves the request really came from one of your own admin pages and not from an external link or site. That nonce is what normally makes CSRF impossible. The vulnerable versions of Elementor shipped an Editor Events module that inspected the raw request URI and, whenever it saw the string elementor/v1/events/ anywhere in it, treated the request as its own internal event and skipped WordPress's REST nonce validation.

That single shortcut is the whole problem. If an attacker can make the nonce check disappear, then any request the victim's browser sends while logged in - including a request that creates a new user - is accepted as genuine.

How the attack works (at a high level)

1. The attacker crafts a link that points at a WordPress REST endpoint capable of creating users, and appends the magic elementor/v1/events/ path so Elementor waves the request through without a nonce.
2. Because a browser will happily turn a GET link into the intended write via a method-override parameter, the payload can travel as a plain clickable URL. Illustrative shape (parameters trimmed on purpose):
   Code:

   /wp-json/wp/v2/users?_method=POST&username=...&roles=administrator&x=elementor/v1/events/
3. The attacker delivers that link where an administrator will click it - an email, a chat message, a "contact us" reply, even a comment on the site.
4. The admin clicks. Their browser sends the request with their valid session cookies. Elementor skips the nonce check, WordPress creates the account, and the attacker now owns an administrator login on the site.

What makes this one nasty is how little the attacker needs. There is no malicious page to host, no JavaScript to run, no form to submit. A link in a message is enough, and the victim never sees anything happen.

What we observed in our lab

We built a clean WordPress site on an isolated VM, installed Elementor 4.3.1, and enabled Securitycheck Pro's Forbid new admin accounts protection. We then reproduced the exact effect of the flaw - a request that creates an administrator account named csrfadmin - against the site, exactly as a clicked link would.

The account was created for a fraction of a second, because the vulnerability lives inside Elementor and bypasses WordPress's own nonce defense before Securitycheck Pro's request filters ever get a vote. But that is not where the story ends. Securitycheck Pro keeps a baseline of every legitimate administrator on the site. The instant an administrator appears that is not on that list, it is treated as hostile: the account is deleted, the event is written to the firewall log, and any admin currently in the dashboard sees a red warning.  
In the WordPress dashboard the message is blunt and reassuring at the same time: "User deleted due to a Securitycheck Pro directive." The attacker's foothold is gone before it can be used.

Two layers of protection, not one

This incident is a good illustration of why we do not rely on a single wall.

• Proactive request filtering (reduces the odds): Securitycheck Pro inspects incoming requests - including the REST API body - and validates the Origin, Referer and Sec-Fetch-Site headers on state-changing calls, so a request forged from an external link does not look like it came from your own dashboard. This raises the bar for the classic CSRF delivery vector.
• Outcome monitoring (catches what slips through): when a flaw lives inside another plugin and defeats WordPress's own nonce check - as this one does - the malicious request can still look legitimate. So we also watch the result that attackers actually want: a new administrator. Forbid new admin accounts guarantees that an admin account created outside your control does not survive.

    Why this matters even if you run a security plugin

A firewall is your brakes, not your seatbelt. It lets you keep moving safely, but it is not a reason to drive into a wall. Securitycheck Pro removed the rogue admin in our test, but the correct fix for this specific flaw is to update Elementor to 4.3.2 or later. Security tooling buys you time and catches the attacks you did not patch in time - it is not a licence to run vulnerable code forever. Run both: patch fast, and keep a net underneath for the day a zero-day beats you to it.

What you should do right now

1. Update Elementor to 4.3.2 or newer on every site you manage. This is the definitive fix.
2. If you cannot patch immediately, enable Forbid new admin accounts in Securitycheck Pro so any unauthorized administrator is removed automatically.
3. Audit your administrators now (Users -> All Users -> Administrator). Remove any account you do not recognise, and check the registration dates.
4. Rotate credentials for legitimate admins and force a re-login if you suspect the flaw was triggered on your site.
5. Review your logs for requests to REST user endpoints that also contain the string elementor/v1/events/.
6. Restrict user enumeration - the /wp-json/wp/v2/users endpoint hands out usernames to anyone by default, which is exactly the reconnaissance an attacker needs.
7. Train the humans. This attack is a link in a message. Remind admins not to click links to their own site from untrusted messages while logged in.
8. Keep a security scanner running with outcome-based protections enabled, not just signature matching.

Indicators to look for

• An administrator account you did not create, especially one added recently.
• Requests in your access logs to /wp-json/wp/v2/users (or ?rest_route=/wp/v2/users) that also carry elementor/v1/events/ or a _method=POST parameter.
• A Securitycheck Pro log entry under Session Protection reading "User deleted".
• Password-reset or new-user notification emails that nobody on your team requested.

References

• BleepingComputer - Elementor WordPress flaw lets attackers create admin accounts
• The Hacker News - Elementor CSRF flaw lets attackers take over sites after admin clicks crafted link
• Patchstack advisory & technical write-up (Elementor 4.3.0/4.3.1 CSRF, REST nonce bypass)
• Elementor changelog - 4.3.2 security release