Awesome Hotel Booking <= 1.0.3 - Incorrect Authorization to Unauthenticated Arbitrary Booking Modification

This research plan outlines the steps to investigate and exploit CVE-2025-14352, an Incorrect Authorization vulnerability in the Awesome Hotel Booking WordPress plugin (versions <= 1.0.3).

---

1. Vulnerability Summary

The Awesome Hotel Booking plugin suffers from a critical authorization flaw in its handling of booking modifications. Specifically, the shortcode handler defined in room-single.php (or included via that file) processes booking updates based solely on the presence of a valid WordPress nonce. It fails to implement any capability checks (e.g., current_user_can()) or ownership validation (verifying the requester is the owner of the booking ID being modified). Consequently, an unauthenticated attacker can obtain a nonce from a public-facing room page and use it to modify any booking record in the system.

2. Attack Vector Analysis

• Target Endpoint: The URL of a page containing the plugin's room shortcode (likely [hb_room_single] or [room_single]). Form submissions to this page trigger the vulnerable handler.
• Vulnerable Action: Modification of booking details (status, dates, or guest information).
• Authentication: None (Unauthenticated).
• Preconditions:
  1. The plugin is active and at least one room is published.
  2. A valid booking ID is known (usually enumerable via incrementing integers).
  3. A nonce for the booking action is obtainable from the public room page.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers a shortcode (likely [hb_room_single]) which maps to a rendering function.
2. Handler Execution: Inside the shortcode function (possibly in room-single.php or an associated controller), code checks if a specific POST parameter exists (e.g., $_POST['action'] == 'hb_modify_booking').
3. Security Check (Weak): The code calls wp_verify_nonce($_POST['hb_nonce'], 'hb_booking_action') (inferred identifiers).
4. Authorization Failure: No check follows to ensure the current user is an admin or the owner of the booking_id.
5. Sink: The code calls a database update or a plugin-specific method (e.g., $booking->update()) using the booking_id and other parameters supplied in the POST request.

4. Nonce Acquisition Strategy

Because the vulnerability exists in a shortcode handler meant for public interaction (booking a room), the plugin must expose a nonce to unauthenticated visitors.

1. Identify the Shortcode: Search for the shortcode tag: grep -rn "add_shortcode" .
2. Create a Public Page:

   wp post create --post_type=page --post_title="Room Page" --post_status=publish --post_content='[hb_room_single id="1"]'
   

3. Navigate and Extract: Use the browser to load the page and locate the nonce field or localized JavaScript variable.
   • Check Form Fields: Look for <input type="hidden" name="..." value="...">.
   • Check JS Localization: The plugin likely uses wp_localize_script.
   • Automation:

     // Example browser_eval to find a nonce in localized data
     // Search for keys like 'hb_nonce', 'booking_nonce', or 'awesome_hotel_nonce'
     browser_eval("window.hb_booking_params?.nonce || document.querySelector('input[name*=\"nonce\"]')?.value")
     

5. Exploitation Strategy

The goal is to modify an existing booking (e.g., change its status or customer name) by spoofing the submission that the shortcode handler expects.

Step-by-Step:

1. Discovery: Create a test booking as a normal user (or via WP-CLI) to identify the target booking_id.

2. Nonce Capture: Fetch the room page and extract the nonce using the strategy in Section 4.

3. Craft Payload: Construct a POST request.

   • URL: http://vulnerable-site.local/room-page/
   • Method: POST
   • Content-Type: application/x-www-form-urlencoded
   • Parameters (Inferred):
     • hb_action: update_booking
     • hb_booking_id: [TARGET_BOOKING_ID]
     • hb_nonce: [EXTRACTED_NONCE]
     • hb_status: cancelled (or confirmed)
     • hb_customer_name: Attacker Was Here

4. Execute: Use http_request to send the payload.

6. Test Data Setup

To reliably test the exploit, the environment must have a booking to modify.

1. Install Plugin: Ensure Awesome Hotel Booking <= 1.0.3 is active.
2. Create Room: Create a room to make the shortcode functional.
3. Create Target Booking:

   # Use WP-CLI to create a booking directly in the database or via plugin functions
   # (Assuming the plugin uses a custom table 'wp_hb_bookings')
   wp db query "INSERT INTO wp_hb_bookings (customer_name, status, room_id) VALUES ('Legitimate Guest', 'pending', 1);"
   

4. Create Page: Place the room shortcode on a public page to enable nonce extraction.

7. Expected Results

• Response: The server returns a 200 OK or 302 Redirect.
• State Change: The database record for the target booking_id is updated with the attacker-supplied values (e.g., status changed to "cancelled" or customer name changed).

8. Verification Steps

After sending the POST request, verify the modification using WP-CLI:

# Check the specific booking record
wp db query "SELECT * FROM wp_hb_bookings WHERE id = [TARGET_BOOKING_ID];"

Confirm that customer_name or status matches the payload sent in the exploit.

9. Alternative Approaches

If the shortcode handler requires specific state (like a session cookie), try:

1. Session-Linked Exploitation: Visit the page first via browser_navigate to establish any necessary session cookies, then use browser_eval to perform a fetch() request with the nonce, ensuring the browser's cookie context is included.
2. AJAX Endpoint: If the shortcode uses AJAX rather than standard POST, target admin-ajax.php with the action parameter found in the plugin's wp_ajax_nopriv_ registrations.
   • grep -rn "wp_ajax_nopriv_" . to find unauthenticated AJAX actions.