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

# 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'"