Elementor CSRF bug: one link turns an admin click into a new admin

The Elementor CSRF vulnerability disclosed this week is a five-line mistake with a two-million-site blast radius. A logged-in administrator clicks one link in an email and an attacker-controlled admin account appears on the site. No JavaScript, no malicious page to host, no form to submit. The root cause is a substring check on a URL, and it is a pattern worth grepping your own codebase for today.

What actually happened

Patchstack reported the flaw, found by a researcher going by Saggre. Elementor's Editor Events module skipped nonce validation for cookie-authenticated REST requests whenever the literal string elementor/v1/events/ appeared anywhere in the request URI. The request URI includes the query string.

That is the whole bug. Any REST request could opt itself out of CSRF protection by appending a harmless-looking query parameter containing that string. The bypass was not scoped to Elementor's own endpoints — it applied to the site's entire REST API surface, including WordPress core routes and the routes of every other installed plugin. Point it at the user-creation route and you have an administrator.

The numbers: CVSS 8.8, affecting Elementor 4.3.0 and 4.3.1, with up to 2 million sites on a vulnerable version. Reported to Elementor on September 22, fixed in 4.3.2 on September 24, public on September 25. No CVE was assigned at disclosure. The delivery vector is anything that renders a link — email, chat, or a comment on the site itself. Two days from report to patch is a good response; the exposure window that matters now is how long your sites sit unpatched.

Why a substring check matters for your business

Update Elementor to 4.3.2 now, then check for unexpected admins. Go to Users, filter by Administrator, and look at registration dates against your own records. Rotate credentials for anything you do not recognize, and check for new plugin files while you are in there. A CSRF that creates accounts leaves a visible artifact — go look for it.

strpos is not authorization. Matching a string against a full request URI to make a security decision is the failure here, and it generalizes to every framework. Compare the routed path to an exact allowlist, after your router has parsed it and stripped the query string. If your middleware makes any decision from $_SERVER['REQUEST_URI'], that decision is attacker-influenced.

Exemptions default to the widest scope unless you force them narrow. The reason this became a whole-API bypass rather than a module bug is that the check ran early and globally. When we write a security exemption, it names the exact route and the exact method, and it lives next to the route definition — never in a global filter that inspects strings. One page builder should not be able to switch off protection for WordPress core.

Your CMS plugin count is your real attack surface. We build commerce and marketing sites where the page builder cannot reach the checkout or the customer records, because those live in a separate service with its own auth. If a WordPress plugin compromise means an attacker owns your orders, the architecture is the problem and the next plugin CVE is just the trigger.

Sources: Patchstack, BleepingComputer.