CVE-2026-95808 in Form Maker Plugin
Summary
by MITRE • 10/14/2026
The Form Maker by 10Web – Mobile-Friendly Drag & Drop Contact Form Builder plugin for WordPress is vulnerable to blind SQL Injection via the 'inputs' parameter in all versions up to, and including, 1.15.48 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. The nonce required to reach the vulnerable handler is emitted to every public page that renders a form, making it trivially obtainable by an unauthenticated attacker from page source.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The Form Maker plugin for WordPress, developed by 10Web, contains a critical security vulnerability classified as blind SQL injection affecting all versions up to and including 1.15.48. This flaw resides specifically within the handling of the inputs parameter during form submission processes. The root cause is attributed to insufficient input sanitization and a lack of proper query preparation mechanisms when constructing database queries. Because the application fails to adequately escape user-supplied data before incorporating it into SQL statements, attackers can inject malicious SQL code that alters the intended logic of the original query. This type of vulnerability allows for the extraction of sensitive information from the underlying database without requiring direct error messages or visible feedback in the response body, which characterizes the blind nature of the injection.
The operational impact of this vulnerability is severe due to the ease with which an unauthenticated attacker can exploit it. The security mechanism typically used to prevent unauthorized actions, specifically a nonce token required for form submission, is emitted on every public page that renders a Form Maker contact form. Consequently, any visitor viewing these pages can trivially obtain the valid nonce by inspecting the HTML source code of the webpage. This design flaw effectively neutralizes the protective value of the nonce, as it does not require secret knowledge or complex session management to acquire. Attackers can therefore craft requests that include both a legitimate-looking nonce and malicious SQL payloads within the inputs parameter, bypassing standard access controls intended for unauthenticated users.
From an industry standards perspective, this vulnerability aligns with CWE-89, which describes Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection. The specific exploitation technique falls under ATT&CK tactic T1059, specifically sub-technique T1059.004 for Command and Scripting Interpreter interactions via database queries, although the primary impact here is data exfiltration rather than command execution. The blind aspect of the injection corresponds to techniques where the attacker infers information based on time delays or boolean responses from the application logic. This allows adversaries to systematically extract sensitive data such as administrator credentials, user personal information, and other confidential records stored in the WordPress database by observing differences in page load times or response behaviors.
Mitigation strategies must address both immediate remediation and long-term security hygiene. The most effective solution is for users of the Form Maker plugin to upgrade immediately to a version later than 1.15.48, where the developers have presumably implemented proper input validation and parameterized queries to prevent SQL injection attacks. For organizations unable to update immediately due to compatibility constraints, implementing a Web Application Firewall can provide an additional layer of defense by detecting and blocking common SQL injection patterns in HTTP requests. Additionally, reviewing server-side logs for anomalous query execution times or unusual database activity may help identify ongoing exploitation attempts. Future development practices should enforce strict adherence to secure coding standards that mandate the use of prepared statements with parameterized queries rather than string concatenation when interacting with databases, ensuring that user input is never interpreted as executable code by the SQL engine.