AweBooking <= 3.2.26 - Authenticated (Subscriber+) Information Exposure

Since the source files for AweBooking 3.2.26 are not provided, this research plan is based on the vulnerability description (Authenticated Information Exposure, Subscriber+), the plugin's known architecture (hotel booking system), and common patterns for this vulnerability class.

1. Vulnerability Summary

The AweBooking plugin (<= 3.2.26) contains an Information Exposure vulnerability where authenticated users with Subscriber-level permissions can access sensitive configuration or user data. This typically occurs in AJAX handlers registered via wp_ajax_ that fail to implement proper capability checks (e.g., current_user_can('manage_options')) or fail to validate that the requested data belongs to the requesting user.

The target is likely an AJAX action intended for administrators or specific users that is erroneously accessible to any logged-in user, or one that leaks data via a response intended for the frontend.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action (Inferred): Likely candidates include awe_get_user_data, awe_booking_details, awe_get_customer_info, or awe_export_settings.
• Vulnerable Parameter: user_id, id, or booking_id.
• Authentication: Subscriber level (lowest authenticated role).
• Preconditions: The attacker must be logged in and obtain a valid AJAX nonce.

3. Code Flow (Inferred)

1. Registration: The plugin registers an AJAX handler in a core class or main file:
   add_action( 'wp_ajax_awe_vulnerable_action', array( $this, 'handle_vulnerable_request' ) );
2. Entry Point: The user sends a POST request to admin-ajax.php with action=awe_vulnerable_action.
3. Missing Check: The function handle_vulnerable_request performs a nonce check but fails to check for administrative capabilities.

   public function handle_vulnerable_request() {
       check_ajax_referer( 'awe_nonce_action', 'nonce' ); // Nonce is present
       // MISSING: if ( ! current_user_can( 'manage_options' ) ) wp_die();
       
       $id = $_POST['id'];
       $data = get_userdata( $id ); // Or database query for booking info
       wp_send_json_success( $data ); // Returns sensitive object
   }
   

4. Exposure: The full user object (including potentially email, hashed password, or meta) or booking details (guest names, contact info) is returned in the JSON response.

4. Nonce Acquisition Strategy

The execution agent must identify where the plugin localizes its AJAX settings.

1. Identify Shortcode: AweBooking uses several shortcodes (e.g., [awe_booking_form], [awe_rooms]).
2. Setup Page: Create a page containing a common AweBooking shortcode to ensure scripts are enqueued.

   wp post create --post_type=page --post_status=publish --post_title="Booking" --post_content='[awe_booking_form]'
   

3. Locate Nonce Key: Search the plugin code for wp_localize_script. Look for the variable name and the nonce key.
   • Search command: grep -r "wp_localize_script" .
   • Likely Variable: awebooking_params or awe_params.
   • Likely Key: awe_nonce or ajax_nonce.
4. Extract via Browser:
   Navigate to the created page as the Subscriber user.

   // Proposed browser_eval
   window.awebooking_params?.ajax_nonce || window.awe_params?.nonce
   

5. Exploitation Strategy

Once the action and nonce are identified:

1. Target Identification: Use grep to find all wp_ajax_ actions that do not contain manage_options or current_user_can.

   grep -rn "add_action.*wp_ajax_" .
   

2. HTTP Request (Example):
   Using the http_request tool, send a POST to the identified action.
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Method: POST
   • Headers: Content-Type: application/x-www-form-urlencoded, Cookie: [Subscriber Cookies]
   • Body: action=awe_get_customer_info&nonce=[NONCE]&id=1 (ID 1 is usually the admin).

6. Test Data Setup

1. Install Plugin: Ensure AweBooking 3.2.26 is active.
2. Create Admin Data: Ensure the Admin user (ID 1) has a full profile (first name, last name, email).
3. Create Subscriber: Create a user with the 'subscriber' role.

   wp user create attacker attacker@example.com --role=subscriber --user_pass=password
   

4. Create a Booking (Optional): If the exposure is booking-related, create a test booking.

7. Expected Results

A successful exploit will result in a 200 OK response with a JSON body containing information that a Subscriber should not see.

• Example Response:

  {
    "success": true,
    "data": {
      "user_login": "admin",
      "user_email": "admin@example.com",
      "user_pass": "$P$B...", 
      "display_name": "Administrator"
    }
  }
  

• Or Booking Info: Exposure of PII (Personally Identifiable Information) of other guests.

8. Verification Steps

1. Response Analysis: Check if the returned JSON contains the user_email or user_pass of a user other than the requester.
2. Manual Check: Compare the data in the JSON response against the output of:

   wp user get 1 --fields=user_login,user_email
   

   If the AJAX response matches the wp user get output for the admin, the exposure is confirmed.

9. Alternative Approaches

If the primary AJAX action is not vulnerable:

• Check REST API: Search for register_rest_route and check for missing permission_callback.
  grep -r "register_rest_route" .
• Check for IDOR in Settings: Look for functions like awe_get_option being called within an AJAX handler that accepts an option name as a parameter.
• Check Export Functions: Look for CSV or PDF export handlers that might be accessible via a direct URL or AJAX action.