CVE-2026-101324 in Fluent Forms Plugin
Summary
by MITRE • 10/10/2026
The Fluent Forms – Customizable Contact Forms, Survey, Quiz, & Conversational Form Builder plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the 'any attacker-chosen name matching the {get.NAME} placeholder (PoC uses 'proof')' parameter in all versions up to, and including, 6.2.14 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link. Exploitation requires a site administrator to have configured a Custom HTML field on a published form containing a {get.*} SmartCode inside a URL-accepting attribute such as iframe src or a href — a documented Fluent Forms feature.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified in the Fluent Forms plugin for WordPress, specifically affecting versions up to and including 6.2.14, represents a significant security risk classified under Reflected Cross-Site Scripting (XSS). This flaw stems from insufficient input sanitization and output escaping mechanisms within the plugin's handling of dynamic form parameters. The core issue lies in how the application processes user-supplied data passed via URL query strings when these values are intended to populate specific fields using SmartCode placeholders such as {get.NAME}. While this feature is designed to allow developers and site administrators to pre-fill forms with external data, the implementation fails to adequately validate or encode the incoming input before rendering it within HTML attributes.
The technical mechanism of exploitation relies on a configuration dependency that must be present for the attack to succeed. Specifically, an administrator must have created a form containing a Custom HTML field where a {get.*} SmartCode is embedded inside a URL-accepting attribute, such as iframe src or href tags. When a victim user clicks a link crafted by an attacker with malicious JavaScript code in the query parameter corresponding to this placeholder, the server-side logic retrieves the value and injects it directly into the HTML output without proper encoding. Because the injection occurs within an attribute context that interprets script execution triggers, such as event handlers or protocol-based javascript: URIs, the browser executes the injected payload upon page load. This constitutes a reflected XSS attack because the malicious script is immediately returned to the user's browser in response to their request rather than being stored permanently on the server for later retrieval by other users.
From an operational impact perspective, this vulnerability allows unauthenticated attackers to execute arbitrary web scripts in the context of the vulnerable website. Successful exploitation can lead to session hijacking, where attacker-controlled JavaScript steals authentication cookies or tokens, thereby granting unauthorized access to user accounts. It also enables defacement of the webpage content, redirection of users to malicious phishing sites designed to steal credentials, and potentially keylogging activities if the injected script monitors keyboard input within form fields. The severity is compounded by the fact that exploitation requires only social engineering tactics, such as tricking a victim into clicking a specially crafted link, which are common vectors in targeted attacks or broader campaigns aimed at compromising WordPress-based infrastructure.
This vulnerability aligns with CWE-79, commonly known as Improper Neutralization of Input During Web Page Generation (Cross-site Scripting), and maps to the MITRE ATT&CK technique T1059.007, which covers JavaScript execution within web browsers. The lack of proper output encoding violates fundamental secure coding principles that dictate all data originating from untrusted sources must be contextually encoded before being inserted into HTML structures. To mitigate this risk, immediate action is required to update the Fluent Forms plugin to a version where this sanitization logic has been corrected. In addition to updating software, administrators should review their form configurations to ensure that SmartCode placeholders are not used in attributes susceptible to XSS unless strict validation and encoding controls are verified by the vendor. Implementing Content Security Policy (CSP) headers can also provide an additional layer of defense by restricting the sources from which scripts can be executed, thereby limiting the impact even if a reflection vector is partially exploited.