CVE-2026-12904 in Kadence Blocks Plugin
Summary
by MITRE • 07/01/2026
The Kadence Blocks – Gutenberg Blocks for Page Builder Features plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions up to and including 3.7.7. This is due to a mismatch between the object used for authorization and the object actually accessed in the Optimize_Rest_Controller's create_item(), get_item(), delete_item(), and bulk_delete_items() endpoints — authorization is checked via current_user_can('edit_post'/'delete_post', $post_id) against the user-supplied post_id, while the storage layer keys analysis records on sha256($post_path) from a separately supplied, attacker-controlled post_path parameter, with no enforcement that post_path corresponds to post_id. This makes it possible for authenticated attackers, with Contributor-level access and above, to read or delete optimizer analysis records belonging to posts owned by other users by submitting their own post_id (which passes the capability check) together with the victim post's path.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/01/2026
The Kadence Blocks plugin vulnerability represents a critical insecure direct object reference flaw that undermines the authorization mechanisms protecting user data within WordPress environments. This weakness exists in versions up to and including 3.7.7 where the plugin's Optimize_Rest_Controller implements inconsistent object validation between authorization checks and actual data access operations. The vulnerability stems from a fundamental mismatch in how the system authenticates user requests against the objects being accessed, creating an exploitable gap that allows authenticated attackers to bypass intended access controls.
The technical implementation of this flaw occurs through a deliberate disconnect between two different parameters used during REST API endpoint processing. When users make requests to create_item(), get_item(), delete_item(), or bulk_delete_items() endpoints, the authorization layer performs capability checks using current_user_can('edit_post'/'delete_post', $post_id) which validates against the user-supplied post_id parameter. However, the actual data storage and retrieval operations utilize sha256($post_path) as the key for optimizer analysis records, where post_path is sourced from a separately provided attacker-controlled parameter. This mismatch creates an opportunity for privilege escalation attacks where malicious users can manipulate one parameter while the system validates against another.
Authenticated attackers with Contributor-level access or higher can exploit this vulnerability by crafting requests that combine their own valid post_id with a target user's post_path. The authorization check passes because the attacker's credentials are validated against their own post_id, but the storage layer retrieves or modifies data based on the victim's post_path, effectively allowing unauthorized access to optimizer analysis records belonging to other users. This vulnerability directly maps to CWE-284 (Improper Access Control) and represents a classic case of weak object reference validation that violates fundamental security principles.
The operational impact of this vulnerability extends beyond simple data exposure to include potential data manipulation and privacy violations across multiple user accounts within the same WordPress installation. Attackers can read sensitive optimizer analysis data including performance metrics, optimization recommendations, and potentially other metadata associated with posts they do not own. The ability to delete these records also presents a significant threat to data integrity and could be used to disrupt workflow processes or remove evidence of optimization activities. This vulnerability affects all users who have Contributor access or higher, which typically includes content editors, authors, and administrators within WordPress environments.
Mitigation strategies should focus on implementing proper parameter validation and ensuring consistency between authorization checks and object access operations. The recommended approach involves enforcing strict correlation between post_id and post_path parameters before any storage layer operations occur, eliminating the possibility of cross-user data access through parameter manipulation. Additionally, implementing proper input sanitization and validation for all user-supplied parameters will help prevent similar issues in the future. Security teams should also consider implementing monitoring for unusual patterns of API requests that might indicate exploitation attempts, as well as ensuring timely patch updates to address this vulnerability. This issue aligns with ATT&CK technique T1078.004 (Valid Accounts: Cloud Accounts) and represents a critical weakness in access control implementation that requires immediate attention from WordPress administrators.