A Hidden Elementor Feature Let a Single Link Forge a WordPress Admin Account

Elementor has patched a critical cross-site request forgery (CSRF) flaw that let a single link, opened by any logged-in WordPress user, forge a request to create a new administrator account or read a site’s settings, all without JavaScript, a form, or a page under the attacker’s control. The bug, tracked as CVE-2026-62062 and rated 8.8 (High) under CVSS 3.1, lived in the free Elementor Website Builder plugin for exactly two days before Elementor shipped a fix.

Patchstack’s disclosure, published Friday and credited to the researcher known as Saggre, says the flaw shipped only in versions 4.3.0 and 4.3.1, which are the two most recent releases of the plugin before Thursday’s patch. Elementor itself is active on more than 10 million WordPress sites; Patchstack’s own headline puts the number of sites that picked up the affected pair of releases at more than 2 million, though the company’s write-up does not walk through how that specific figure was derived.

A hidden feature, on by default

The vulnerable code belongs to Elementor’s Editor Events module, which proxies telemetry from the page-building editor. According to Patchstack, the module is gated behind an internal experiment flag that is deliberately hidden from the Experiments screen most site owners would check, and that flag defaults to active for any site whose first Elementor install was version 3.32.0 or later. A default, unmodified install of 4.3.0 or 4.3.1 was affected with no settings changed and no other plugin involved.

The module’s constructor hooks WordPress’s rest_authentication_errors filter at priority 0, before any other handler runs, and asks a narrow question: is this request headed for one of my own routes? Patchstack quotes the check verbatim:

// core/common/modules/events-manager/rest-api/events-proxy-rest-api.php
public function bypass_nonce_check_for_own_routes( $result ) {
    if ( $this->is_own_route_request() ) {
        return true;
    }
    return $result;
}

private function is_own_route_request(): bool {
    $request_uri = Utils::get_super_global_value( $_SERVER, 'REQUEST_URI' ) ?? '';
    // API_NAMESPACE = 'elementor/v1', API_BASE = 'events'
    return false !== strpos( $request_uri, self::API_NAMESPACE . '/' . self::API_BASE . '/' );
}

The problem, Patchstack explains, is timing. rest_authentication_errors fires inside WP_REST_Server::check_authentication(), before WordPress has matched a route, so the only thing the callback has to inspect is the raw request URI, a string that includes the full query string and that the client fully controls. The check does not anchor its search to the actual route; it just looks for the substring elementor/v1/events/ anywhere in that URI, including inside a query parameter that is never used for anything else.

Returning true from that filter does not just skip Elementor’s own check. WordPress’s core CSRF protection for cookie-authenticated REST requests, the function rest_cookie_check_errors(), is written to respect whatever an earlier handler already decided:

// wp-includes/rest-api.php - rest_cookie_check_errors()
function rest_cookie_check_errors( $result ) {
    if ( ! empty( $result ) ) {
        return $result; // Elementor returned true at priority 0, so this returns here
    }
    // ...never reached: the wp_rest nonce is never verified
    $result = wp_verify_nonce( $nonce, 'wp_rest' );
    // ...
}

A value of true reads as “authentication already succeeded,” so core’s nonce check, and the nonce check of any other security plugin hooked to the same filter, never runs. What is left is the route’s own permission check, which asks what the logged-in visitor’s account is normally allowed to do. Since the victim really is logged in, that check passes; only the proof that the victim actually intended the request is gone.

A single link, no script required

Most REST-based CSRF bugs need a page that submits a form or fires a fetch() call, which limits an attacker to places they can host markup. This one did not, because the WordPress REST API accepts a _method query parameter that lets a plain GET request stand in for a POST. Patchstack’s example shows the entire attack fitting inside one URL:

https://example.com/wp-json/wp/v2/users
    ?_method=POST
    &username=csrfadmin
    &email=csrfadmin%40example.test
    &password=...
    &roles%5B%5D=administrator
    &x=elementor/v1/events/    <- the only part that matters

Without that last parameter, the request fails with rest_cannot_create_user and an HTTP 401. With it, the server responds with HTTP 201 and a new user whose role is administrator. Patchstack says the researcher also confirmed that shortening the marker by a single character, to elementor/v1/event/, was enough to make the request fail again, ruling out any other explanation for the bypass. Because the payload is a plain anchor tag rather than a script, it can be delivered anywhere a link can appear: an email, a chat message, a comment on an entirely unrelated site.

The blast radius reached every REST route on the site

Patchstack is careful to note that this was not a bug confined to Elementor’s own endpoints. Because the bypass ran before WordPress had matched a route at all, it applied to the REST API surface of the whole site, including routes registered by plugins that had nothing to do with Elementor. Alongside the administrator-creation example, Patchstack says the researcher also turned a request to /wp-json/wp/v2/settings from an HTTP 401 into an HTTP 200 that returned the site’s settings in the response body.

A two-day window, and a vague changelog entry

The timeline is tight. Elementor shipped 4.3.0 on September 22, the release that introduced the vulnerable code alongside new features including a new “Elementor MCP” feature for connecting external AI tools to a site. Patchstack says it received the researcher’s report the same day. Elementor released 4.3.1 the next day with an unrelated translation fix, still carrying the bug, and shipped 4.3.2 on September 24 with the actual patch. Patchstack’s advisory went public the day after that.

The fix changes both the input and the comparison. Instead of the raw request URI, the check now reads the route WordPress already resolved from $wp->query_vars['rest_route'], a value with the query string stripped out entirely, and it requires the plugin’s namespace to appear at the start of that route rather than anywhere inside it. Elementor’s own public changelog entry for 4.3.2 does not mention a CVE or the word forgery; it lists the change only as “Fix: Improved code security enforcement in data handling,” one line among five other, unrelated tweaks and fixes in the same release.

What site owners should do

Sites running Elementor 4.3.0 or 4.3.1 should update to 4.3.2 or later immediately; WordPress.org’s plugin repository already lists 4.3.2 as the current version. Sites on any release before 4.3.0 never shipped the Editor Events proxy and were not affected in the first place. CVE-2026-62062 is filed under CWE-352, the standard weakness class for cross-site request forgery, and as of publication it had not been added to CISA’s Known Exploited Vulnerabilities catalog, meaning there is no public evidence yet that it has been exploited outside Patchstack’s own proof of concept.

This is a separate product and a separate class of bug from Elementor’s two prior appearances in sxz.io’s coverage. Both an August file-upload flaw and a since-exploited bug reported in September affected Elementor Pro, the paid add-on sold separately from the plugin covered here. This week’s flaw sits in the free Elementor Website Builder core plugin that Pro extends, and it is a request-forgery bug rather than a file-upload one; the two products share a vendor and a name, not a vulnerability class.