Booking Ultra Pro <= 1.1.23 - Authenticated (Subscriber+) Information Exposure

Since source files were not provided for Booking Ultra Pro <= 1.1.23, this plan is based on the vulnerability description, common patterns in this plugin's architecture, and standard WordPress security research methodologies. Identifiers marked with (inferred) must be verified by the agent during the initial discovery phase.

---

1. Vulnerability Summary

The Booking Ultra Pro plugin is vulnerable to Information Exposure via insecurely protected AJAX or REST API endpoints. Authenticated users with Subscriber-level permissions can trigger specific actions that return sensitive data—such as full user lists (including emails/phone numbers), plugin configuration (potentially including API keys), or internal system paths—because the plugin fails to implement proper capability checks (current_user_can) on these administrative functions.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Vulnerable Action (Inferred): bup_get_staff_list, bup_get_clients, or bup_export_settings.
• Authentication: Subscriber level (PR:L).
• Payload Parameter: action, security (nonce), and potentially type or id.
• Preconditions: The attacker must be logged in as a Subscriber.

3. Code Flow (Discovery Logic)

The agent should trace the following path to confirm the vulnerability:

1. Entry Point: Search for AJAX registrations in the plugin folder (likely classes/ or admin/ directories).
   • grep -rn "wp_ajax_" .
2. Identify Weak Handlers: Look for functions registered with wp_ajax_ but not wp_ajax_nopriv_.
3. Audit Capabilities: Examine the callback function for each handler.
   • Vulnerable Pattern: The function uses check_ajax_referer(...) but lacks if ( ! current_user_can( 'manage_options' ) ) { wp_die(); }.
4. Sink (Data Exposure): Identify where $wpdb->get_results or get_option is called and immediately returned as JSON.
   • Target: Queries fetching from {$wpdb->prefix}users or {$wpdb->prefix}booking_ultra_pro_... tables.

4. Nonce Acquisition Strategy

The plugin likely localizes a nonce for its AJAX requests.

1. Identify Localization: Search for wp_localize_script.
   • grep -rn "wp_localize_script" .
   • Look for a variable like bup_ajax_obj (inferred) or booking_ultra_params (inferred).
2. Determine Script Placement: Find which page enqueues the script containing the nonce. It is likely the main booking page or the user profile page.
3. Execution:
   • Create a test page with the booking shortcode: [booking_ultra_pro] (inferred).
   • Navigate to this page as a Subscriber.
   • Use browser_eval to extract the nonce:

     // Example: Adjust based on actual localized object found in step 1
     window.bup_ajax_obj?.nonce || window.booking_ultra_params?.security
     

5. Exploitation Strategy

Once the action name and nonce are identified:

1. Setup: Ensure a Subscriber user is created and logged in.
2. Request: Use http_request to call the vulnerable AJAX action.
3. Target Action: bup_get_all_users (inferred - verify via grep).

HTTP Request Template:

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

  action=[ACTION_NAME]&security=[NONCE_VALUE]&query_type=all
  

  (Note: Replace [ACTION_NAME] with the specific handler found in Discovery, e.g., bup_fetch_staff.)

6. Test Data Setup

To demonstrate "Sensitive Information Exposure," the environment must contain sensitive data to expose:

1. Users: Create multiple users with different roles (Admin, Editor) and fill their profiles with dummy "sensitive" data (phone numbers in metadata).
   • wp user create staff_member staff@example.com --role=editor --user_pass=password
   • wp user填 meta set [ID] phone_number "555-0199"
2. Shortcode Page:
   • wp post create --post_type=page --post_title="Booking" --post_status=publish --post_content='[booking_ultra_pro]'

7. Expected Results

• Successful Exploit: The server returns a 200 OK response with a JSON body containing a list of users, their emails, and potentially metadata (phone numbers, addresses) that should only be visible to administrators.
• Vulnerability Confirmation: A Subscriber (who should not have access to the full user list) successfully receives data belonging to other users.

8. Verification Steps

1. Verify via CLI: Compare the JSON output from the http_request with the actual user database:
   • wp user list --fields=ID,user_email,display_name
2. Check Sensitivity: Confirm if the JSON output includes the user_pass (hash) or user_email of the Administrator.

9. Alternative Approaches

If the AJAX action is not bup_get_staff_list, check for:

• Settings Exposure: Action bup_get_settings. Look for responses containing stripe_api_key or paypal_email.
• Debug/Log Exposure: Search for actions that return file contents, such as bup_view_log.
• REST API: If AJAX is secure, check register_rest_route calls. Look for routes in the bup/v1 namespace (inferred) that lack a permission_callback or use __return_true.