Most security advice about links is really advice about where the link goes. The more interesting question is what happens when a link you click does something on a site you are already logged into. A flaw fixed in the Elementor page builder on 24 September 2026 is an unusually clean example, because a single link, opened by an administrator, was enough to create a second administrator account for whoever sent it. No password, no malware, no fake login page.
When you sign in to a website, your browser stores a cookie and sends it back automatically with every request to that site. That is what keeps you logged in as you move from page to page. The part people rarely think about is that the browser does this whether or not the request came from the site itself. A link in an email, an image tag on a forum, a form on somebody else’s page: if it points at a site you are signed in to, your browser attaches your session and the site sees a perfectly normal request from a logged-in user.
The site can tell who you are. What it cannot tell, on its own, is whether you meant it. That gap is cross-site request forgery. The attacker never sees your password and never sees the response. They simply borrow your authority for one request, and if that request changes something, the change is real.
The standard answer is a token: a short unpredictable value tied to your session, which the site puts into its own forms and links and then insists on seeing when the request comes back. An attacker composing a link from outside cannot guess it, so the forged request arrives without one and is rejected. WordPress calls these nonces, CubeCart and Magento call them tokens, and the principle is identical everywhere.
Two things follow from that, and they are the whole story of this vulnerability. The check has to run on every request that changes something. And the code deciding whether the check applies has to be exactly right, because deciding not to check is the same as having no protection at all.
Elementor is a page builder used on a very large number of WordPress sites. Recent versions include a small component that reports editor usage back to Elementor, and it has its own endpoint under the WordPress REST API. Because that endpoint is called in circumstances where the standard nonce is not available, the component asks WordPress to skip the usual REST authentication check for its own requests.
The bug was in how it recognised its own requests. It looked for the text elementor/v1/events/ anywhere in the address of the incoming request, and the address includes everything after the question mark. So a request to any other part of the REST API, with &anything=elementor/v1/events/ tacked on the end, matched. The nonce check was then skipped, and because that decision is made before WordPress works out which endpoint was actually being called, it was skipped for the entire REST API: WordPress’s own endpoints, and every other plugin’s.
One further detail turns this from a theoretical bypass into a link you can put in an email. WordPress accepts a _method parameter that overrides the type of request, so an ordinary click, which is a GET, can be treated as the POST that creates something. Everything the attack needs therefore fits in a single web address, with no JavaScript and no attacker-controlled page involved.
The result, on a site running an affected version, is that an administrator who clicks the link creates a new administrator account belonging to the attacker. The permission checks themselves still worked: a subscriber clicking the same link achieves nothing, because a subscriber cannot create users. What was lost was the proof that the administrator intended it.
The flaw is CVE-2026-62062, scored 8.8 out of 10. The affected releases are Elementor 4.3.0 and 4.3.1 only; the component involved does not exist in earlier versions, so a site on 4.2 or below was never exposed, and a site that has rolled back to 4.2 for unrelated reasons is not exposed either. Version 4.3.2 fixes it and was released on 24 September 2026. The corrected code asks WordPress which endpoint the request resolved to, rather than searching the raw address, and requires the match to be at the start rather than anywhere inside.
The window was genuinely narrow. Elementor 4.3.0 was released on 22 September, the researcher reported the problem the same day, and the fix shipped two days later. That is a good response, and it means only sites that updated promptly into 4.3.0 or 4.3.1 were ever affected. Two things are still worth knowing. Around two million sites were running one of those two versions when the details were published. And Elementor’s own changelog for 4.3.2 describes the fix as strengthened data handling security, with no mention of a vulnerability, so reading the release notes would not have told you this was urgent.
If you use Elementor, update it. That is the fix, and it is a two-minute job. If the site ran 4.3.0 or 4.3.1 at any point, it is worth also checking the things the flaw made possible:
/wp-json/ that also contain the text elementor/v1/events in the query string. A legitimate call to that endpoint has it in the path, not after a question mark, so anything matching in the query is worth reading closely.Finding nothing is the likely outcome. There are no reports of this being used against real sites, the affected versions were current for two days, and the attack needed a logged-in administrator to open a link. It is still a fifteen-minute check, and the alternative is finding out later.
Two lessons generalise well beyond this plugin.
The first is that a security check which decides whether it applies by looking for text inside a web address is fragile by design. The address contains a section the visitor writes, so any test that searches the whole of it can be satisfied by the visitor. The safe version asks the framework what the request resolved to after it has been parsed, and anchors the comparison rather than accepting a match anywhere.
The second is more uncomfortable, and it applies to every site with more than a couple of add-ons. This bug was in one plugin, but the protection it disabled was the platform’s, and the endpoints left unguarded belonged to everything installed. A plugin does not only bring its own risk. It can also switch off a defence that the rest of the site was relying on, and a security plugin hardening the same layer would have been bypassed along with it. That is the real argument for keeping the number of installed extensions small and the list of what is installed current, which is the same conclusion we reached from a very different kind of plugin flaw the week before.
Turn on automatic updates for Elementor and for anything else you can reasonably let update itself. This is a good illustration of why: the fix was out within two days of the report, and the entire value of that speed goes to sites that apply it. A site updating on a monthly cycle that happened to pick up 4.3.0 or 4.3.1 in the meantime would still be sitting on it now, weeks after the details became public, and the release notes would give it no reason to hurry.
Beyond this specific flaw, treat administrator accounts as the thing being protected. Most CSRF attacks are only interesting because someone with real privileges was signed in when the link was opened. Keep the number of administrators small, use author or editor roles for people who only publish, and avoid browsing the wider web in the same session where you are logged into the site’s back end. Passkeys and two-factor authentication do not help here, because the attacker is using a session you legitimately opened, which is a useful reminder that login security and session security are different problems.
If you host with us and you are not sure whether a site runs Elementor, or which version, open a ticket and we will check it and update it for you. The same goes for the user-list and log checks above. We are also happy to talk through which of your plugins genuinely need to be installed, which is the cheapest security work available to most sites. Our article on the website security measures that actually matter covers the rest of the ground, and the WordPress core flaw from the same fortnight makes the case for updating quickly rather than on a schedule.