Appointment Booking Plugin for WooCommerce – WpBookingly | All-in-One Service Manager <= 1.2.9 - Missing Authorization

This research plan targets CVE-2026-25444, a missing authorization vulnerability in the WpBookingly (service-booking-manager) plugin for WordPress. This vulnerability allows authenticated users with Contributor-level access to execute unauthorized actions.

---

1. Vulnerability Summary

The Appointment Booking Plugin for WooCommerce – WpBookingly (versions <= 1.2.9) fails to implement proper authorization checks (e.g., current_user_can()) in one or more of its AJAX handler functions. While the plugin may check if a user is logged in (via the wp_ajax_ hook registration), it does not verify if the logged-in user possesses the necessary administrative capabilities to perform sensitive operations, such as modifying plugin settings or managing booking data.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Authentication: Authenticated, Contributor-level role (PR:L).
• Vulnerable Action: An AJAX action registered via add_action( 'wp_ajax_...', ... ) that lacks a capability check.
• Target Functionality: Likely candidate functions include settings updates, service management, or staff management (e.g., wpbookingly_save_settings, wpbookingly_delete_service).
• Preconditions: The plugin must be active, and a valid nonce must be obtained (if enforced).

3. Code Flow (Inferred)

1. Entry Point: The attacker sends a POST request to admin-ajax.php with a specific action parameter.
2. Hook Trigger: WordPress triggers the corresponding wp_ajax_{action} hook.
3. Vulnerable Callback: The callback function (likely in an AJAX or Admin class) is executed.
4. Missing Check: The function may call check_ajax_referer() (verifying the nonce) but fails to call current_user_can( 'manage_options' ) or a similar check.
5. Sink: The function proceeds to update the database via update_option(), $wpdb->update(), or $wpdb->delete().

4. Nonce Acquisition Strategy

The plugin likely localizes a nonce for its admin interface. To obtain this as a Contributor:

1. Identify the Script Handle: Search for wp_localize_script in the plugin code to find the JS object name.
2. Locate the Page: Find an admin page accessible to Contributors where the plugin scripts are loaded. If the plugin only loads scripts on its own settings page (usually restricted), check if scripts are loaded on the Dashboard or Profile page.
3. Execution:
   • Log in as a Contributor.
   • Navigate to /wp-admin/index.php.
   • Use browser_eval to search for the nonce:

     // Common patterns for this plugin (inferred)
     window.wpbookingly_ajax?.nonce || window.wp_bookingly_vars?.security
     

   • Verification: Grep the source for wp_create_nonce to identify the exact action string and the variable name used in wp_localize_script.

5. Exploitation Strategy

Discovery Phase (Automated Agent)

Before sending the exploit, the agent must identify the specific vulnerable action:

1. grep -rn "add_action( 'wp_ajax_" . inside the plugin directory.
2. Inspect the callback functions for those actions. Look for any function that does not contain the string current_user_can.
3. Target actions related to settings, save, delete, or update.

Exploit Step: Unauthorized Option Update (Example)

• Action: wpbookingly_save_settings (inferred)
• Method: POST
• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Payload:

  action=wpbookingly_save_settings&nonce=[NONCE]&option_name=users_can_register&option_value=1
  

  (Note: If the function updates plugin-specific settings, target a setting that impacts security, such as an "authorized roles" setting or a redirect URL.)

6. Test Data Setup

1. Install Plugin: Install WpBookingly version 1.2.9.
2. Create User:

   wp user create attacker attacker@example.com --role=contributor --user_pass=password
   

3. Identify Plugin Setting: Find a plugin setting to toggle for verification (e.g., wpbookingly_booking_mode).

7. Expected Results

• Successful Exploit: The server returns a success response (e.g., {"success":true} or 1).
• Database Change: The targeted setting or data is modified in the wp_options or plugin-specific table.
• Bypass: The action is completed despite the user only having contributor permissions.

8. Verification Steps

After the http_request, verify the change using WP-CLI:

# Check if a global option was changed
wp option get wpbookingly_settings

# Check if a specific service was deleted/modified
wp db query "SELECT * FROM wp_wpbookingly_services"

9. Alternative Approaches

If the wpbookingly_save_settings action is protected or doesn't exist, search for:

• Export/Download Actions: Look for wp_ajax_wpbookingly_export_bookings. This could lead to unauthorized data disclosure (CVSS:C).
• Staff/Service Management: Look for wp_ajax_wpbookingly_delete_staff. This allows a Contributor to delete staff members or services, causing a Denial of Service for the booking system.
• Check for Nonce Reuse: If the nonce check is missing entirely (not just the capability check), the attack can be performed as a CSRF. Check if check_ajax_referer is missing in the identified callback.