CVE-2026-118205 in Essential Addons for Elementor Plugin
Summary
by MITRE • 10/30/2026
The Essential Addons for Elementor – Popular Elementor Templates & Widgets plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 6.8.7 via the `page_id` parameter of the `register_user()` function. The vulnerability exists because the handler's post status deny-list rejects `future`, `draft`, and `pending` but admits `inherit` — the status carried by every WordPress revision — allowing an attacker to substitute a revision ID for a live page ID, while a flawed "last saved by administrator" check reads `post_author` on revisions (which reflects the editing administrator) rather than the `_edit_last` meta that is never copied to revisions, and the nonce gate is rendered ineffective because any unauthenticated visitor can freely obtain a valid nonce via the `wp_ajax_nopriv_eael_get_token` endpoint. This makes it possible for unauthenticated attackers to register an account with a role as high as Editor — gaining capabilities including `edit_others_posts`, `publish_pages`, `upload_files`, and `unfiltered_html` — by naming a revision whose `_elementor_data` contains an elevated role an administrator previously saved and later reverted on a page bearing the Login/Register widget. Successful exploitation requires that the site has "Anyone can register" enabled and that an administrator has at some point saved and then reverted a non-default "New User Role" on an affected page.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The Essential Addons for Elementor plugin, widely used within the WordPress ecosystem to extend functionality through templates and widgets, contains a critical privilege escalation vulnerability in versions up to 6.8.7. This flaw resides specifically within the `register_user()` function and is triggered via manipulation of the `page_id` parameter. The core technical failure stems from an incomplete validation logic regarding post statuses. While the handler explicitly denies access for posts with status values such as future, draft, or pending, it inadvertently permits requests where the post status is inherit. In WordPress architecture, every revision created by a user carries this inherit status, effectively allowing attackers to bypass intended restrictions by substituting a live page ID with an older revision ID of that same page.
The exploitation mechanism relies on a flawed authentication and authorization check within the plugin's logic. The code attempts to verify administrative privileges by reading the `post_author` field from the post object associated with the provided ID. However, when dealing with revisions, this field reflects the author who created or last edited the revision, which may be an administrator if they previously modified the page content. Crucially, the plugin fails to check the `_edit_last` meta value, which is not copied to revisions and would correctly indicate whether the current user has permission to perform administrative actions on that specific post context. This discrepancy allows a non-administrator or unauthenticated actor to impersonate an administrator's authority by pointing to a revision authored by one.
Furthermore, the nonce-based security gate designed to prevent Cross-Site Request Forgery is rendered ineffective due to a separate configuration issue in the plugin. The endpoint `wp_ajax_nopriv_eael_get_token` allows any visitor, regardless of authentication status, to obtain a valid nonce. This means that even if an attacker does not have a logged-in session, they can freely fetch a legitimate security token and use it to forge requests against the vulnerable registration function. This combination of flawed post-status validation, incorrect privilege checking logic on revisions, and accessible nonces creates a perfect storm for exploitation without any prior authentication or interaction with protected areas of the site beyond public-facing pages containing specific widgets.
Successful exploitation requires two preconditions: first, the WordPress installation must have user registration enabled via the setting "Anyone can register." Second, an administrator must have previously saved a page using the Login/Register widget where the New User Role was set to something other than the default subscriber role, and subsequently reverted that change or edited the page again. When these conditions are met, an unauthenticated attacker can craft a request specifying a revision ID of such a page along with desired user details. The system will process this registration as if it were authorized by the administrator who last touched that content in its current form. Consequently, the attacker gains access to a newly created account with elevated privileges, potentially reaching Editor level or higher depending on the configuration at the time of the revision.
The operational impact of this vulnerability is severe, granting attackers capabilities typically reserved for trusted users. Upon successful exploitation, the new account possesses rights such as `edit_others_posts`, allowing modification of content not authored by them; `publish_pages`, enabling the publication of pages that appear live on the site; and `upload_files`, which facilitates the upload of malicious scripts or other harmful assets to the server's media library. Additionally, the `unfiltered_html` capability allows for the injection of arbitrary HTML and JavaScript into posts and pages, significantly increasing the risk of persistent cross-site scripting attacks against visitors. These capabilities collectively compromise the integrity, confidentiality, and availability of the WordPress site, potentially leading to full website takeover if combined with other vectors or used as a foothold for further lateral movement within the server environment.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, specifically involving incorrect assumptions about user roles based on post metadata rather than actual session permissions. It also maps to MITRE ATT&CK techniques related to Account Manipulation and Defense Evasion, as attackers exploit the system's trust in revision history and nonce validity to bypass access controls without detection by standard security monitoring tools that might not flag registration events originating from public endpoints with valid nonces. The flaw highlights a common pitfall in WordPress plugin development where developers assume post metadata behaves consistently across different post types like pages versus revisions, failing to account for the distinct data structures maintained by the revision system.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Administrators should immediately update Essential Addons for Elementor to version 6.8.8 or later, where this logic has been corrected to properly validate post types and check `_edit_last` meta values alongside `post_author`. For sites unable to patch instantly due to compatibility concerns with other plugins, disabling user registration temporarily via the WordPress settings is a viable stopgap measure. Additionally, restricting access to the `wp_ajax_nopriv_eael_get_token` endpoint through web application firewall rules or by modifying plugin code to require authentication for nonce generation can mitigate the risk of unauthenticated exploitation. Security audits should also review other instances where post revisions are used as proxies for live content validation, ensuring that privilege checks always reference current user sessions and explicit capability grants rather than historical metadata states.