CVE-2026-83625 in Contact Form by Supsystic Plugin
Summary
by MITRE • 09/05/2026
The Contact Form by Supsystic plugin for WordPress is vulnerable to Stored Cross-Site Scripting via IP Address Header in all versions up to, and including, 1.10.2 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. An unauthenticated attacker can first call the 'updateNonce' action — which is accessible without authentication due to its absence from the plugin's permission list — to obtain a valid nonce, then submit a contact form with a malicious payload in a spoofed IP header such as X-Forwarded-For.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability identified within the Contact Form by Supsystic WordPress plugin represents a significant security risk stemming from insufficient input sanitization and output escaping mechanisms. This flaw allows for Stored Cross-Site Scripting, commonly referred to as XSS, which is classified under CWE-79 in industry standards. The core technical issue lies in how the application handles data derived from HTTP headers, specifically the IP Address Header such as X-Forwarded-For. When a user submits a contact form through this plugin, the system processes various inputs without adequately validating or encoding them before storage and subsequent display. This lack of rigorous validation enables an attacker to inject malicious JavaScript code into the database via these header fields rather than just standard form input fields.
The operational impact of this vulnerability is severe because it facilitates Stored XSS attacks that persist on the server side. Unlike reflected XSS, where the payload is only executed in a single request, stored vulnerabilities remain active until manually removed from the database. Consequently, whenever an administrator or any other user accesses pages containing the injected content, the malicious scripts execute within their browser context. This can lead to session hijacking, credential theft, defacement of the website, or further propagation of malware if the attacker crafts payloads designed to exploit additional client-side vulnerabilities. The persistence of this code means that every visitor becomes a potential victim, amplifying the scope and severity of the compromise significantly beyond what would be expected from a simple input validation error.
The exploitation path for this vulnerability is particularly concerning due to its unauthenticated nature. An attacker does not need valid credentials or any form of authentication to initiate an attack. The process begins by calling the updateNonce action, which is accessible without authentication because it was inadvertently omitted from the plugin's permission list. This oversight allows external actors to obtain a valid nonce, which is typically used to prevent Cross-Site Request Forgery attacks but here serves as a necessary step to bypass other security controls. Once the attacker possesses this valid nonce, they can submit a contact form containing their malicious payload embedded within spoofed IP headers like X-Forwarded-For or similar variants that forward client information through proxies and load balancers.
From an ATT&CK perspective, this vulnerability aligns with techniques involving input validation bypasses and potential exploitation of web applications for initial access or persistence depending on the specific payload delivered. The ability to execute arbitrary scripts in the context of trusted websites undermines user trust and can lead to broader system compromises if combined with other vulnerabilities such as server-side request forgery or privilege escalation flaws. Mitigation strategies must focus primarily on updating the plugin to a version where these issues have been addressed, specifically versions greater than 1.10.2. In addition to patching, administrators should implement strict input validation and output encoding practices across all user-facing inputs, including those derived from HTTP headers. Security plugins that monitor for anomalous header values or restrict access to nonce generation endpoints can also provide an additional layer of defense against such exploitation attempts until the software is fully updated.