CVE-2021-47926: Contact Form to Email XSS Vulnerability

CVE-2021-47926 Overview

CVE-2021-47926 is a stored cross-site scripting (XSS) vulnerability [CWE-79] in the Contact Form to Email WordPress plugin version 1.3.24. The flaw exists in the form name input field, which fails to sanitize HTML and JavaScript content before storage. Authenticated attackers with form creation privileges can embed <script> tags inside form names. When other logged-in administrators or editors visit the form management page, the injected payload executes in their browser session. Successful exploitation enables session hijacking, credential theft, and unauthorized actions performed under the victim's WordPress privileges.

Critical Impact
Authenticated attackers can persist JavaScript payloads in the plugin's form management interface, leading to session theft and privileged account compromise when administrators view stored forms.

Affected Products

Contact Form to Email plugin version 1.3.24 for WordPress
WordPress installations using the affected plugin version
Form2Email (DWBooster) component on WordPress sites

Discovery Timeline

2026-05-10 - CVE-2021-47926 published to NVD
2026-05-12 - Last updated in NVD database

Technical Details for CVE-2021-47926

Vulnerability Analysis

The vulnerability is a stored XSS issue in the Contact Form to Email plugin version 1.3.24. The plugin accepts arbitrary input in the form name field during form creation. Input is persisted to the database without HTML entity encoding or tag stripping. The stored value is later rendered directly into the form management page DOM.

When an administrator loads the form list, the browser parses the injected <script> tags and executes the attacker-controlled JavaScript. The payload runs with the privileges of the viewing user. This enables theft of WordPress authentication cookies, CSRF token exfiltration, and arbitrary administrative actions via the WordPress REST API.

The issue is classified under [CWE-79] Improper Neutralization of Input During Web Page Generation. Exploitation requires an authenticated account with permission to create forms, and a second user with access to the management page must view the malicious form.

Root Cause

The root cause is missing output encoding on user-supplied form name values. The plugin does not apply WordPress sanitization functions such as sanitize_text_field() on input or esc_html() on output. Form name strings are concatenated into HTML without context-aware escaping.

Attack Vector

An authenticated attacker with plugin access creates a new form. The attacker sets the form name to a value containing JavaScript, such as a <script> tag with a remote payload loader or an inline event handler. The malicious form is saved to the WordPress database via the plugin's form storage mechanism.

When a higher-privileged user opens the form management screen, the stored script executes in their authenticated session context. Public exploit details are documented in the Exploit-DB #50524 entry and the VulnCheck WordPress XSS Advisory.

No verified proof-of-concept code is reproduced here. See the referenced advisories for technical exploitation details.

Detection Methods for CVE-2021-47926

Indicators of Compromise

Form records in the plugin's database tables containing <script>, onerror=, onload=, or javascript: strings in name fields
Unexpected outbound HTTP requests from administrator browser sessions to attacker-controlled domains shortly after accessing the form management page
New WordPress administrator accounts or modified user roles created without a corresponding audit trail
Anomalous session cookie reuse from geographically distant IP addresses

Detection Strategies

Query the WordPress database for plugin form records and search the name column for HTML tag characters and JavaScript event handler patterns
Inspect web server access logs for POST requests to the plugin's form creation endpoint with payloads containing encoded < and > characters
Monitor browser-side telemetry on administrator endpoints for unexpected script execution originating from WordPress admin pages
Review WordPress audit logs for form creation events performed by low-privilege users immediately preceding administrator activity

Monitoring Recommendations

Enable a WordPress activity logging plugin to capture form creation, modification, and viewing events with user attribution
Deploy a web application firewall rule set that inspects POST bodies to plugin admin endpoints for script tag patterns
Alert on administrator account changes, password resets, and new user creation occurring within minutes of form management page visits
Continuously baseline outbound network traffic from workstations used for WordPress administration

How to Mitigate CVE-2021-47926

Immediate Actions Required

Update the Contact Form to Email plugin to a version newer than 1.3.24 that addresses the stored XSS issue
Audit existing forms in the plugin database and remove any entries with HTML or JavaScript content in the name field
Rotate WordPress administrator passwords and invalidate active sessions if exploitation is suspected
Restrict plugin form creation permissions to trusted administrator accounts only

Patch Information

Vendor patch details are available from the plugin maintainer at the Form2Email application site. Site operators should upgrade through the WordPress plugin manager and verify the installed version after upgrade. Refer to the VulnCheck WordPress XSS Advisory for additional remediation guidance.

Workarounds

Disable the Contact Form to Email plugin until a patched version is installed if immediate updates are not possible
Enforce a Content Security Policy header on the WordPress admin interface that blocks inline script execution
Restrict access to the WordPress administration interface using IP allow-listing at the web server or firewall layer
Require multi-factor authentication for all WordPress accounts with plugin management permissions

bash

# Content Security Policy example for WordPress admin
# Add to web server configuration to mitigate stored XSS execution
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'"