NEWS · SEPTEMBER 27, 2026 · SECURITY

The CSRF flaw in Elementor 4.3.0 and 4.3.1 lets a single link hand an attacker an admin account

On September 25, 2026 the security company Patchstack disclosed a cross-site request forgery (CSRF) flaw in WordPress's Elementor Website Builder plugin that affects only versions 4.3.0 and 4.3.1. On a default installation, a logged-in administrator opening one link is enough to create a second administrator account for the attacker. Elementor fixed it in version 4.3.2, released on September 24.

01 · WHAT HAPPENED?

Patchstack's advisory: CVSS 8.8, fixed in 4.3.2

The advisory was published on September 25, 2026 under the name of Dave Jong, Security Research Lead at Patchstack. Patchstack lists the issue as an unauthenticated cross-site request forgery that leads to privilege escalation and scores it 8.8 on CVSS. A researcher going by Saggre discovered the flaw and reported it to Patchstack. Patchstack's timeline has the report arriving on September 22, Elementor releasing version 4.3.2 on September 24 and the advisory going public on September 25.

Only two releases are affected. The changelog on WordPress.org dates 4.3.0 to September 22, 4.3.1 to September 23 and 4.3.2 to September 24, and the 4.3.2 entry includes a fix line about improved code security enforcement in data handling. The plugin page shows Elementor at more than 10 million active installations. For the two affected versions, both outlets cite WordPress.org statistics: BleepingComputer says up to 2 million sites, The Hacker News more than 2 million, so roughly 2 million. Both reported that the flaw had yet to receive a CVE identifier when their stories ran.

02 · DETAILS

One string appended to the query does all the work

The bug sits in the Editor Events module, which proxies Elementor's editor telemetry. To exempt its own requests from WordPress's nonce check, the module hooks the rest_authentication_errors filter at priority 0 and returns true, meaning authentication has already succeeded, whenever the string elementor/v1/events/ appears anywhere in the request URI. That URI includes the query string, and the query string is written by whoever composes the link. According to Patchstack, appending a parameter such as ?zzz=elementor/v1/events/ to any REST request is enough to pass the check. When that happens, rest_cookie_check_errors(), the only CSRF protection WordPress core applies to cookie-authenticated REST requests, returns early without ever verifying the nonce, and security plugins that harden REST authentication through the same filter are skipped along with it.

No form or script is needed because WordPress core accepts a _method query parameter that overrides the HTTP verb, so a plain GET navigation can perform a write. In the researcher's test, the user-creation request returned HTTP 401 without the marker; with it, the server returned HTTP 201 and a user with the administrator role. Patchstack puts it plainly: "The link needs no JavaScript, no form, and no page under the attacker’s control." The link can travel as an ordinary anchor in an email, a chat message or a comment. Nor does the reach stop at Elementor. The bypass covers the REST endpoints of WordPress core and of every other installed plugin, and the researcher also showed GET /wp-json/wp/v2/settings, which returns the site settings, flipping from HTTP 401 to HTTP 200.

03 · WHY IT MATTERS

One administrator click can hand over control of the site

Two things make this serious. The first is how ordinary the trigger is: a logged-in user unknowingly performs any REST action their account is allowed to perform, and on a stock installation an administrator's click means a second administrator account for the attacker. The second is how invisible the module is. According to Patchstack, the Editor Events experiment is hidden from Elementor's Experiments screen and is on by default for every site whose first Elementor installation was 3.32.0 or later. A default 4.3.0 or 4.3.1 install with no settings changed is affected; the module merely being loaded is enough, and the site's telemetry settings do not prevent it.

The 4.3.2 fix moves the check from the raw URI to the route WordPress actually resolved and requires the namespace to sit at the very start of that route, with an extra guard for routes that are not strings. Releases before 4.3.0 do not ship the Editor Events proxy and are not affected by this flaw. BleepingComputer points out, however, that those older versions are vulnerable to other flaws, some of which are already actively exploited, so rolling back should not be treated as a safe exit. Patchstack's advice is direct: "We strongly recommend updating Elementor to version 4.3.2 or above." We covered a WordPress core security release in our September 19 piece on WordPress 7.1.1; this time the risk comes not from core but from a widely used plugin.

04 · TÜRKİYE

The sources carry nothing specific to Türkiye, so this section is commentary

None of the four sources contains information specific to Türkiye. The language list on the WordPress.org page (65 entries) includes Turkish, but that is not usage data. What follows is therefore not a fact drawn from the sources but explicitly UNALSOFT commentary.

Our reading: if the administrator account of a WordPress business site belongs to one person who also opens email and messages in the same browser, the trigger for this flaw is exactly the kind of plain link that person might click during the day. The unknowns deserve the same clarity. The sources do not include: the number of sites in Türkiye running 4.3.0 or 4.3.1, any local attack or incident report tied to this flaw, or a warning about it from an institution in Türkiye.

The UNALSOFT view

We read this as a question of maintenance discipline: installing a plugin is only the start, while knowing which version is running and applying updates within days is the actual work. The practical steps are simple: if your Elementor version is 4.3.0 or 4.3.1, update to 4.3.2 or above, then look through the Users screen for any administrator account you do not recognise. Having a security plugin installed is not a guarantee on its own, because this flaw also skips plugins that harden REST authentication through the same filter. That is why in our web design projects we treat plugin and user maintenance after handover as an integral part of the job.

Do you know which plugin versions your site is running?

A short conversation is enough to review your WordPress site's plugin versions and administrator accounts together.

Message on WhatsApp