Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-10T04:17:48.280Z",
  "pubdate": "2026-09-10T04:17:48.280Z",
  "executiveSummary": "The Builderall Cheetah For Wp WordPress plugin contains an unauthorized data modification vulnerability affecting versions up to and including 3.0.2.\nThe vulnerability stems from a lack of capability checks and nonce verification within the AJAX handler registered to the disable() function.\nAn authenticated attacker with Subscriber-level privileges can exploit this flaw to disable the page builder layout on any post or page by manipulating the _ba_cheetah_enabled post meta field.\nThis unauthorized modification impacts data integrity, as attackers can disrupt the visual structure and content presentation of arbitrary posts within the WordPress installation.\nThe exploit requires minimal technical expertise and relies on the target's authentication session, allowing for wide-scale modification of content configuration without administrative oversight.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of the AJAX handler wp_ajax_ba_cheetah_disable. This handler is registered to execute the disable() function, which is designed to toggle the state of the Builderall Cheetah page builder on specific posts.\nThe function fails to perform any authorization checks, such as using current_user_can(), to verify if the requesting user possesses the necessary administrative or editing privileges. Furthermore, the handler lacks CSRF protection, as no nonce verification is performed via check_ajax_referer() or equivalent methods.\nThe vulnerable code directly processes the post_id provided via the user-controlled $_POST['ba_cheetah_data']['post_id'] parameter. This input is passed into the WordPress update_post_meta() function to set the _ba_cheetah_enabled meta key to a value of false.\nBecause the post_id is not validated against the user's permissions, an attacker can supply the identifier for any existing post or page within the database. When the AJAX request is sent to the WordPress admin-ajax.php endpoint, the server processes the command and updates the database, effectively disabling the page builder for the target post.\nThe attack flow proceeds as follows: First, the attacker initiates an authenticated session on the target WordPress site. Second, the attacker crafts a POST request targeting /wp-admin/admin-ajax.php, setting the action parameter to ba_cheetah_disable and passing the targeted post_id within the ba_cheetah_data array. Third, the application's backend blindly executes the disable() function. Finally, the database is updated, removing the Builderall Cheetah layout functionality from the target post, causing potential display issues or loss of content formatting for end users.\nThe impact is significant as it allows attackers to bypass intended access control mechanisms to modify post meta, which can be leveraged to alter the site's front-end appearance, disrupt workflows, or cause denial-of-service to specific page layouts across the entire site infrastructure."
}