Exploitation Research Plan: CVE-2026-32363 (WPLifeCycle Missing Authorization)

1. Vulnerability Summary

The WPLifeCycle plugin (versions <= 3.3.1) is vulnerable to Missing Authorization. The vulnerability exists because certain functions registered as AJAX handlers (or via other hooks) do not implement current_user_can() checks. This allows unauthenticated users to perform actions intended only for administrators. Given the CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, the impact is limited to Low Integrity, suggesting an attacker can modify specific plugin settings or site options without being logged in.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: Likely a hook registered with wp_ajax_nopriv_ (to allow unauthenticated access) that performs a state-changing operation (e.g., update_option).
• Parameter: An action parameter in a POST request, along with whatever data the vulnerable function expects (e.g., setting_name, value).
• Authentication: None (Unauthenticated).
• Preconditions: The plugin free-php-version-info must be active.

3. Code Flow (Inferred - Subject to verification by Agent)

1. Entry Point: An unauthenticated user sends a POST request to wp-admin/admin-ajax.php?action=[VULNERABLE_ACTION].
2. Hook Registration: The plugin likely contains code similar to:

   add_action('wp_ajax_nopriv_wpl_save_settings', 'wpl_save_settings_callback');
   add_action('wp_ajax_wpl_save_settings', 'wpl_save_settings_callback');
   

3. Vulnerable Callback: The callback function (e.g., wpl_save_settings_callback) likely processes $_POST data and calls update_option() or set_transient() without checking:
   • current_user_can('manage_options')
   • A valid WordPress nonce (via check_ajax_referer)
4. Sink: The update_option() function is called, modifying the database.

4. Nonce Acquisition Strategy

If the vulnerable function uses check_ajax_referer or wp_verify_nonce, a nonce must be extracted.

1. Identify Shortcodes/Pages: Search the plugin for add_shortcode. If the plugin displays PHP info on the frontend, it may enqueue scripts there.
2. Locate Nonce Localization: Search for wp_localize_script. Common keys might be wpl_ajax or wplifecycle_obj.
   • Example Search: grep -r "wp_localize_script" .
3. Extraction Process:
   • Create a page containing the plugin's shortcode: wp post create --post_type=page --post_status=publish --post_content='[wplifecycle_info]' (shortcode name is inferred).
   • Navigate to the page using browser_navigate.
   • Use browser_eval to find the nonce: browser_eval("window.wpl_ajax_obj?.nonce") (variable name is inferred).

Note: If the vulnerability is "Missing Authorization," it is highly probable that even if a nonce is present, the capability check is missing. If the nonce is also missing or the handler uses wp_ajax_nopriv_ without checking the result of check_ajax_referer(..., ..., false), exploitation is trivial.

5. Exploitation Strategy

The agent will follow these steps:

1. Discovery: Run grep -rn "wp_ajax_nopriv" wp-content/plugins/free-php-version-info/ to identify the specific action name.
2. Payload Identification: Inspect the identified callback function to see which parameters it accepts. Look for update_option, delete_option, or update_user_meta.
3. Request Construction: Send a POST request using http_request.
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Method: POST
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body: action=[FOUND_ACTION]&[PARAM]=[VALUE]
4. Target Setting: Aim to modify a setting that is visible in the WordPress admin or affects site behavior (e.g., changing a "dismissed notice" flag or a plugin-specific configuration).

6. Test Data Setup

1. Install/Activate Plugin: Ensure free-php-version-info version 3.3.1 is installed and active.
2. Initial State Check: Record the current value of the targeted option using WP-CLI.
   • Command: wp option get [target_option_name]

7. Expected Results

• Response: The HTTP request to admin-ajax.php should return a 200 OK or a JSON success message (e.g., {"success":true}).
• Database Change: The targeted option in the wp_options table should be updated to the attacker-supplied value.

8. Verification Steps

1. WP-CLI Verification: After the exploit attempt, verify the change in the database.
   • Command: wp option get [target_option_name]
2. State Comparison: Compare this value against the initial state recorded in Step 6. If they differ and match the payload, the exploit is successful.

9. Alternative Approaches

• Settings Loophole: If the plugin uses a generic save_settings function that takes an array of options, try to overwrite core WordPress options (e.g., users_can_register) if the plugin doesn't whitelist which options can be updated.
• REST API: Check if the plugin also registers REST API routes without permission_callback by searching for register_rest_route.
• Init-based handling: If no AJAX actions are found, search for add_action('init', ...) or add_action('admin_init', ...) that checks for a specific $_GET or $_POST parameter without checking capabilities.