Exploitation Research Plan: CVE-2026-2432 (CM Custom Reports)

1. Vulnerability Summary

The CM Custom Reports plugin (versions <= 1.2.7) is vulnerable to Stored Cross-Site Scripting (XSS). The vulnerability exists in the plugin's "Labels" settings, which allow administrators to customize text strings used throughout the plugin's interface. Because the plugin fails to sanitize these inputs when saved to the database and fails to escape them when rendered back to the UI, an attacker with administrative privileges can inject arbitrary JavaScript.

While administrators typically have the unfiltered_html capability, this vulnerability is significant in WordPress Multisite environments or installations where DISALLOW_UNFILTERED_HTML is defined, as it allows an administrator to bypass these security restrictions and execute scripts in the context of other users (including Super Admins).

2. Attack Vector Analysis

• Vulnerable Endpoint: Admin Settings Page (likely admin.php?page=cmcr_settings or similar).
• Vulnerable Tab: "Labels" tab.
• Payload Carrier: POST parameters corresponding to label fields (e.g., cmcr_labels[some_label_key]).
• Authentication: Required (Administrator+).
• Preconditions: unfiltered_html must be disabled for the user (e.g., via Multisite or configuration) to demonstrate a privilege escalation/security bypass, though the vulnerability exists regardless.

3. Code Flow (Inferred)

1. Registration: The plugin registers a settings page using add_submenu_page() under the cm-custom-reports menu.
2. Input Handling: On the "Labels" tab, the plugin provides a form. When the form is submitted, a handler (likely hooked to admin_init or admin_post) processes the $_POST data.
3. Persistence: The handler likely iterates through the labels and saves them using update_option(). It fails to apply sanitize_text_field() or wp_kses() to the label values.
4. Output: When the settings page or a report page is loaded, the plugin retrieves the labels using get_option().
5. Sink: The retrieved labels are echoed directly into the HTML without using esc_html() or esc_attr().

4. Nonce Acquisition Strategy

To save settings, the plugin will require a WordPress nonce to prevent CSRF.

1. Identify Page: Navigate to the CM Custom Reports settings page. The slug is likely cmcr_settings or cm-custom-reports-settings.
2. Access Page: Use the browser_navigate tool to go to http://localhost:8080/wp-admin/admin.php?page=cmcr_settings.
3. Extract Nonce: CM plugins typically wrap their settings in a form that includes a standard WordPress nonce field.
4. JS Extraction:
   • Use browser_eval to find the nonce:
     browser_eval("document.querySelector('input[name=\"_wpnonce\"]')?.value")
   • Also, check for specific CM localization objects:
     browser_eval("window.cmcr_settings?.nonce") (inferred)

5. Exploitation Strategy

The goal is to store an XSS payload in a label and trigger it by viewing the settings page.

Step 1: Discover the Settings Form

Navigate to the settings page and inspect the "Labels" tab to identify the exact POST keys.

• URL: /wp-admin/admin.php?page=cmcr_settings (inferred)
• Tool: browser_navigate

Step 2: Submit XSS Payload

Submit a POST request to the settings handler. Based on CM plugin patterns, this is often a direct POST to the same settings page or options.php.

• Target URL: http://localhost:8080/wp-admin/admin.php?page=cmcr_settings
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body Parameters (Inferred):
  • _wpnonce: [Extracted Nonce]
  • action: update
  • cmcr_labels[report_header]: <script>alert("XSS_STORED")</script>
  • save: Save Changes

Step 3: Trigger Payload

Navigate back to the settings page or any page where the labels are rendered.

• URL: /wp-admin/admin.php?page=cmcr_settings
• Tool: browser_navigate

6. Test Data Setup

1. User: Ensure an Administrator user exists.
2. Hardening: To prove the vulnerability's impact, disable unfiltered_html for the admin:
   • wp-config.php: define( 'DISALLOW_UNFILTERED_HTML', true );
3. Plugin State: Ensure CM Custom Reports (<= 1.2.7) is installed and activated.

7. Expected Results

• The HTTP response for the settings save should indicate a redirect (302) or success message.
• Upon navigating to the settings page, an alert box with XSS_STORED should appear.
• The page source should contain the literal string <script>alert("XSS_STORED")</script>.

8. Verification Steps

1. Database Check: Use WP-CLI to check the stored option:
   wp option get cmcr_labels (inferred option name)
   Verify that the output contains the raw <script> tag.
2. Source Check: Verify the rendered output via the browser:
   browser_eval("document.body.innerHTML.includes('<script>alert')")

9. Alternative Approaches

• AJAX Handler: If the plugin saves via AJAX, look for a wp_ajax_cmcr_save_labels action in the source code.
• Report Rendering: If the XSS does not fire on the admin settings page, try viewing a generated report where the labels might be used as headers.
• Attribute Breakout: If the payload is rendered inside an input value, use: "><script>alert(1)</script> or x" onmouseover="alert(1).