iGMS Direct Booking <= 1.3 - Missing Authorization

This research plan outlines the steps to identify and exploit the Missing Authorization vulnerability (CVE-2026-39652) in the iGMS Direct Booking plugin.

1. Vulnerability Summary

The iGMS Direct Booking plugin (up to version 1.3) suffers from a Missing Authorization vulnerability. This occurs when an administrative or sensitive function is registered via a WordPress hook (typically AJAX or a general initialization hook) but fails to verify if the requesting user has the necessary privileges (e.g., current_user_can('manage_options')). Because it may also be registered via wp_ajax_nopriv_, unauthenticated attackers can trigger these functions to perform unauthorized actions such as modifying plugin settings or manipulating booking data.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Vulnerable Action: To be identified, but likely an AJAX action registered with wp_ajax_nopriv_ prefix.
• Payload Parameter: Likely a $_POST array containing settings or configuration data.
• Authentication: None required (Unauthenticated).
• Preconditions: The plugin must be active. If a nonce is required, it must be leaked via the frontend.

3. Code Flow (Inferred Audit Path)

1. Entry Point Identification: The plugin registers AJAX handlers in its main file or an inclusion file (e.g., includes/class-igms-db-ajax.php or similar).
   • Grep Command: grep -rn "wp_ajax_nopriv_" wp-content/plugins/igms-direct-booking/
2. Handler Analysis: For every unauthenticated AJAX action found, locate the callback function.
   • Search Pattern: add_action( 'wp_ajax_nopriv_[ACTION_NAME]', [ $this, '[FUNCTION_NAME]' ] );
3. Authorization Check Audit: Inspect the identified [FUNCTION_NAME] for a call to current_user_can(). If the function modifies options or database state and lacks this check, it is vulnerable.
   • Critical Sinks: update_option(), wp_insert_post(), $wpdb->insert(), $wpdb->update().

4. Nonce Acquisition Strategy

If the vulnerable function uses check_ajax_referer() or wp_verify_nonce(), follow this strategy:

1. Locate Nonce Creation: Search for wp_create_nonce in the plugin source to find the action string.
   • Grep: grep -rn "wp_create_nonce" wp-content/plugins/igms-direct-booking/
2. Locate Localization: Find where this nonce is passed to the frontend.
   • Search: wp_localize_script( ... )
3. Identify Trigger: Determine which shortcode or page enqueues the script containing the nonce. Look for add_shortcode in the source.
   • Shortcode Example (Inferred): [igms_booking_form]
4. Extraction:
   • Create a page: wp post create --post_type=page --post_status=publish --post_content='[igms_booking_form]'
   • Navigate to the page using browser_navigate.
   • Extract the nonce using browser_eval:

     // Example JS path based on typical localization
     window.igms_booking_data?.nonce || window.igms_vars?.ajax_nonce
     

5. Exploitation Strategy

Once the vulnerable action and required parameters are identified:

1. Identify Parameters: Look for the keys in $_POST used by the vulnerable function (e.g., igms_settings, api_key, property_id).
2. Craft Request: Use the http_request tool to send a POST request.
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Method: POST
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body: action=[VULNERABLE_ACTION]&_ajax_nonce=[NONCE]&[PARAM]=[VALUE]
3. Example Target (Hypothetical):
   If the action is igms_save_config and it updates the igms_api_key option:
   • action=igms_save_config&api_key=EVIL_KEY_123&nonce=[EXTRACTED_NONCE]

6. Test Data Setup

1. Install Plugin: Ensure iGMS Direct Booking v1.3 is installed and active.
2. Identify Shortcodes: List shortcodes to find a candidate for nonce leakage:
   • grep -rn "add_shortcode" wp-content/plugins/igms-direct-booking/
3. Create Test Page:
   • wp post create --post_type=page --post_title="Booking" --post_status=publish --post_content='[SHORTCODE_FOUND]'

7. Expected Results

• Success Indicator: The server returns a 200 OK response, often with a JSON body indicating success (e.g., {"success": true}).
• Data Impact: Plugin settings are modified, or a new booking record is created without valid user credentials.

8. Verification Steps

After sending the exploit request, verify the change using WP-CLI:

1. Check Options: If the exploit modified settings:
   • wp option get igms_settings (Verify if values match the payload).
2. Check Database: If the exploit created data:
   • wp db query "SELECT * FROM wp_options WHERE option_name LIKE 'igms_%'"
   • wp post list --post_type=igms_booking (if bookings are CPTs).

9. Alternative Approaches

• Initialization Hooks: If no unauthenticated AJAX is found, check for admin_init or init hooks that process $_POST without capability checks.
  • Search: grep -rn "add_action( 'admin_init'" wp-content/plugins/igms-direct-booking/
• Direct Option Update: If the plugin uses register_setting incorrectly without a proper sanitize_callback or permission_callback, it might be possible to update options via options.php (though this usually requires authentication, check for nopriv wrappers).
• REST API: Check for registered REST routes that lack the permission_callback argument.
  • Search: register_rest_route in the plugin directory.