Private WP suite <= 0.4.1 - Authenticated (Administrator+) Stored Cross-Site Scripting via 'Exceptions' Setting

This research plan outlines the steps required to demonstrate Stored Cross-Site Scripting (XSS) in the Private WP suite plugin via the 'Exceptions' setting.

1. Vulnerability Summary

The Private WP suite plugin (<= 0.4.1) allows administrators to define "Exceptions"—specific URLs or pages that remain public even when the rest of the site is restricted. The plugin fails to sanitize this input when saving it to the database and fails to escape it when rendering it back into the admin settings page (and potentially on the frontend). In environments where unfiltered_html is disabled (like WordPress Multisite), this allows an administrator to inject malicious JavaScript that will execute in the context of any user (including Super Admins) who visits the settings page.

2. Attack Vector Analysis

• Endpoint: /wp-admin/options.php (Standard WordPress Settings API endpoint).
• Vulnerable Parameter: private_wp_suite_options[exceptions] (inferred based on standard plugin naming conventions).
• Authentication: Requires Administrator-level privileges.
• Preconditions: The plugin must be active. To demonstrate the security impact, unfiltered_html should ideally be disabled (e.g., via define( 'DISALLOW_UNFILTERED_HTML', true ); in wp-config.php), though the payload will work regardless of this setting if the code is unescaped.

3. Code Flow (Inferred)

1. Entry (Admin UI): The administrator visits the plugin settings page (typically registered via add_options_page or add_menu_page in an admin class).
2. Registration: The plugin uses register_setting( 'private_wp_suite_settings', 'private_wp_suite_options', ... ).
3. Sink (Saving): When the form is submitted to options.php, WordPress calls the update_option logic. If the sanitize_callback is missing or insufficient (e.g., just trim), the XSS payload is stored in the wp_options table.
4. Source (Rendering): The settings page callback (e.g., settings_page_output) retrieves the option using get_option( 'private_wp_suite_options' ).
5. Execution: The value of the exceptions key is echoed inside a <textarea> or <div> without using esc_textarea() or esc_html(). An attacker can close the tag (e.g., </textarea>) and inject a <script> tag.

4. Nonce Acquisition Strategy

The Settings API protects form submissions using a nonce.

1. Identify Page: The settings page is likely at /wp-admin/options-general.php?page=private-wp-suite.
2. Navigate: Use browser_navigate to reach this page.
3. Extract Nonce: Use browser_eval to extract the _wpnonce and option_page fields from the HTML form.
   • option_page: The value of input[name="option_page"].
   • _wpnonce: The value of input[name="_wpnonce"].
4. JavaScript Extraction:

   (() => {
       return {
           nonce: document.querySelector('input[name="_wpnonce"]')?.value,
           option_page: document.querySelector('input[name="option_page"]')?.value,
           settings_field_name: document.querySelector('textarea[name*="exceptions"]')?.name 
       };
   })()
   

5. Exploitation Strategy

1. Preparation: Log in as Administrator.
2. Information Gathering:
   • Navigate to the Private WP suite settings page.
   • Identify the exact name of the textarea for "Exceptions". It is likely private_wp_suite_options[exceptions].
   • Extract the _wpnonce.
3. Execution (Payload Injection):
   • Send a POST request to /wp-admin/options.php.
   • Payload: </textarea><script>alert(document.domain + " - XSS")</script>
   • Request Details:
     • Method: POST
     • URL: http://localhost:8080/wp-admin/options.php
     • Content-Type: application/x-www-form-urlencoded
     • Body:

       option_page=[EXTRACTED_OPTION_PAGE]&
       action=update&
       _wpnonce=[EXTRACTED_NONCE]&
       private_wp_suite_options[exceptions]=</textarea><script>alert(window.origin)</script>
       

4. Triggering: Navigate back to the settings page. The script should execute immediately.

6. Test Data Setup

1. Plugin Installation: Install and activate private-wp-suite version 0.4.1.
2. Environment Check: Ensure the user has the Administrator role.
3. (Optional) Harden Environment: Add define( 'DISALLOW_UNFILTERED_HTML', true ); to wp-config.php to prove the bypass of intended WordPress security restrictions.

7. Expected Results

• Upon submitting the POST request, the server should return a 302 redirect back to the settings page with a settings-updated=true parameter.
• When the browser loads the settings page, an alert box showing the origin/domain should appear.
• The HTML source of the page will show the payload rendered raw:

  <textarea ...></textarea><script>alert(window.origin)</script></textarea>
  

8. Verification Steps

1. CLI Check: Verify the option value in the database:
   wp option get private_wp_suite_options
   Check if the exceptions key contains the <script> payload.
2. Browser Verification: Use browser_navigate to the settings page and check for the presence of the script in the DOM or use browser_eval to check if a global variable set by the script exists.

9. Alternative Approaches

• Action-based XSS: If the "Exceptions" are used on the frontend to determine access, check if the payload triggers for unauthenticated visitors when they access the site.
• Bypass through different fields: If exceptions is sanitized, check other settings fields like "Login Page Message" or custom redirect URLs, which often suffer from the same lack of escaping.
• XSS via Attribute Injection: If the payload is rendered inside an input value attribute instead of a textarea, use: " onmouseover="alert(1)" type="text.