CVE-2026-15664 in Quill Forms Plugin
Summary
by MITRE • 09/19/2026
The Quill Forms | Conversational Multi Step Forms, Surveys & quizzes plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Multiple Choice 'Other' Value in all versions up to, and including, 5.7.1 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 injected script executes in the context of the WordPress admin results view, making administrators the primary target when reviewing submitted form entries.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/19/2026
The Quill Forms plugin for WordPress, specifically versions up through 5.7.1, contains a critical security flaw classified as Stored Cross-Site Scripting within its conversational multi-step forms feature. This vulnerability arises from insufficient input sanitization and output escaping mechanisms when handling the Multiple Choice field type with an Other value option. The core technical failure lies in the application's inability to properly validate or encode user-supplied data before storing it in the database and subsequently rendering it back into the browser environment without appropriate context-aware encoding. This allows malicious actors to inject arbitrary JavaScript code that persists on the server side, rather than being limited to session-based attacks like reflected XSS.
The operational impact of this vulnerability is severe due to its stored nature combined with the specific execution context. When a user submits a form entry containing malicious script payloads within the Other value field, the data is saved directly into the WordPress database without adequate filtering. Subsequently, when an administrator accesses the admin results view to review these submitted entries, the browser parses and executes the injected scripts in the context of the administrative dashboard. This means that any user with access to view form submissions can trigger the execution of arbitrary code within the privileged environment of the WordPress administration interface. The primary targets are site administrators who regularly monitor or export form data, as their active sessions provide high-value credentials for exploitation.
From a classification perspective, this vulnerability aligns closely with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. Specifically, it represents Stored XSS where the payload is persisted on the target server rather than being transmitted via request parameters alone. In terms of adversary tactics, this flaw facilitates techniques associated with MITRE ATT&CK ID T1059, Command and Scripting Interpreter, particularly when used for session hijacking or credential theft through keylogging scripts embedded in the injected payloads. The ability to execute code within an admin context significantly lowers the barrier for attackers seeking full site compromise, as they can leverage browser-based attacks such as Cross-Site Request Forgery (CSRF) automation or direct manipulation of administrative functions without needing traditional authentication bypasses.
Mitigation strategies must address both immediate remediation and long-term defensive posture improvements. The most effective solution is to upgrade the Quill Forms plugin to a version later than 5.7.1, where developers have presumably implemented proper input validation and output encoding practices consistent with WordPress coding standards. For environments unable to update immediately due to compatibility constraints, temporary mitigations include restricting access to form submission endpoints if possible, although this may not fully mitigate the risk since the attack vector relies on legitimate user submissions being viewed by admins. Implementing a Web Application Firewall (WAF) with rules specifically tuned to detect and block XSS payloads in POST data can provide an additional layer of defense against exploitation attempts. Furthermore, enforcing strict Content Security Policy headers that restrict script execution sources can help mitigate the impact if any scripts are successfully injected, although this is not a substitute for fixing the underlying code defect. Regular security audits focusing on input sanitization and output escaping across all user-facing forms will prevent similar vulnerabilities from emerging in future updates or custom integrations.