CVE-2026-107100 in Royal Addons for Elementor Plugin
Summary
by MITRE • 10/28/2026
The Royal Addons for Elementor WordPress plugin before 1.7.1070 does not verify that a requested post is publicly viewable before returning its content via an unauthenticated AJAX action, relying only on the published status and not on the post type's visibility, allowing unauthenticated users to disclose the content of posts stored in non-public post types, for example captured contact-form submissions containing names, email addresses and messages.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in Royal Addons for Elementor versions prior to 1.7.1070 represents a critical failure in access control logic within the plugin's AJAX handling mechanisms. This flaw stems from an insufficient verification process where the application checks only the publication status of a requested post, specifically whether it is marked as published, without validating its visibility settings or public accessibility attributes. In WordPress architecture, posts can exist in various states and types beyond standard blog entries, including private posts, password-protected content, and custom post types that may have restricted viewing permissions by design. By relying solely on the published flag, the system inadvertently bypasses these additional security layers, allowing any user with knowledge of a valid post ID to retrieve sensitive data regardless of its intended privacy level.
From a technical perspective, this issue is classified under CWE-284, which denotes Improper Access Control, and aligns with MITRE ATT&CK technique T1078, specifically the Valid Accounts or Default Accounts sub-category if exploited through discovered IDs, though more accurately it reflects improper authorization checks typical of Broken Object Level Authorization (BOLA) patterns found in CWE-639. The exploitation vector is unauthenticated AJAX action invocation, meaning that an attacker does not need to possess valid credentials or be logged into the WordPress dashboard. Instead, they can craft specific HTTP requests targeting the vulnerable endpoint with known post identifiers. This capability transforms what might seem like a minor configuration oversight into a significant data exposure risk, particularly because it affects non-public post types which are often used for storing sensitive operational data rather than public-facing content.
The operational impact of this vulnerability is severe due to the nature of data typically stored in custom post types within Elementor-based websites. Developers and site administrators frequently utilize these areas to capture and store contact form submissions, lead generation details, or internal communication logs. Consequently, an attacker can extract personally identifiable information such as names, email addresses, phone numbers, and detailed message contents from the database without authorization. This constitutes a direct violation of data confidentiality principles and exposes organizations to potential regulatory penalties under frameworks like GDPR or CCPA due to the unauthorized disclosure of personal data. Furthermore, the aggregated nature of this data could facilitate further social engineering attacks or targeted phishing campaigns against individuals whose information was exposed.
To mitigate this risk, immediate action is required by upgrading the Royal Addons for Elementor plugin to version 1.7.1070 or later, where the developers have implemented proper visibility checks alongside publication status verification. For sites that cannot upgrade immediately due to compatibility constraints, temporary mitigations should include restricting access to AJAX endpoints via server-level rules if possible, although this is often difficult with dynamic WordPress environments. Additionally, implementing a Web Application Firewall (WAF) rule set designed to detect and block suspicious patterns of bulk post ID enumeration can help reduce the attack surface. Site administrators must also audit their custom post type configurations to ensure that sensitive data storage practices align with security best practices, such as avoiding the use of public-facing plugins for storing highly confidential information without additional encryption or access controls at the application level. Regular vulnerability scanning and code reviews focusing on AJAX handlers are recommended to prevent similar logic flaws in future updates or third-party integrations.