CVE-2026-2918 in Happy Addons for Elementor Plugin
Summary
by MITRE • 03/11/2026
The Happy Addons for Elementor plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 3.21.0 via the `ha_condition_update` AJAX action. This is due to the `validate_reqeust()` method using `current_user_can('edit_posts', $template_id)` instead of `current_user_can('edit_post', $template_id)` — failing to perform object-level authorization. Additionally, the `ha_get_current_condition` AJAX action lacks a capability check. This makes it possible for authenticated attackers, with Contributor-level access and above, to modify the display conditions of any published `ha_library` template. Because the `cond_to_html()` renderer outputs condition values into HTML attributes without proper escaping (using string concatenation instead of `esc_attr()`), an attacker can inject event handler attributes (e.g., `onmouseover`) that execute JavaScript when an administrator views the Template Conditions panel, resulting in Stored Cross-Site Scripting.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 03/17/2026
The vulnerability described in CVE-2026-2918 represents a critical security flaw within the Happy Addons for Elementor WordPress plugin, affecting all versions up to and including 3.21.0. This issue stems from an insecure direct object reference condition that allows unauthorized modification of published templates through improper authorization checks. The vulnerability specifically manifests in two distinct AJAX endpoints: `ha_condition_update` and `ha_get_current_condition`, both of which fail to properly validate user permissions before allowing template modifications. The root cause lies in the implementation of the `validate_reqeust()` method which incorrectly uses `current_user_can('edit_posts', $template_id)` instead of the proper `current_user_can('edit_post', $template_id)` function call. This fundamental flaw in authorization logic creates a pathway for authenticated attackers with Contributor-level access or higher to manipulate display conditions of any published `ha_library` template, effectively bypassing the intended object-level access controls.
The operational impact of this vulnerability extends beyond simple unauthorized template modification, creating a sophisticated attack vector that culminates in stored cross-site scripting capabilities. The flaw in the `cond_to_html()` renderer function compounds the issue by directly outputting condition values into HTML attributes without proper sanitization or escaping mechanisms. Rather than employing WordPress's recommended `esc_attr()` function for attribute escaping, the code relies on simple string concatenation, creating an environment where malicious input can be injected into HTML event handlers. This vulnerability enables attackers to inject JavaScript code through event attributes such as `onmouseover` or similar handlers, which then execute when administrators view the Template Conditions panel. The stored nature of this XSS vulnerability means that once an attacker successfully injects malicious code, it persists in the affected templates and executes automatically whenever the targeted administrators access the relevant interface, creating a persistent threat vector that can be leveraged for session hijacking, credential theft, or further exploitation of the compromised WordPress environment.
This vulnerability aligns with CWE-284 (Improper Access Control) and CWE-79 (Cross-Site Scripting) categories, representing a classic example of how inadequate authorization checks can lead to serious security implications. The attack pattern follows the ATT&CK framework's T1548.001 (Abuse Elevation Control Mechanism) and T1165 (Injection) techniques, as the vulnerability exploits both permission bypass mechanisms and code injection capabilities. The fact that this affects authenticated users with Contributor-level access demonstrates the importance of principle of least privilege implementation, where even users with relatively low permissions should not be able to manipulate objects they do not own or have explicit authorization to modify. Organizations using this plugin are particularly vulnerable as the attack requires minimal privileges and can be executed through standard WordPress administrative interfaces, making it a significant concern for WordPress site owners who may not be aware of the specific vulnerability in their third-party plugins. The stored XSS nature of the vulnerability makes it particularly dangerous as it can affect multiple administrators over time, potentially leading to widespread compromise of the WordPress administration interface and underlying user sessions.