Elementor CSRF Flaw Lets Attackers Take Over Sites After Admin Clicks Crafted Link
- ID
- 28873
- Status
- summarized
- Published
- 26 Sep 2026, 5:55 PM
- Fetched
- 26 Sep 2026, 7:09 PM
- Provider
- The Hacker News
- Category
- security
- Original URL
- https://thehackernews.com/2026/09/elementor-csrf-flaw-lets-attackers-take.html
- Source URL
- https://feeds.feedburner.com/TheHackersNews
Summary
- Score
- 8.0
- Created
- 26 Sep 2026, 7:10 PM
- Tags
- Audience
- developersvibe_codersstartup_founders
What happened
Elementor versions 4.3.0 and 4.3.1 carry an unauthenticated CSRF flaw (CVSS 8.8, no CVE assigned yet) that lets an attacker create a rogue administrator account when a logged-in WordPress user simply opens a crafted link. Patchstack traced the cause to the Editor Events module skipping CSRF protection for cookie-authenticated REST API requests whenever the literal string "elementor/v1/events/" appears anywhere in the request URI, including the query string, so appending a harmless-looking parameter such as x=elementor/v1/events/ disables protection for the entire REST API surface. The plugin is active on over 10 million WordPress sites, the two affected versions alone account for more than 2 million installs, and the issue was fixed in version 4.3.2 released earlier this week; researcher "Saggre" is credited with reporting it.
Why it matters
If you or a client run Elementor, check the version now and move to 4.3.2: anything still on 4.3.0 or 4.3.1 exposes the full REST API, including core routes like /wp/v2/users, so a single admin click on an anchor tag in an email, chat message, or comment is enough to mint a second administrator account for the attacker. The exploit needs no JavaScript, no form submission, and no attacker-controlled page, which means the usual 'don't visit sketchy sites' advice does not apply. While you wait for the update, restrict who has admin sessions and treat any unexpected administrator account as a live compromise rather than a glitch.
Discussion angle
The root cause is a substring match on the raw request URI, query string included, used as a CSRF exemption: what other plugins or internal APIs in your stack make an authorization decision by grepping the URL instead of parsing it, and how would you detect that pattern in a code review?