Extra Shortcodes <= 2.2 - Authenticated (Contributor+) Stored Cross-Site Scripting

This research plan outlines the technical steps to analyze and exploit CVE-2025-62111, a Stored Cross-Site Scripting (XSS) vulnerability in the Extra Shortcodes plugin (<= 2.2).

---

1. Vulnerability Summary

The Extra Shortcodes plugin fails to properly sanitize or escape user-supplied attributes within its registered shortcodes. When a user with the contributor role or higher creates a post containing one of these shortcodes, they can inject malicious JavaScript into the attributes. This script is stored in the WordPress database as part of the post content and executes in the context of any user (including Administrators) who views the post or the post editor.

2. Attack Vector Analysis

• Endpoint: WordPress Post Editor (/wp-admin/post-new.php or /wp-admin/post.php).
• Vulnerable Parameter: Shortcode attributes (e.g., title, url, class, or content).
• Authentication: Required (Contributor role or higher).
• Preconditions: The plugin must be active, and a user with at least Contributor permissions must be able to save a post or a draft.

3. Code Flow (Inferred)

1. Registration: The plugin registers various shortcodes using add_shortcode( 'tag_name', 'handler_function' ) during the init hook.
2. Input: A Contributor saves a post containing [tag_name attribute="<script>alert(1)</script>"]. WordPress saves this raw string to the wp_posts table.
3. Processing: When the post is rendered, WordPress calls the plugin's handler_function( $atts ).
4. Sink: The handler function likely extracts the attributes using shortcode_atts() and returns an HTML string where the attribute is concatenated directly without using esc_attr(), esc_html(), or wp_kses().
   • Example Vulnerable Pattern: return '<div class="' . $atts['class'] . '">' . $content . '</div>';

4. Nonce Acquisition Strategy

While the final XSS is stored in the post content, the act of saving the post as a Contributor requires standard WordPress nonces.

1. Identify the Post Nonce: When a Contributor opens the post editor, WordPress localizes several nonces.
2. Acquisition via browser_eval:
   • Navigate to /wp-admin/post-new.php.
   • The primary nonce for saving/updating posts is typically found in the #_wpnonce hidden input field or via the global wp object in Gutenberg.
   • Command: browser_eval("document.querySelector('#_wpnonce')?.value")
3. Plugin-Specific Nonces: Since this is a Stored XSS via the standard post editor, no unique plugin-specific AJAX nonce is typically required for the injection itself, as we are leveraging the native wp_insert_post or edit_post functionality.

5. Exploitation Strategy

The goal is to identify a shortcode that reflects its attributes into the HTML source without escaping.

Step 1: Identify Shortcodes (Discovery)
Search the plugin directory for registered shortcodes:
grep -r "add_shortcode" /var/www/html/wp-content/plugins/extra-shortcodes/

Step 2: Map to Handler Functions
Identify the function associated with a promising shortcode (e.g., button, alert, box). Check the handler for unescaped output:
grep -n "function [FUNCTION_NAME]" [FILE_PATH] -A 20

Step 3: Construct Payload
Identify which attribute is reflected.

• If reflected in an attribute (e.g., class="..."): "><script>alert(document.domain)</script>
• If reflected in a URL (e.g., href="..."): javascript:alert(1)
• If reflected in a tag body: <img src=x onerror=alert(1)>

Step 4: Inject via HTTP Request
Use the http_request tool to simulate a Contributor saving a draft.

• URL: http://localhost:8080/wp-admin/post.php
• Method: POST
• Body (URL-encoded):

  action=editpost
  post_ID=[POST_ID]
  _wpnonce=[NONCE]
  post_title=XSS Test
  content=[shortcode_name attribute="<script>alert(1)</script>"]
  

6. Test Data Setup

1. Install Plugin: Ensure extra-shortcodes is installed and active.
2. Create Contributor:
   wp user create attacker attacker@example.com --role=contributor --user_pass=password
3. Create Initial Draft:
   wp post create --post_type=post --post_status=draft --post_author=[ATTACKER_ID] --post_title="Draft"

7. Expected Results

• The HTTP request should return a 302 Found redirecting back to the post editor.
• When an Administrator navigates to the list of posts and previews the malicious post, the JavaScript payload (alert(document.domain)) will execute in their browser.

8. Verification Steps

1. Check Database Content:
   wp db query "SELECT post_content FROM wp_posts WHERE post_title='XSS Test'"
2. Check Frontend Output:
   Use http_request to GET the post permalink and check if the payload is rendered unescaped (e.g., searching for <script>alert).

9. Alternative Approaches

• Gutenberg Blocks: If the plugin provides Gutenberg blocks instead of traditional shortcodes, the injection point might be in the block's JSON metadata within the post_content.
• AJAX Save: If the plugin has a custom settings page for "Default Shortcode Styles" accessible to Contributors, the XSS could be injected there using the wp_ajax_ hooks identified via grep -r "wp_ajax_".