Plugin Optimizer <= 1.3.7 - Missing Authorization

This research plan targets CVE-2025-68861, a Missing Authorization vulnerability in the "Plugin Optimizer" WordPress plugin. As an expert security researcher, I have structured this plan to guide an automated agent through the process of identifying the vulnerable code path and executing a Proof-of-Concept (PoC) exploit.

---

1. Vulnerability Summary

The Plugin Optimizer plugin (<= 1.3.7) fails to implement capability checks on certain AJAX registered actions. While WordPress automatically handles authentication for wp_ajax_ hooks, it does not enforce authorization (permissions). Consequently, any logged-in user (including those with the subscriber role) can trigger functions intended only for administrators. This typically results in unauthorized modification of plugin settings, which in this context could allow an attacker to disable essential plugins site-wide or on specific pages, potentially bypassing security controls or causing a Denial of Service (DoS).

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Vulnerable Action: po_save_settings or plugin_optimizer_save_rules (inferred from plugin functionality).
• Authentication: Authenticated (Subscriber level required).
• Authorization: Missing current_user_can('manage_options') check in the AJAX callback.
• Payload Type: application/x-www-form-urlencoded or JSON within a POST request.
• Target Parameter: Likely an array or JSON object containing plugin slugs and their enabled/disabled status.

3. Code Flow (Inferred)

1. Registration: The plugin uses add_action( 'wp_ajax_...', 'callback' ) during initialization (likely in an admin_init or init hook).
2. Entry Point: An authenticated user sends a POST request to admin-ajax.php with action=[vulnerable_action].
3. Missing Guard: The callback function is invoked. It may call check_ajax_referer() for CSRF protection but lacks a call to current_user_can().
4. Sink: The function processes the input and calls update_option() or update_post_meta() to save the modified plugin optimization rules.

4. Nonce Acquisition Strategy

The plugin likely uses wp_localize_script to pass a nonce to its administrative interface. Even if a Subscriber cannot access the "Plugin Optimizer" settings page directly, the script might be enqueued on all admin pages or the dashboard.

1. Identify Localization: Look for wp_localize_script in the plugin source code.
   • Grep target: grep -r "wp_localize_script" .
   • Likely JS Variable: po_vars or plugin_optimizer_data.
   • Likely Nonce Key: nonce or security.
2. Identify Nonce Action: Look for wp_create_nonce to find the action string.
   • Grep target: grep -r "wp_create_nonce" .
3. Extraction Method:
   • The agent should login as a Subscriber.
   • Navigate to the WordPress Dashboard (/wp-admin/index.php).
   • Use browser_eval to extract the nonce:
     browser_eval("window.po_vars?.nonce || window.plugin_optimizer_data?.security")

5. Exploitation Strategy

The goal is to modify the plugin's configuration to disable a target plugin (e.g., a security plugin like Wordfence or the Plugin Optimizer itself) across the site.

Step-by-Step:

1. Discovery: Determine the exact AJAX action and parameter structure by searching the source for add_action('wp_ajax_.
2. Preparation: Note the slug of a plugin to "disable" (e.g., wordfence/wordfence.php).
3. Execution: Send the following request via the http_request tool:

POST /wp-admin/admin-ajax.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

action=po_save_settings&security=[EXTRACTED_NONCE]&settings[wordfence/wordfence.php][disabled]=1&settings[wordfence/wordfence.php][active]=0

(Note: Parameter names settings, disabled, and active are inferred and must be verified against the source code or by observing a legitimate admin request.)

6. Test Data Setup

1. Target Plugin: Ensure at least one other plugin is active (e.g., akismet).
2. Attacker Account: Create a user with the subscriber role.
   • wp user create attacker attacker@example.com --role=subscriber --user_pass=password123
3. Plugin Configuration: Ensure Plugin Optimizer is active and functional.

7. Expected Results

• Response: The server should return a 200 OK response, often with a JSON body like {"success": true} or 1.
• Impact: The global configuration for Plugin Optimizer will be updated to include the attacker's malicious rules.
• Side Effect: The targeted plugin (e.g., Akismet) will no longer load on the frontend/backend as per the optimization rules.

8. Verification Steps

After the HTTP request, verify the database state using WP-CLI:

1. Check Options Table:
   wp option get po_settings or wp option get plugin_optimizer_rules
2. Verify Content: Confirm that the output contains the slug of the plugin you attempted to disable and that its status is set to disabled or equivalent.
3. Frontend Check: If possible, check the homepage source code to see if the targeted plugin's assets are no longer being loaded.

9. Alternative Approaches

• Parameter Guessing: If the AJAX action is found but the parameter structure is unclear, search the plugin's assets/js/ directory for the code that constructs the jQuery.ajax call. Look for keywords like JSON.stringify or data: {.
• REST API: Check if the plugin registers any REST routes via register_rest_route. If it does, check for the permission_callback parameter. If it is set to __return_true or is missing, the REST API may be a secondary vector.
• Settings Save: Some plugins use the admin_init hook to listen for $_POST variables directly. Search for isset($_POST['po_save']) in the code. If found, this can often be triggered by any user visiting any admin page if the capability check is missing.