SiteLock Security <= 5.0.2 - Missing Authorization

This research plan outlines the steps to identify and exploit CVE-2026-24532, a missing authorization vulnerability in the SiteLock Security plugin.

1. Vulnerability Summary

The SiteLock Security plugin (up to 5.0.2) fails to implement proper capability checks (e.g., current_user_can( 'manage_options' )) on one or more of its AJAX handlers. While these handlers are registered for authenticated users via wp_ajax_{action}, they lack an internal check to ensure the user has administrative privileges. This allows any authenticated user, including those with the Subscriber role, to perform actions intended only for administrators, such as modifying security settings, clearing logs, or triggering scans.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Method: POST
• Authentication: Authenticated (Subscriber-level minimum)
• Vulnerable Action: Likely prefixed with sitelock_ or sl_. Based on typical plugin architecture, candidates include:
  • sitelock_save_settings
  • sitelock_trigger_scan
  • sitelock_hardening_action
• Payload Parameter: action, nonce, and specific setting parameters (e.g., option_name, option_value).

3. Code Flow (Inferred)

1. Registration: The plugin uses add_action( 'wp_ajax_...', 'callback_function' ) in its initialization class (likely includes/class-sitelock.php or admin/class-sitelock-admin.php).
2. Entry Point: admin-ajax.php receives a POST request with the action parameter.
3. Vulnerable Sink: The callback_function is invoked. It likely checks for a nonce using check_ajax_referer() but fails to call current_user_can().
4. Execution: The function proceeds to execute sensitive logic, such as update_option() or triggering a system command/scan.

4. Nonce Acquisition Strategy

The plugin likely localizes a nonce for its administrative dashboard. Even if the dashboard is restricted, the script might be enqueued on other pages or the nonce might be accessible to any logged-in user.

1. Identify Localized Variable: Look for wp_localize_script in the plugin source code.
   • Search Pattern: grep -r "wp_localize_script" wp-content/plugins/sitelock/
   • Target JS Object: Likely named sitelock_ajax or sl_vars.
2. Locate Triggering Page: Determine where the scripts are enqueued (e.g., the plugin settings page).
3. Extraction via Browser:
   • Create a Subscriber user.
   • Since a subscriber cannot access the admin settings page directly, check if the plugin enqueues the script on the dashboard (/wp-admin/index.php) or if the nonce is used for a shortcode-related feature.
   • If the nonce is generated for any logged-in user, use:
     browser_eval("window.sitelock_ajax?.nonce") (Replace sitelock_ajax with the actual identifier found).

5. Exploitation Strategy

We will attempt to disable a security feature or modify a setting.

• Step 1: Identify Action. Use grep to find all registered wp_ajax_ actions and check their callbacks for missing current_user_can.
  • grep -rn "add_action.*wp_ajax_" wp-content/plugins/sitelock/
• Step 2: Prepare Request.
  • URL: https://[target]/wp-admin/admin-ajax.php
  • Headers: Content-Type: application/x-www-form-urlencoded, Cookie: [Subscriber Cookies]
  • Body:

    action=[VULNERABLE_ACTION]&
    _ajax_nonce=[NONCE]&
    [SETTING_PARAM]=[MALICIOUS_VALUE]
    

• Example Payload (Hypothetical):
  If the action is sitelock_toggle_hardening:
  action=sitelock_toggle_hardening&feature=login_security&enabled=0&_ajax_nonce=abc123def4

6. Test Data Setup

1. Install Plugin: SiteLock Security version 5.0.2.
2. Configure: Enable "WP Hardening" or "Login Security" features as an Admin.
3. Create Attacker: Create a user with the subscriber role.
4. Verification Page: If the plugin requires the script to be loaded for a nonce to exist, create a page with a plugin-specific shortcode:
   wp post create --post_type=page --post_status=publish --post_content='[sitelock_scanner]' (Confirm shortcode via grep -r "add_shortcode")

7. Expected Results

• Success: The server returns a 200 OK or a JSON success message (e.g., {"success":true}).
• Impact: A security setting that was previously enabled is now disabled, or a system operation is triggered without permission.
• Bypass Confirmation: The action succeeds despite the user having only Subscriber permissions.

8. Verification Steps

After sending the HTTP request, use WP-CLI to verify the state change:

• Check Option: wp option get sitelock_settings (Compare before and after).
• Check Hardening Status: Use any CLI command provided by the plugin or inspect wp_options for relevant keys.
• Example: wp option get sitelock_hardening_login_security should return 0 if successfully disabled.

9. Alternative Approaches

• If Nonce is not required: Omit the nonce and check if check_ajax_referer is missing or called with die=false.
• Information Disclosure: Look for AJAX actions that return data (e.g., sitelock_get_logs). A successful exploit would return sensitive log data to the Subscriber.
• Setting Injection: Try to inject an arbitrary WordPress option if the handler uses a generic update_option($_POST['key'], $_POST['value']) pattern.