One click, one new administrator: the Elementor CSRF flaw explained

If you run a WordPress site, or your business does, and it uses Elementor, stop reading and check the plugin version. If it says 4.3.0 or 4.3.1, update it to 4.3.2 now, then come back. The rest of this article will still be here, and the link in the email your marketing manager has just been sent will not wait.

Elementor is the most widely used page builder in the WordPress ecosystem, active on more than ten million sites. On 25 September Patchstack published details of a cross-site request forgery flaw in the two most recent releases, 4.3.0 and 4.3.1, which between them were running on around two million of those sites. The flaw carries a CVSS score of 8.8. It had not, at the time of writing, been assigned a CVE identifier, which is worth knowing because anyone searching a vulnerability database by CVE number will not find it. BleepingComputer and The Hacker News both covered it. The researcher who found it goes by Saggre and reported it through Patchstack on 22 September; Elementor shipped the fix in 4.3.2 on the 24th, which is a creditable turnaround of two days.

What the flaw lets an attacker do

The short version is this. An attacker who cannot log in to your site at all prepares a web address that points at your own site. They put it in front of one of your administrators, in an email, a chat message, a support ticket, or a comment on the site itself. The administrator, who is logged in to WordPress in the same browser, as administrators usually are, clicks it. Their browser sends the request to the site with their session cookie attached, and the site, believing the administrator intended the action, carries out a privileged operation on the attacker's behalf, the headline example being the creation of a second administrator account under the attacker's control.

From that point the attacker owns the site: its content, its plugins, its uploads, the ability to install a web shell, the customer data held in any form plugin or shop, and the ability to serve malware to every visitor. A page builder flaw becomes a full site compromise.

What makes this one unusually dangerous is how little the attacker needs from the victim. Most cross-site request forgery attacks require the victim to land on a booby-trapped page that then submits a hidden form or runs a script, which gives mail filters and browsers something to catch. This one does not. The bait is a single ordinary link that works as a plain anchor in an email client, a messaging app, or a WordPress comment. There is nothing for a sandbox to detonate and nothing for a browser to warn about, because the destination is the victim's own trusted website.

How it works, at the level that matters for defence

The mechanism is worth understanding because it explains both why the bug slipped through review and what to look for in your logs. I will describe it in terms of the defect, not as a recipe.

WordPress exposes a REST API under /wp-json/. When a request to that API arrives carrying a logged-in user's cookie, WordPress does not trust the cookie on its own. It also demands a nonce, a short-lived token proving the request originated from a page WordPress itself served to that user. That nonce check, performed by a core function called rest_cookie_check_errors(), is the single control that stands between a logged-in administrator's browser and any action the REST API can perform. It is precisely what makes an unsolicited link harmless: follow a link straight to a user-creation endpoint and WordPress recognises that the administrator never asked for it and refuses.

Elementor's Events Manager module introduced an exemption to that check for its own internal API route, so that its own legitimate traffic would not be blocked. The defect was in how the exemption decided whether a request belonged to Elementor. Instead of inspecting the route WordPress had actually resolved the request to, the code inspected the raw request URI as a string, and treated the request as Elementor's own if that string merely contained the plugin's route somewhere within it. Because the raw URI includes the query string, any request at all could make itself look like Elementor's traffic by carrying the plugin's route fragment as an incidental-looking query parameter. Having decided the request was its own, the module told WordPress that authentication was satisfied, and the core nonce check was skipped. The capability check, which asks whether the user is allowed to do the thing, remained in place, but it had become meaningless: the victim genuinely is an administrator, so the only real protection was the intent check that had just been bypassed.

Two implementation details compounded it. WordPress supports overriding the HTTP method of a request through a parameter, so a request that looks like a harmless read can be turned into a write. And the vulnerable check ran at the earliest possible priority, so its verdict was the one that stuck. The corrected code in 4.3.2 inspects the resolved route rather than the raw URI, anchors the comparison to the start of the route rather than looking for it anywhere in the string, and validates the type of the value it is testing. It is a small patch, and a good illustration of a general truth: security checks must key on what the framework decided to do, never on the attacker-supplied text that arrived at the door.

