Research Plan: CVE-2025-15396 - Library Viewer Reflected XSS

1. Vulnerability Summary

The Library Viewer plugin for WordPress is vulnerable to Reflected Cross-Site Scripting (XSS) in versions prior to 3.2.0. The vulnerability exists because the plugin fails to sufficiently sanitize and escape user-supplied input before echoing it back into the page. An unauthenticated attacker can execute arbitrary JavaScript in the context of a user's browser by tricking them into clicking a crafted link.

2. Attack Vector Analysis

• Endpoint: Any frontend page where the Library Viewer plugin is active (typically via a shortcode) or a specific plugin-generated view.
• Vulnerable Parameter: Likely a query parameter used for filtering, pagination, or specifying a document/library ID (e.g., lib_id, category, search, or paged). (Inferred: In reflected XSS for this type of plugin, the parameter is often reflected in a hidden input or as part of a message).
• Authentication: None (Unauthenticated).
• Preconditions: The plugin must be installed and active. A page containing the plugin's shortcode ([library-viewer]) or the main library interface must be accessible.

3. Code Flow

1. Entry Point: The user requests a URL with a malicious query parameter: example.com/library/?lib_search=<script>alert(1)</script>.
2. Processing: The plugin's frontend handler (often in public/class-library-viewer-public.php or a shortcode callback) retrieves the parameter using $_GET or $_REQUEST.
3. Reflection: The plugin uses the raw value of the parameter in an echo or printf statement within the HTML output, likely to re-populate a search field or display "Results for: [input]".
4. Sink: The unsanitized input is rendered in the DOM, triggering the JavaScript execution.

4. Nonce Acquisition Strategy

Reflected XSS typically occurs during a GET request to render a page and often does not require a nonce. However, if the reflection occurs via an AJAX-driven search or filter:

1. Identify Shortcode: The plugin likely uses [library-viewer].
2. Create Test Page:

   wp post create --post_type=page --post_title="Library" --post_status=publish --post_content='[library-viewer]'
   

3. Identify JS Variable: Look for wp_localize_script in the source. Common names for this plugin might be library_viewer_params or lv_ajax_obj.
4. Extract Nonce:
   If an AJAX nonce is required for the reflected endpoint, use browser_eval:

   // Example (inferred identifiers)
   browser_eval("window.library_viewer_params?.nonce")
   

5. Bypass Check: If the code uses wp_verify_nonce($nonce, -1) or fails to check the return value of check_ajax_referer, the nonce may be unnecessary or easily satisfied.

5. Exploitation Strategy

1. Discovery: Navigate to the page with the shortcode and identify query parameters used in the UI (Search bars, category filters).
2. Payload Crafting:
   • Simple reflection: <script>alert(document.domain)</script>
   • Attribute breakout: "><script>alert(1)</script>
   • Event handler (if reflected in an attribute): ' onmouseover='alert(1)
3. Request Execution:
   Use http_request to simulate a victim clicking the link.

   {
     "method": "GET",
     "url": "http://localhost:8888/library/?search_term=%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E"
   }
   

4. Verification: Check the response body for the unescaped payload.

6. Test Data Setup

1. Install Plugin: Ensure library-viewer version < 3.2.0 is active.
2. Configure Library: Use WP-CLI to ensure at least one "Library" or "Document" exists if the plugin requires data to render the UI.

   # Inferred: Creating a library item if the plugin uses a CPT
   wp post create --post_type=library_item --post_title="Test Document" --post_status=publish
   

3. Public Page: Create a page that renders the library:

   wp post create --post_type=page --post_title="Library View" --post_status=publish --post_content='[library-viewer]'
   

7. Expected Results

• The HTTP response will contain the literal string <img src=x onerror=alert(1)> (or the chosen payload) without being converted to HTML entities (e.g., <img).
• When viewed in a browser via the browser_navigate tool, an alert box or the side effect of the script should be observable.

8. Verification Steps

1. Inspect Response:

   # Verify the payload is present and unescaped in the HTML source
   http_request GET "http://localhost:8888/library-view/?search_term=<script>alert(1)</script>" | grep "<script>alert(1)</script>"
   

2. Check Source Code (Post-Exploit): Verify the sink in the plugin files:

   grep -r "echo.*\$_GET" wp-content/plugins/library-viewer/
   

9. Alternative Approaches

• POST-based Reflection: If the search uses POST, send the payload in the request body with Content-Type: application/x-www-form-urlencoded.
• AJAX Reflection: If the UI is SPA-like, check admin-ajax.php?action=lv_search&term=<payload>. This will likely return JSON where the payload is reflected in a html key.
• Pagination/Ordering: Test parameters like order, orderby, or paged which are frequently reflected in hidden form fields for state persistence.