Exploitation Research Plan: CVE-2025-31413 (CSRF in Element Pack Elementor Addons)

1. Vulnerability Summary

The Element Pack Elementor Addons plugin (<= 8.3.13) contains a Cross-Site Request Forgery (CSRF) vulnerability. This issue arises from a failure to correctly implement or verify WordPress nonces on administrative AJAX actions. Specifically, certain handlers intended for managing plugin settings or module statuses either omit the check_ajax_referer call entirely or use it with the die parameter set to false without subsequently checking the return value. This allows an unauthenticated attacker to perform sensitive configuration changes by tricking a logged-in administrator into visiting a malicious link or form.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Vulnerable Action: element_pack_settings_save or ep_module_toggle (inferred; based on common patterns in this plugin's administrative interface).
• HTTP Method: POST
• Payload Parameter: action, settings_data (or individual setting keys), and potentially a dummy or missing security/nonce parameter.
• Authentication Level: Requires an active Administrator session (exploited via CSRF).
• Preconditions: The victim must be logged in as an administrator.

3. Code Flow

1. The plugin registers AJAX handlers during init or admin_init hooks, typically within the includes/class-element-pack-admin.php or similar administrative controller.
2. An action like wp_ajax_element_pack_settings_save is mapped to a callback function (e.g., save_settings_callback).
3. Inside the callback, the code likely checks for current_user_can('manage_options') but fails to strictly validate a nonce using check_ajax_referer('element-pack-settings', 'security').
4. If check_ajax_referer is used with $die = false, and the return value is ignored, execution continues to the sink.
5. Sink: The user-supplied data in $_POST is passed to update_option() or update_site_option(), allowing modification of plugin behaviors (e.g., enabling/disabling security features, changing API keys, or modifying layout settings).

4. Nonce Acquisition Strategy

If the plugin attempts "incorrect" nonce validation (e.g., using a mismatched action string or an improperly localized nonce), we need to identify the localization key.

1. Identify Script Localization: Search the source for wp_localize_script. Look for the variable name used to pass data to the admin dashboard.
   • Likely Variable: element_pack_config (inferred).
   • Likely Key: ajax_nonce or nonce (inferred).
2. Create Trigger Content: Element Pack nonces are often only loaded on the plugin's settings page. To extract one:
   • wp post create --post_type=page --post_status=publish --post_title="EP Admin" --post_content='[element-pack-some-widget]' (Note: In CSRF, the admin's browser already has the nonce if they are on the settings page, but for PoC verification, we navigate there).
3. Extraction via Browser:

   // Using browser_eval to find the localized nonce
   const nonce = window.element_pack_config?.ajax_nonce || 
                 window.element_pack_admin_config?.security;
   

4. Bypass Analysis: If check_ajax_referer is called with $die = false and the result is not checked, the strategy is simply to provide any value or omit the parameter.

5. Exploitation Strategy

We will simulate a CSRF attack by performing a POST request from the "attacker" context while the agent holds admin session cookies.

Step 1: Identify the vulnerable action
The agent should first search for wp_ajax_ registrations in the plugin directory:
grep -rn "wp_ajax_" .

Step 2: Construct the CSRF Payload
Assuming the vulnerable action is element_pack_save_settings:

• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Content-Type: application/x-www-form-urlencoded
• Body:

  action=element_pack_save_settings&security=WRONG_NONCE&settings[some_critical_feature]=off
  

  Note: We test with WRONG_NONCE to confirm the "incorrect validation" aspect.

Step 3: Execution
Use http_request with the admin cookies to send the payload.

6. Test Data Setup

1. Plugin Activation: Ensure bdthemes-element-pack-lite is installed and active.
2. Initial State: Check the current value of a target option.
   • wp option get element_pack_active_modules
3. Admin Context: The agent must be authenticated as an admin (already standard in the test environment).

7. Expected Results

• HTTP Response: A 200 OK response, often containing {"success": true} or 1.
• Vulnerability Confirmation: The request succeeds even if the security or nonce parameter is invalid, expired, or missing.
• Impact: The targeted WordPress option (element_pack_*) is updated in the database.

8. Verification Steps

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

# Verify the option was changed
wp option get element_pack_active_modules

# Or check for a specific setting modified in the payload
wp option get bd_element_pack_settings

9. Alternative Approaches

• Mismatched Actions: If a nonce is checked, compare the action string in wp_create_nonce (localized) vs check_ajax_referer (in the handler). If they differ (e.g., element-pack-nonce vs element-pack-security), the check will fail for the intended use but might accept a default nonce (-1) or a nonce from a different part of the plugin.
• Admin Post Hook: Check if the settings are saved via admin-post.php instead of AJAX. Look for add_action('admin_post_...'). These are frequently missing CSRF protection compared to AJAX handlers.
• Grep for Weak Validation:
  grep -rn "check_ajax_referer.*false" .
grep -rn "wp_verify_nonce" . | grep -v "if"