Why "no CVE yet" is not "no urgency"

It is tempting to wait for a CVE and a tidy entry in the National Vulnerability Database before acting. Do not. The absence of a CVE identifier here reflects the pace of disclosure, not the absence of risk, and the enrichment feeds that many security tools rely on will be blind to a vulnerability they cannot key by CVE number. This is a recurring gap: the sites most exposed to a plugin flaw are small business sites with no security monitoring at all, and they are also the ones least likely to be watching an advisory feed. The window between a public advisory and opportunistic mass scanning is now measured in hours.

We have seen exactly that this same week with an unrelated but instructive case, a critical WordPress core vulnerability, CVE-2026-87902, where Patchstack recorded probing beginning the same day the patch shipped and traffic rising more than tenfold the following day as attackers worked straight from the patch diff. That flaw is on the CISA Known Exploited Vulnerabilities list. The Elementor flaw is a softer target in one sense, because it needs an administrator to click, and a harder one in another, because clicking a link is a thing administrators do all day. Treat the timeline as hours, not weeks.

What to do this morning

The priority order is short and unglamorous.

Update Elementor to 4.3.2 or later on every site you run. If you manage sites for clients, this is a same-day job across the estate, not a scheduled-maintenance item. Where you genuinely cannot update immediately, Patchstack has issued a virtual-patch rule for the flaw, and a web application firewall in front of the site can enforce it in the interim, but this is a holding measure and not a substitute for the update.

Then assume, rather than hope, that the click may already have happened, and go looking. Review the site's user list for any administrator account you cannot account for, paying attention to accounts created in the days since 22 September. Check that the total number of administrators matches what you expect. Review recently installed or modified plugins and any new files in the uploads directory, which is where a web shell most often lands. If you find an unexpected administrator, treat it as a full compromise: the account is the symptom, not the disease, and by the time it exists the attacker has had the run of the site.

Two hardening measures make the next one of these far less painful. Keep the number of standing administrator accounts to the minimum, because every administrator is a person whose single click is enough. And separate content editing from site administration: the people who use Elementor day to day rarely need the administrator role, and an editor who clicks the same link cannot be turned into an administrator by it.

Seeing it in the logs: Wazuh detection

Our SOC runs Wazuh across client estates, and for advisory-driven flaws like this we write detections rather than wait for a signature to arrive. Two behaviours give this attack away in web server logs, and both are things a normal site almost never does.

The first is the bypass fingerprint: a request to a WordPress REST endpoint that carries Elementor's Events Manager route as a query-string parameter rather than as the actual path. Legitimate Elementor traffic reaches that route as its path; a request that names the route in the query string while addressing a different endpoint is the shape of the bypass. The second is the outcome: a request that results in the creation of a user, or a privileged account change, arriving at the REST user endpoint. On most sites, administrators are created a handful of times in a site's whole life, so alerting on every such event costs nothing and catches the thing that actually hurts.

Assuming Apache access logs are being read into Wazuh through the standard decoders, a local ruleset along these lines flags both. Tune the IDs to your own range; ours sit in the 150000 block alongside the rest of our web rules.

