Research Plan: CVE-2025-15483 - Link Hopper Stored XSS

1. Vulnerability Summary

The Link Hopper plugin for WordPress (versions <= 2.5) is vulnerable to Stored Cross-Site Scripting (XSS) via the hop_name parameter. The vulnerability exists because the plugin fails to sanitize the link name when it is saved to the database and fails to escape the value when it is rendered in the admin dashboard. While the attack requires Administrator-level privileges, it is significant in environments where unfiltered_html is disabled (such as WordPress Multisite or hardened installations), as it allows an administrator to execute arbitrary JavaScript in the context of other administrators or super-admins.

2. Attack Vector Analysis

• Endpoint: Likely a link creation/editing form in the WordPress admin area or an AJAX handler.
• Vulnerable Parameter: hop_name (inferred).
• Authentication: Authenticated, Administrator+.
• Impact: Stored XSS. Execution occurs when an administrator views the list of "hops" (links) created within the plugin.
• Precondition: unfiltered_html must be disabled for the user (e.g., standard Administrator on a Multisite installation).

3. Code Flow (Inferred)

1. Input: An administrator navigates to the Link Hopper management page (e.g., wp-admin/admin.php?page=link-hopper-add or similar).
2. Processing: The administrator submits a form to create or update a "hop". The request is handled by a function hooked to admin_init or a wp_ajax_ action.
3. Storage: The plugin retrieves $_POST['hop_name']. It likely saves this value using update_post_meta() or a direct $wpdb->insert()/$wpdb->update() call without applying sanitize_text_field().
4. Retrieval: When an administrator visits the link overview page (wp-admin/admin.php?page=link-hopper), the plugin retrieves the stored hop_name.
5. Sink: The retrieved hop_name is echoed directly into the HTML table or list without using esc_html() or esc_attr().

4. Nonce Acquisition Strategy

Since the vulnerability is in the admin area, the form used to save the link will almost certainly be protected by a WordPress nonce.

1. Identify the Page: Search the plugin code for add_menu_page or add_submenu_page to find the admin menu slug.
   • grep -r "add_menu_page" wp-content/plugins/link-hopper/
2. Navigate to Form: Use browser_navigate to go to the link creation page.
3. Extract Nonce:
   • If it is a standard form, the nonce is likely in a hidden input field: browser_eval("document.querySelector('input[name=\"_wpnonce\"]')?.value").
   • If it is an AJAX-driven interface, check for localized scripts: browser_eval("window.link_hopper_params?.nonce") (inferred variable name).
4. Identify Action: Search for the form handler to determine if the nonce is checked using check_admin_referer() or check_ajax_referer().

5. Exploitation Strategy

Step 1: Force unfiltered_html Restriction

To simulate the vulnerable condition on a standard WordPress install, disable unfiltered_html.

• Command: wp config set DISALLOW_UNFILTERED_HTML true --raw

Step 2: Identify the Save Action

Determine how the plugin saves links. Look for $_POST['hop_name'] in the codebase.

• grep -r "hop_name" wp-content/plugins/link-hopper/

Step 3: Trigger the Storage

Send an authenticated POST request to save a new hop with the XSS payload.

• URL: https://[target]/wp-admin/admin.php?page=link-hopper-settings (inferred) or admin-ajax.php.
• Method: POST
• Body (URL-encoded):

  action=lh_save_hop&  (inferred action)
  hop_name=<script>alert(document.domain)</script>&
  hop_url=https://example.com&
  _wpnonce=[EXTRACTED_NONCE]
  

Step 4: Trigger the Execution

Navigate to the page where links are listed.

• URL: https://[target]/wp-admin/admin.php?page=link-hopper (inferred)

6. Test Data Setup

1. Plugin Activation: Ensure link-hopper is installed and active.
2. User Creation: Create an administrator user.
   • wp user create admin_tester admin@example.com --role=administrator --user_pass=password123
3. Config Change: Disable unfiltered_html (as noted in Step 1).
4. Identify Slug: Find the exact admin slug for the Link Hopper list page.

7. Expected Results

• The POST request should return a 302 redirect or a success message.
• Upon navigating to the link list page, a JavaScript alert box displaying the document domain should appear.
• Viewing the page source should show the raw <script> tag within the HTML table row for the hop_name column.

8. Verification Steps

1. Database Check: Verify the payload is stored raw in the database.
   • wp db query "SELECT * FROM wp_posts WHERE post_title LIKE '%<script>%'" (if stored as a CPT)
   • OR wp db query "SELECT * FROM wp_options WHERE option_name LIKE '%link_hopper%'"
2. HTML Inspection: Verify the absence of escaping in the response.
   • Use http_request to fetch the admin list page and check if <script> is present and NOT encoded as <script>.

9. Alternative Approaches

• Post Meta Exploitation: If hop_name is stored in wp_postmeta, try injecting via post.php if the plugin uses a custom meta box.
• Attribute Injection: If the hop_name is echoed inside an attribute (e.g., <input value="[hop_name]">), use a payload like " onmouseover="alert(1)".
• Multisite Test: If the single-site config change doesn't yield results, convert the site to a multisite network and test as a site-administrator (who lacks unfiltered_html by default).