CVE-2026-15823 in Builderall Plugin
Summary
by MITRE • 09/10/2026
The Builderall Cheetah For Wp plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the disable() function in versions up to, and including, 3.0.2. The wp_ajax_ba_cheetah_disable AJAX handler is registered without any capability or nonce verification, and the target post_id is sourced directly from user-controlled $_POST['ba_cheetah_data']['post_id']. This makes it possible for authenticated attackers, with Subscriber-level access and above, to disable the page builder layout on arbitrary posts by setting the _ba_cheetah_enabled post meta to false, including on posts owned by other users.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Builderall Cheetah For WP versions up to 3.0.2 represents a critical failure in access control mechanisms within the WordPress plugin ecosystem. This flaw is classified under CWE-862, which denotes Missing Authorization, and specifically aligns with MITRE ATT&CK technique T1548.001, known as Abuse Elevation Control Mechanism: Bypass User Interface Restrictions. The core issue stems from the registration of the wp_ajax_ba_cheetah_disable AJAX handler without implementing any form of capability verification or nonce validation. In standard WordPress development practices, administrative actions that modify site configuration or content structure must be protected by checking if the current user possesses specific capabilities and verifying a security token to prevent Cross-Site Request Forgery attacks. The absence of these safeguards creates an open pathway for malicious actors to execute privileged functions without proper authorization checks.
From a technical perspective, the vulnerability exploits how input data is processed within the disable() function. The target post identifier is sourced directly from user-controlled superglobal arrays, specifically $_POST['ba_cheetah_data']['post_id'], with no sanitization or validation against existing posts or ownership constraints. This direct assignment allows an attacker to manipulate the internal state of the application by specifying arbitrary post IDs. When this input is processed, it triggers a database update that sets the _ba_cheetah_enabled post meta field to false. Since there are no checks to ensure the requesting user owns the specified post or has administrative rights over its content, the function operates on any accessible resource within the WordPress installation. This lack of object-level authorization means that the scope of impact extends far beyond the attacker's own content, affecting all posts and pages managed by the site.
The operational impact of this vulnerability is significant for website integrity and user experience. An authenticated attacker with even minimal privileges, such as Subscriber level or higher, can disable the page builder layout on arbitrary posts. This action effectively breaks the visual structure and functionality of those specific web pages, potentially rendering them unusable or displaying broken layouts to end-users. For multi-author sites, this capability allows malicious users to sabotage the work of other contributors by disabling their content formatting tools remotely. Furthermore, because the attack can be automated via AJAX requests, it facilitates rapid, large-scale disruption without requiring complex exploitation techniques. This could lead to substantial downtime, loss of trust in the platform's reliability, and increased administrative overhead as site owners must manually re-enable layouts for affected posts.
Mitigation strategies should focus on immediate patching and enhanced security configurations. The primary remediation is to upgrade Builderall Cheetah For WP to a version that addresses this vulnerability by implementing proper capability checks using functions like current_user_can() and verifying nonces with wp_verify_nonce(). Administrators of sites running vulnerable versions should restrict user roles where possible, ensuring that only trusted users have access to the dashboard. Additionally, deploying Web Application Firewalls can help detect and block suspicious AJAX requests targeting known vulnerable endpoints. Regular security audits and adherence to WordPress coding standards are essential to prevent similar authorization flaws in future updates or other plugins installed on the same environment.