<group name="web,attack,wordpress,elementor,">

  <!-- Base: a request to the WordPress REST API -->
  <rule id="151900" level="0">
    <decoded_as>web-accesslog</decoded_as>
    <url>/wp-json/</url>
    <description>WordPress REST API request (base rule for correlation)</description>
  </rule>

  <!-- The bypass fingerprint: Elementor's events route appearing in the
       query string of a request whose path is something else entirely -->
  <rule id="151901" level="12">
    <if_sid>151900</if_sid>
    <url type="pcre2">\?[^ ]*elementor/v1/events/</url>
    <description>Elementor CSRF bypass attempt: events route passed as a query parameter on a REST request</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>elementor_csrf,pci_dss_6.5.9,</group>
  </rule>

  <!-- The outcome: a write to the REST user-creation endpoint. On a
       stable site this is rare enough to alert on every time -->
  <rule id="151902" level="10">
    <if_sid>151900</if_sid>
    <url type="pcre2">/wp-json/wp/v2/users</url>
    <regex type="pcre2">"(POST|PUT) |_method=(POST|PUT)</regex>
    <description>WordPress REST API request to create or modify a user account</description>
    <mitre>
      <id>T1136.001</id>
    </mitre>
    <group>wordpress_user_create,</group>
  </rule>

  <!-- Correlation: the bypass fingerprint and a user-write from the same
       source in quick succession is a takeover attempt in progress -->
  <rule id="151903" level="14" frequency="2" timeframe="120">
    <if_matched_sid>151901</if_matched_sid>
    <same_source_ip />
    <description>Elementor CSRF site takeover in progress: bypass attempt followed by a user-account write from the same source</description>
    <group>elementor_csrf,attack_success,</group>
  </rule>

</group>

The base rule is silent; rule 151901 fires on the bypass fingerprint at high severity; rule 151902 fires whenever the user endpoint is written to at all, which is the event you want to know about regardless of cause; and rule 151903 raises the roof if it sees both from one source inside two minutes. The response rule you attach to 151903 is a matter of your own risk appetite, but for a WordPress site behind our platform it is the sort of high-confidence signal that can justify pre-authorised containment.

If you would rather not run WordPress detection yourself, this is the daily work of a managed SOC: SOC365 watches advisory feeds, writes detections like these the day a flaw is disclosed, and puts them across every client estate before the scanning starts. There is a broader point in that, which we made in our piece on why an AI SOC lets owners sleep: the value is not the rule, it is that the rule is written and deployed while you are asleep.

The wider lesson

This is not really a story about Elementor, which found itself with a subtle bug, was told about it responsibly and fixed it in two days. It is a story about the plugin as a supply chain, a theme we have returned to more than once this month. A WordPress site is rarely one piece of software; it is a core, a theme and a dozen plugins, each written by a different team, each able to add its own routes and its own exemptions to the security controls of the whole. Every plugin you install is a supplier you have taken on, with the standing to weaken the site's defences in ways you will never review. The defensive posture that follows is the same one we have argued for all month: know what you have installed, keep it patched the day a fix appears, reduce the standing privilege that a single mistake can hand over, and watch the logs so that when a click does land, you find out in minutes rather than when your visitors start being redirected to a malware page. That is a considerably better morning than the alternative.

Frequently asked questions

Which versions of Elementor are affected, and what is the fix? Only versions 4.3.0 and 4.3.1. The fix is version 4.3.2, released on 24 September 2026. If you are on an older 4.x release you were not affected by this particular flaw, but you should be current regardless.

Is my site affected if I never click suspicious links? The risk is not limited to you. Any administrator on the site can trigger it by clicking a crafted link, and the link can arrive through a site comment or a support enquiry, not only email. The safe assumption is that at least one administrator will click at least one link, which is why the update rather than user caution is the control that matters.

There is no CVE number. How do I track it? It is tracked through Patchstack's own vulnerability database as an Elementor cross-site request forgery to privilege escalation, CVSS 8.8. A CVE identifier may be assigned later. Do not treat the absence of a CVE as a reason to wait, and be aware that CVE-keyed scanners and feeds may not flag it.

How do I tell whether I have already been hit? Look for administrator accounts you do not recognise, especially any created since 22 September; check that your administrator count is what you expect; and review recently added plugins and any unexpected files in the uploads directory. If you find an unexplained administrator, treat the whole site as compromised and move to incident response rather than simply deleting the account.

We manage dozens of client WordPress sites. What is the right process? Update every site to 4.3.2 today, in priority order by exposure and value, rather than waiting for a maintenance window. Where an update genuinely cannot be applied at once, put a virtual patch or WAF rule in front of the site as a temporary measure. Then run the compromise checks above across the estate, and put detection in place so the next plugin flaw is caught by a rule rather than by a customer. If that is more than your team can carry, it is exactly what a managed SOC is for.