CVE-2026-71249 in Contact Form Plugin
Summary
by MITRE • 08/05/2026
299Ko's public contact form (plugin/contact/controllers/ContactController.php, home()) sets raw POST field values (name, firstname, email, message) into the page template with no sanitization. The template engine's variable output function (common/Template.php, _show_var()) echoes values with no htmlspecialchars() call, and the sink template (contact.tpl) outputs these values unescaped into an HTML attribute and a textarea. An unauthenticated attacker can submit a payload such as name="><script>alert(document.domain)</script> to achieve reflected XSS against any visitor who submits or is tricked into auto-submitting the form, including a targeted administrator, enabling session token theft.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability represents a critical reflected cross-site scripting flaw in a contact form plugin that operates without proper input sanitization or output escaping mechanisms. The weakness exists in the ContactController.php file where raw POST data from user inputs is directly injected into page templates without any form of sanitization or validation, creating an avenue for malicious code execution. The vulnerability specifically manifests when the application processes form submissions and renders them in the contact.tpl template file, which serves as the final sink for these unprocessed variables.
The technical implementation of this flaw stems from a fundamental failure in the application's data handling pipeline where user-supplied information flows directly from the HTTP POST request through to the HTML output without appropriate security measures. In the ContactController.php file, the home() method indiscriminately accepts name, firstname, email, and message parameters from the raw POST data and passes them directly into the template system. The Template.php file's _show_var() function then echoes these values directly to the browser without applying htmlspecialchars() or any equivalent escaping mechanism, creating a classic XSS vulnerability pattern.
The operational impact of this vulnerability extends beyond simple script injection, as it enables attackers to execute arbitrary JavaScript code in the context of any user's browser who interacts with the compromised form. When an attacker submits malicious input such as name="><script>alert(document.domain)</script>, the payload gets rendered directly into HTML attributes and textarea elements, allowing for session hijacking, credential theft, and potentially full administrative compromise if targeted at privileged users. This vulnerability falls under CWE-79 - Improper Neutralization of Input During Web Page Generation, which is a well-established category for XSS vulnerabilities.
The attack vector requires minimal privileges since the vulnerability affects an unauthenticated public form, making it particularly dangerous as it can be exploited by anyone who accesses the compromised website. The reflected nature of the attack means that payloads are executed immediately upon page load, requiring no persistent storage or complex exploitation chains. This makes the vulnerability highly attractive to attackers targeting specific administrators or users with elevated privileges, as they can craft payloads designed to steal session cookies or redirect victims to malicious sites.
Mitigation strategies should focus on implementing proper input validation and output escaping mechanisms throughout the application's data flow. All user-supplied inputs must be sanitized using appropriate escaping functions before being rendered in HTML contexts, specifically applying htmlspecialchars() with ENT_QUOTES flag when outputting data into HTML attributes and textareas. The template system should enforce strict variable escaping by default, ensuring that any data passed to templates undergoes proper sanitization regardless of the context. Additionally, implementing Content Security Policy headers can provide an additional layer of defense against XSS attacks. This vulnerability aligns with ATT&CK technique T1531 - Account Access Through Social Engineering, as it enables attackers to gain unauthorized access through the exploitation of user trust in legitimate website forms. The implementation of proper input validation and output escaping should be enforced across all template variables and user-facing data handling components to prevent similar issues from occurring in other parts of the application.