CVE-2026-3235 in WP Data Access Plugin
Summary
by MITRE • 08/26/2026
The WP Data Access plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 5.5.68 via the 'check_app_access' function due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to access data from protected app containers by exploiting a mismatch between the authorization check (performed against app_id) and data retrieval (performed using cnt_id without verifying container ownership).
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The WP Data Access plugin, widely utilized in WordPress environments for managing database interactions through structured application interfaces, contains a critical security flaw affecting all versions up to 5.5.68. This vulnerability is classified as an Insecure Direct Object Reference (IDOR), formally known under the Common Weakness Enumeration standard as CWE-204. The core of this issue lies within the check_app_access function, which serves as a gatekeeper for accessing data stored in protected application containers. While the plugin implements authorization checks to verify user permissions against an app_id parameter, it fails to validate ownership or access rights when retrieving actual data using a separate container identifier, cnt_id. This architectural disconnect creates a significant security gap that allows unauthenticated attackers to bypass intended restrictions and extract sensitive information from containers they do not own or have permission to view.
From a technical perspective, the vulnerability exploits the lack of synchronization between authorization validation and resource access logic. When an attacker initiates a request, the system verifies whether the user has rights associated with a specific app_id. However, subsequent data retrieval operations rely on cnt_id without ensuring that this container belongs to the authorized application or user context. By manipulating the cnt_id parameter in HTTP requests, attackers can enumerate and access arbitrary protected containers within the WordPress database structure. This bypasses authentication mechanisms entirely because the initial check passes based on a valid but unrelated app_id, while the actual data exposure is driven by the attacker-controlled container identifier. The absence of strict ownership verification means that any publicly accessible endpoint utilizing this function becomes a vector for unauthorized data disclosure.
The operational impact of this vulnerability is severe, particularly in environments where WP Data Access handles sensitive business or personal information. Unauthenticated attackers can perform non-interactive enumeration to discover valid cnt_id values and subsequently extract confidential records from protected app containers. This leads directly to the compromise of confidentiality integrity within the affected WordPress installation. Depending on the data stored in these containers, consequences may include exposure of user credentials, financial details, proprietary business logic, or other regulated information subject to compliance frameworks such as GDPR or HIPAA. The ability to access this data without authentication significantly lowers the barrier for exploitation, allowing even low-skilled threat actors to conduct large-scale data scraping attacks against vulnerable sites.
This vulnerability aligns with several tactics within the MITRE ATT&CK framework, specifically relating to Collection and Exfiltration phases where attackers gather sensitive information from compromised systems. It also reflects common weaknesses in web application design where input validation is applied inconsistently across different stages of request processing. To mitigate this risk, administrators must immediately update WP Data Access to version 5.5.69 or later, which addresses the missing validation logic by ensuring that cnt_id ownership is verified against app_id authorization contexts before data retrieval occurs. In cases where immediate patching is not feasible, implementing web application firewall rules to restrict access to affected endpoints and enforcing strict input validation on container identifiers can provide temporary protection. Regular security audits focusing on direct object reference patterns in custom WordPress plugins are recommended to prevent similar architectural flaws from being introduced or overlooked in future updates.