Description

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).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-26T11:16:38.073Z",
  "pubdate": "2026-08-26T11:16:38.073Z",
  "executiveSummary": "The WP Data Access plugin is susceptible to an Insecure Direct Object Reference (IDOR) vulnerability affecting all versions up to and including 5.5.68.\nThe flaw originates from the check_app_access function, which fails to properly validate the relationship between a user-controlled container identifier and the authorized application identifier.\nThis vulnerability allows unauthenticated remote attackers to bypass access controls and retrieve sensitive information from protected app containers.\nThe impact includes unauthorized data exposure, potential compromise of sensitive records managed through the plugin, and unauthorized access to data structures that should be restricted to authenticated or authorized users.\nExploitation requires no authentication, making it a critical risk for deployments using the WP Data Access plugin where sensitive data is stored within containers.\nThe core issue lies in a logical mismatch between the authorization verification process and the data retrieval process, allowing an attacker to manipulate parameters to access data they are not entitled to view.",
  "technicalDetails": "The vulnerability resides within the check_app_access function of the WP Data Access plugin. The function is designed to enforce access control checks for app containers; however, it suffers from a critical flaw in input validation and object reference management.\nThe root cause is a breakdown in the authorization logic: the plugin performs an initial security check against a provided app_id parameter, but subsequently retrieves data based on a different, user-controlled parameter, cnt_id, without verifying that the requested cnt_id is actually owned by or associated with the validated app_id.\nBy supplying a legitimate app_id that passes the initial authorization check and pairing it with an arbitrary or unauthorized cnt_id, an attacker can coerce the plugin into executing database queries for data containers they are not permitted to access.\nThe attack flow proceeds as follows: First, the attacker identifies a target container ID (cnt_id) for which they seek unauthorized access. Second, the attacker invokes the check_app_access function with a request containing both the authorized application identifier and the target cnt_id. Third, the application validates the app_id, creating a false sense of security regarding the request's legitimacy. Finally, the internal retrieval logic executes using the unvalidated cnt_id, bypassing the authorization context and returning the requested data to the attacker.\nSince this functionality is reachable by unauthenticated users, the attack surface is exposed directly to the network. There is no requirement for administrative privileges or local account access to trigger this IDOR.\nThe lack of server-side object ownership verification allows for systemic data enumeration if the attacker can guess or discover valid cnt_id values. This leads to complete exposure of container contents. The vulnerability persists across all versions up to 5.5.68, and remediation requires a logic patch that forces the application to verify that the retrieved container (cnt_id) belongs to the authorized application context before data retrieval occurs."
}