CVE-2026-115301 in Contact Form by Supsystic Plugin
Summary
by MITRE • 10/29/2026
The Contact Form by Supsystic WordPress plugin before 1.11.1 does not sandbox the template engine used to render its forms and allows stored form-editor content to reach that engine as executable template code, enabling an administrator to perform server-side template injection and execute arbitrary code on the server. The injected template is compiled and executed whenever any visitor loads a page containing the form, so the stored payload also lets an unauthenticated visitor read server-side secrets such as authentication salts and database credentials.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in the Contact Form by Supsystic WordPress plugin prior to version 1.11.1 represents a critical failure in input validation and template engine security, specifically manifesting as a Server-Side Template Injection (SSTI). This flaw arises from the application's architectural decision not to properly sandbox or isolate the template engine responsible for rendering dynamic forms. In secure web development practices, template engines must strictly separate logic from data, ensuring that user-supplied input is treated solely as static content rather than executable code. However, in this instance, the plugin fails to sanitize form-editor content before passing it to the underlying templating system. This lack of sanitization allows an attacker who possesses administrative privileges to inject malicious template syntax directly into the form configuration fields. Because the application treats these inputs as part of the template logic rather than plain text, the engine attempts to parse and execute them during the rendering process.
The operational impact of this vulnerability is severe due to its persistence and broad accessibility. The injected payload is stored within the database associated with the specific contact form configuration. Consequently, every time a visitor loads a webpage containing that particular form, the server-side template engine processes the malicious code embedded in the form's definition. This mechanism transforms what might otherwise be an administrative-only issue into one accessible to unauthenticated users. The execution of arbitrary code on the server side occurs automatically upon page load, meaning no additional interaction from the victim user is required beyond visiting a single webpage. This persistence ensures that the attack vector remains active until the vulnerable plugin version is updated or the malicious form configuration is manually removed by an administrator.
The consequences of this successful exploitation extend far beyond simple code execution. An attacker can leverage the SSTI to read sensitive server-side secrets, including authentication salts and database credentials stored in environment variables or configuration files accessible to the application runtime. The exposure of these cryptographic keys allows for further attacks such as session hijacking, where an adversary can forge valid user sessions by replicating the signature algorithms using stolen salts. Furthermore, access to database credentials enables direct manipulation or exfiltration of the website's data store, potentially leading to a complete compromise of the underlying system and all associated user data. This level of access effectively grants the attacker full control over the web application and its backend infrastructure.
To mitigate this risk, immediate action is required by site administrators using versions of the Contact Form plugin earlier than 1.11.1. The primary remediation step involves upgrading to version 1.11.1 or later, where the developers have implemented proper sandboxing for the template engine and enforced strict input validation on form-editor content. Until the upgrade is performed, administrators should consider disabling the affected forms if they are not actively in use to prevent unauthenticated visitors from triggering the code execution. Additionally, implementing a Web Application Firewall with rules capable of detecting SSTI patterns may provide an additional layer of defense by blocking malicious template syntax before it reaches the application logic. Regular security audits and adherence to secure coding standards that prioritize input sanitization against injection attacks are essential for preventing similar vulnerabilities in future development cycles. This incident underscores the importance of treating all user-controllable data as untrusted, even when originating from administrative interfaces, and highlights the critical need for robust sandboxing mechanisms in server-side rendering technologies.