Exploitation Research Plan: CVE-2026-24539

1. Vulnerability Summary

The Protección de datos – RGPD plugin (<= 0.68) suffers from a Missing Authorization vulnerability. This occurs because one or more AJAX or REST API endpoints lack appropriate capability checks (e.g., current_user_can()) in their callback functions. Consequently, unauthenticated attackers can trigger sensitive plugin actions, such as modifying settings, altering policy page assignments, or manipulating consent data, by sending requests directly to the WordPress AJAX or REST API endpoints.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php (for AJAX actions) or /wp-json/ (for REST API).
• Vulnerable Action: Likely a wp_ajax_nopriv_ hook or a wp_ajax_ hook registered without internal authentication checks.
• Payload Parameter: Likely action (for AJAX) or specific setting fields (e.g., policy_page, banner_text).
• Authentication: Unauthenticated (PR:N).
• Preconditions: The plugin must be active.

3. Code Flow Discovery

To identify the specific vulnerable code path, the following discovery steps must be performed in the environment:

1. Identify AJAX Handlers:
   Search for all registered unauthenticated AJAX actions:

   grep -rn "wp_ajax_nopriv_" .
   

   Alternatively, check for registered authenticated AJAX actions that might lack capability checks:

   grep -rn "wp_ajax_" .
   

2. Analyze Callbacks:
   For each identified action (e.g., pdr_save_data or rgpd_update_config), examine the callback function in the source code.

   • Check for Authorization: Look for the absence of current_user_can( 'manage_options' ) or similar checks.
   • Check for Nonces: Look for check_ajax_referer() or wp_verify_nonce(). Note the action string and parameter name (e.g., security, nonce, _wpnonce).

3. Check for REST Routes:
   Search for REST API registrations:

   grep -rn "register_rest_route" .
   

   Verify if permission_callback is set to __return_true or is missing entirely.

4. Nonce Acquisition Strategy

If the vulnerable function requires a nonce (even if it lacks a capability check), follow this protocol:

1. Identify Localized Scripts:
   GDPR plugins often localize nonces for the front-end cookie banner. Search for wp_localize_script in the plugin code:

   grep -rn "wp_localize_script" .
   

   Identify the object name (e.g., rgpd_vars) and the nonce key (e.g., nonce).

2. Trigger Script Loading:
   The plugin likely enqueues scripts on the homepage or pages with a specific shortcode. Check the plugin for shortcodes:

   grep -rn "add_shortcode" .
   

   • Hypothetical Shortcode: [proteccion_datos_rgpd]

3. Extract via Browser:
   If a shortcode or global banner is found:

   • Create a test page: wp post create --post_type=page --post_status=publish --post_content='[SHORTCODE_NAME]'
   • Navigate to the page.
   • Use browser_eval to extract the nonce:

     window.OBJECT_NAME_FROM_LOCALIZE?.nonce_key
     

5. Exploitation Strategy

Assuming the vulnerability resides in an AJAX handler (common for this plugin type):

1. Target URL: http://localhost:8080/wp-admin/admin-ajax.php
2. Method: POST
3. Headers: Content-Type: application/x-www-form-urlencoded
4. Action Selection: Based on discovery, use the action that modifies plugin settings.
5. Payload (Example):
   • action=VULNERABLE_ACTION_NAME
   • nonce=EXTRACTED_NONCE (if applicable)
   • option_name_parameter=NEW_VALUE (e.g., changing the text of the cookie banner to include an XSS payload <script>alert(1)</script>)

6. Test Data Setup

1. Install and activate the plugin version 0.68.
2. Identify a setting that is visible on the site, such as the "Cookie Banner Text" or "Privacy Policy Page ID".
3. Note the current value using WP-CLI:

   wp option get rgpd_settings # (inferred option name)
   

7. Expected Results

• Response: The server should return a 200 OK or wp_send_json_success (usually {"success":true}).
• Impact: The setting targeted in the payload (e.g., banner_message) should be updated in the database without any administrator interaction.

8. Verification Steps

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

# Check the specific option modified by the exploit
wp option get [MODIFIED_OPTION_NAME]

# If the exploit changed a setting like the Privacy Policy Page ID:
wp option get rgpd_policy_page

9. Alternative Approaches

If no wp_ajax_nopriv_ hooks are sensitive:

• REST API: Check if GET /wp-json/proteccion-datos-rgpd/v1/... exists and lacks a permission_callback.
• Admin Init: Check if the plugin uses admin_init to process $_POST or $_GET requests without checking is_admin() or permissions. This often happens in legacy plugins that handle form submissions before the page renders.

  grep -rn "add_action.*admin_init" .
  

• Settings Save: Check if the plugin registers settings via register_setting but fails to provide a proper sanitize_callback or relies on an unauthenticated endpoint to update them.