On this page (7 sections)

Patchstack has published research on a Cross-Site Request Forgery (CSRF) weakness in the Elementor Website Builder plugin. According to Patchstack, a single link opened by a logged-in WordPress user makes that user perform any REST API action their account is allowed to perform. On a stock installation, an administrator who clicks it creates a second administrator account for the attacker.

If you run WordPress with Elementor, or manage sites for clients who do, check which Elementor version is installed. Patchstack says only releases 4.3.0 and 4.3.1 are affected. The research available to us does not name a fixed version or a CVE identifier, so this article avoids guessing at either.

What happened

Patchstack's Security Research Lead, Dave Jong, describes the issue as an unauthenticated Cross-Site Request Forgery that leads to privilege escalation. The flaw was reported to Patchstack by a researcher credited as Saggre. Patchstack says it has issued mitigation rules for its own users. Only one independent publisher covers this story so far, so the technical details below rest on that single primary write-up, and we have not seen a vendor advisory or CVE record.

The attack needs very little from the victim. Per Patchstack, the link needs no JavaScript, no form and no page controlled by the attacker, and it can be delivered as a plain anchor in an email, chat message or comment.

Why this works: a CSRF check that gets skipped

WordPress protects cookie-authenticated REST API requests with a nonce, a token that proves the request came from a page the user was actually on. Without it, a browser would happily attach your login cookie to a request triggered from anywhere.

Patchstack explains that in 4.3.0 and 4.3.1 an Elementor module called Editor Events, which proxies the editor's telemetry, registers a hook that skips this nonce check for its own routes. The hook runs before WordPress has matched a route, so it only has the raw request URI to look at. It tests whether the text elementor/v1/events/ appears anywhere in that URI. Because the URI includes the query string, which is written by whoever composes the link, any REST request can add that text as a harmless-looking parameter and be exempted from the protection.

In short, the weakness class is an overly loose string match used as a security decision. The check was meant to identify Elementor's own endpoints but matched attacker-controlled text instead.

Why default installs are affected

Patchstack reports that the module sits behind a hidden experiment that does not appear on Elementor's Experiments screen. It is switched on by default for sites whose first Elementor installation was version 3.32.0 or later. Patchstack also notes that the module's constructor registers the filter unconditionally, so the module simply being loaded is enough, and telemetry settings do not prevent it. A default install of 4.3.0 or 4.3.1 with no other plugins is affected, according to the write-up.

Who is realistically exposed

  • Sites running exactly Elementor 4.3.0 or 4.3.1. Earlier releases are described as unaffected.
  • Sites where administrators, editors or shop managers read email, chat or comments while logged in to WordPress. The attack depends on a logged-in user opening a link.
  • Agencies and hosts managing many sites, where one forgotten site on an affected release is enough.
  • The impact scales with the clicker's role: the link carries out whatever REST actions that account is permitted to do, so an administrator is the worst case.
Patchstack's headline refers to 2 million+ sites, while its text describes Elementor as active on over ten million sites overall. The share of sites actually running 4.3.0 or 4.3.1 is not given in the research, so do not assume every Elementor site is affected.

How to check your exposure

First, find out which Elementor version each site runs. This read-only WP-CLI command lists the installed version of the plugin; run it from the WordPress root on the server. You are looking for 4.3.0 or 4.3.1 in the version column.

List the installed Elementor version (run in the WordPress root)WP-CLI
wp plugin list --name=elementor --fields=name,status,version

To review all plugins on one site in a single pass, use the same listing without the name filter and look for the elementor row. Repeat it per site if a server hosts several.

List all plugins with versions (read-only)WP-CLI
wp plugin list --fields=name,status,version

Next, look for administrator accounts you do not recognize. This read-only command lists all users with the administrator role; compare the result against the people who should have access, paying attention to recent registration dates.

List administrator accounts (read-only)WP-CLI
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

What to do now

Because the research does not state a fixed release, rely on the plugin's own update channel and Elementor's release notes to confirm which version resolves the issue. Moving off 4.3.0 and 4.3.1 is the clear goal, since Patchstack says earlier releases do not contain the vulnerable proxy.

Caution. Back up the site and test on staging before updating or rolling back a page builder. Changing Elementor versions on a live site can affect page layouts. Confirm the exact target version in Elementor's official release notes first.

If you find an unexpected administrator, treat the site as potentially compromised and follow our guide on what to do when a website is hacked. For broader hardening such as limiting administrator accounts, see our WordPress security checklist.

Detection and monitoring afterwards

  • Watch for new user registrations with the administrator role, and alert on role changes.
  • Review web server logs for REST API requests (paths containing wp-json) that include the text elementor/v1/events/ in the query string rather than in the path. Unusual query-string occurrences deserve a look.
  • Keep a short list of plugin versions per site and re-check it after every update cycle. Our guide on checking whether a WordPress plugin is vulnerable walks through this.
  • Schedule regular read-only scans of your verified sites with Webforta Scan so changes you did not expect are easier to spot. This helps with visibility but does not replace patching.

This read-only grep searches an nginx access log for the endpoint text appearing anywhere in a request line. Run it on the server and adjust the log path to your setup (Apache and other servers log elsewhere).

Search an nginx access log for the endpoint text (read-only; adjust the log path)Shell
grep -i 'elementor/v1/events/' /var/log/nginx/access.log

Matches are not proof of abuse, because the plugin itself may use that route in normal operation. Look specifically for requests where the text appears after a question mark and the path points at a different REST route.

What we do not know yet

  • No CVE identifier appears in the research we reviewed.
  • The fixed version is not stated in the available text of the Patchstack post.
  • There is no report of exploitation in the wild in the source we have, so treat exploitation status as unconfirmed.
  • Only one publisher has covered this so far, and no vendor advisory was available to us. We will treat details as provisional until Elementor or a CVE record confirms them.

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

  1. Cross-Site Request Forgery in Elementor Plugin Affecting 2 Million+ Sites - Patchstackpatchstack.com ·
  • Elementor
  • WordPress
  • CSRF
  • Privilege escalation
  • REST API