Easy Modal <= 2.1.0 - Authenticated (Contributor+) Stored Cross-Site Scripting

Vulnerability Summary

The Easy Modal plugin (versions <= 2.1.0) is vulnerable to Stored Cross-Site Scripting (XSS). This occurs because the plugin allows users with Contributor-level permissions and above to create or edit modals without properly sanitizing input fields (such as the modal title or content) and subsequently fails to escape this data when it is rendered on the front end or in the admin dashboard.

In WordPress, contributors typically have the edit_posts capability. If "Easy Modal" treats modals as a Custom Post Type (CPT) or provides a custom interface accessible to contributors, an attacker can inject malicious <script> tags into the modal's settings. When an administrator or any other user views a page containing that modal (via shortcode) or views the modal list in the admin panel, the script executes in their browser context.

Attack Vector Analysis

• Endpoint: wp-admin/post.php (if using CPT) or an AJAX handler like wp_ajax_em_save_modal (inferred).
• Vulnerable Parameter: post_title, content, or specific meta fields like em_modal_settings[title] or em_modal_settings[css_class] (inferred).
• Authentication: Authenticated, Contributor role or higher.
• Preconditions: The plugin must be active, and the attacker must have access to the modal editor.

Code Flow (Inferred)

1. Entry Point: The user submits a request to save a modal. This is handled either by the standard save_post hook for the easy_modal CPT or a custom AJAX action.
2. Processing: The plugin receives the input (e.g., $_POST['post_title'] or $_POST['em_settings']). It likely uses update_post_meta() or wp_insert_post() without sufficient sanitization (like wp_kses or sanitize_text_field).
3. Storage: The raw XSS payload is stored in the wp_posts table or wp_postmeta table.
4. Sink: When a page containing the [easy-modal id="..."] shortcode is loaded, the plugin retrieves the modal data.
5. Rendering: The plugin echoes the title or content directly: echo $modal->post_title; (inferred) without using esc_html() or esc_attr().

Nonce Acquisition Strategy

Since source files are not provided, we will assume the plugin follows the standard WordPress Custom Post Type (CPT) pattern for modal management.

1. Identify the Modal Post Type: We will check if easy_modal or em_modal is a registered post type.
2. Create a Page for Discovery: A contributor will navigate to the "Add New Modal" page.
3. Extract Nonce:
   • Use browser_navigate to go to wp-admin/post-new.php?post_type=easy_modal.
   • Use browser_eval to extract the _wpnonce from the form.
   • browser_eval("document.querySelector('#_wpnonce').value")

Exploitation Strategy

1. Test Data Setup

• Create a user with the Contributor role.
• Identify the exact slug for the modal post type (likely easy_modal).

2. Step-by-Step Exploitation

Step 1: Authenticate as Contributor

• Log in to the WordPress instance using the http_request tool to obtain session cookies.

Step 2: Get Nonce and Post ID

• Navigate to the "Add New Modal" screen to trigger the generation of a post_ID (auto-draft) and a valid nonce.
• URL: wp-admin/post-new.php?post_type=easy_modal

Step 3: Inject Stored XSS

• Submit a POST request to wp-admin/post.php to save the modal with a malicious title.
• Request Details:
  • URL: http://localhost:8080/wp-admin/post.php
  • Method: POST
  • Content-Type: application/x-www-form-urlencoded
  • Body:

    action=editpost
    &post_type=easy_modal
    &post_ID=[POST_ID]
    &_wpnonce=[NONCE]
    &post_title=<script>alert('XSS_SUCCESS_TITLE')</script>
    &content=<img src=x onerror=alert('XSS_SUCCESS_CONTENT')>
    &publish=Publish
    

Step 4: Embed the Modal (Trigger)

• As the contributor, create a public post/page containing the modal shortcode to ensure it renders on the frontend.
• Shortcode: [easy-modal id="[POST_ID]"] (inferred).

Step 5: Trigger the XSS

• Use browser_navigate to visit the newly created page as an Administrator.
• This demonstrates the escalation from Contributor to Administrator via XSS.

Expected Results

• The HTTP response from post.php should indicate a successful redirect (302) or success message.
• When the page with the shortcode is loaded, a JavaScript alert box with 'XSS_SUCCESS_TITLE' or 'XSS_SUCCESS_CONTENT' should appear.
• The HTML source of the rendered page should contain the raw, unescaped <script> or <img> tags.

Verification Steps

1. Database Check: Use WP-CLI to verify the payload is stored raw.

   wp post get [POST_ID] --field=post_title
   

2. Frontend Check: Use http_request to fetch the page where the modal is embedded and grep for the payload.

   # Look for the unescaped script tag
   grep "<script>alert('XSS_SUCCESS_TITLE')</script>"
   

Alternative Approaches

If the plugin uses a custom AJAX interface instead of the CPT post.php flow:

1. Search for AJAX actions: grep -r "wp_ajax_em_" wp-content/plugins/easy-modal/.
2. Identify the saving function: Look for update_option or update_post_meta calls inside the AJAX handler.
3. Craft AJAX Request:
   • Action: em_save_modal (inferred).
   • Payload: Send the XSS in a JSON or form-data parameter.
   • Nonce: Often localized in window.em_admin_settings.nonce.