CVE-2026-7232 in FormCraft Plugin
Summary
by MITRE • 07/23/2026
The FormCraft plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the '[parameter name]' parameter in all versions up to, and including, 3.9.14 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. The exploit chain combines a server-side gap — where composite matrix sub-field keys such as field2_0 and field2_1 are never passed through the sanitization loop and are stored raw via $wpdb->insert() — with a client-side gap where DOMPurify is only invoked when typeof field.value === 'string', but matrix values arrive from the server as arrays, bypassing the check before being mapped to strings and injected into the DOM. Additionally, the same sink is reachable via a second attack vector: array-typed field values are passed through htmlentities() on submission but later reversed by html_entity_decode() at formcraft-main.php:2608 and :2122, restoring the malicious payload before storage and rendering.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/23/2026
The FormCraft WordPress plugin vulnerability represents a critical stored cross-site scripting weakness that affects versions up to 3.9.14, creating a persistent security risk for WordPress installations. This vulnerability stems from inadequate input sanitization mechanisms combined with insufficient output escaping practices that allow malicious payloads to be permanently stored and executed within the application environment. The flaw manifests through multiple attack vectors that exploit both server-side and client-side processing gaps, making it particularly dangerous as it can affect any user who accesses pages containing the injected scripts without requiring authentication or privileged access.
The technical implementation of this vulnerability occurs through a combination of server-side data handling failures and client-side sanitization bypasses. Specifically, composite matrix sub-field keys such as field2_0 and field2_1 are never properly passed through the sanitization loop during database insertion operations, allowing raw input to be stored directly via $wpdb->insert() methods. This creates a persistent storage point for malicious scripts that can execute whenever legitimate users access affected pages. The vulnerability is further exacerbated by DOMPurify's conditional execution logic which only processes inputs when typeof field.value === 'string', but matrix values arrive from the server as arrays, effectively bypassing the sanitization check before these array-based values are converted to strings and injected into the document object model.
The operational impact of this vulnerability extends beyond simple script execution to encompass potential privilege escalation and data exfiltration scenarios. Attackers can leverage this weakness to inject malicious scripts that target authenticated administrators or regular users, potentially gaining access to sensitive information or performing unauthorized actions within the compromised WordPress environment. The vulnerability's persistence through storage means that once injected, malicious payloads remain active until manually removed from the database, creating ongoing security exposure for affected installations. This stored nature aligns with CWE-79 (Cross-site Scripting) and follows attack patterns consistent with those documented in the MITRE ATT&CK framework under the T1566 (Phishing) and T1059 (Command and Scripting Interpreter) techniques.
Multiple mitigation strategies should be implemented to address this vulnerability effectively. Immediate remediation involves upgrading to a patched version of the FormCraft plugin where input sanitization has been properly enforced for all field types including matrix arrays. Database-level protections must ensure that all inputs pass through comprehensive sanitization routines before storage, with special attention to array-type fields that may bypass standard string-based validation. Client-side protections should be enhanced to properly handle all data types regardless of their initial format, ensuring that DOMPurify or equivalent sanitization libraries are invoked for all input sources rather than relying on type checking mechanisms that can be easily circumvented. Additionally, implementing proper content security policies and regular security audits of plugin code can help prevent similar vulnerabilities from emerging in the future, while monitoring for suspicious database modifications can provide early detection of exploitation attempts. The vulnerability serves as a reminder of the critical importance of thorough input validation across all data processing layers and demonstrates how seemingly minor implementation oversights can create significant security risks in web applications.