Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.7",
  "pubDate": "2026-10-10T05:16:38.733Z",
  "pubdate": "2026-10-10T05:16:38.733Z",
  "executiveSummary": "The Fluent Forms WordPress plugin, in versions up to and including 6.2.14, is susceptible to a Reflected Cross-Site Scripting (XSS) vulnerability.\nThis security flaw stems from inadequate input sanitization and output escaping mechanisms within the plugin's SmartCode processing engine.\nThe vulnerability allows unauthenticated attackers to execute arbitrary JavaScript within the context of a victim's browser session.\nExploitation is contingent upon specific site configurations, specifically where an administrator has implemented a Custom HTML field containing a {get.*} SmartCode within a sensitive URL-based attribute, such as an 'href' or 'src' attribute.\nBy crafting a malicious URL containing a payload in the requested parameter, an attacker can trigger the execution of the script when a user interacts with the link.\nThe impact includes potential session hijacking, unauthorized actions performed on behalf of the user, and the exfiltration of sensitive data.\nThis vulnerability highlights the risks associated with dynamic parameter reflection in plugin features that facilitate user-defined content rendering.",
  "technicalDetails": "The vulnerability originates from the plugin's handling of the {get.NAME} SmartCode placeholder, which is designed to dynamically fetch and reflect data from the request parameters.\nThe root cause is a failure to implement robust input validation or context-aware output encoding on the value passed to the SmartCode placeholder before it is rendered into the HTML document.\nThe plugin facilitates a feature allowing administrators to embed SmartCodes within Custom HTML fields. When a {get.*} SmartCode is placed inside an attribute that expects a URI—such as the 'src' attribute of an iframe or the 'href' attribute of an anchor tag—the plugin processes the user-supplied input directly.\nAn unauthenticated attacker can supply a malicious payload through the parameter specified by the placeholder. For example, if {get.proof} is configured, an attacker can append '?proof=javascript:alert(1)' to the URL.\nBecause the plugin does not properly sanitize the input for these specific HTML contexts, the browser treats the attacker-supplied payload as legitimate code, resulting in execution in the user's browser session.\nThe attack flow requires the following conditions: first, a site administrator must have published a Fluent Form containing a Custom HTML field that utilizes a {get.*} SmartCode within an attribute that supports URI-based execution (like javascript:). Second, the attacker must persuade an authenticated or unauthenticated victim to click a specially crafted link that includes the payload as a URL parameter.\nUpon successful execution, the injected script operates with the same permissions as the victim's session. If the victim is an administrator, the impact is significantly higher, potentially allowing for account takeover, plugin modification, or the injection of persistent malicious content into the WordPress database.\nThe flaw affects all versions up to 6.2.14 and is classified as Reflected XSS because the malicious script is not stored on the server but is instead reflected back to the user via the HTTP request parameters.\nThe reliance on the {get.*} functionality makes this a design-level implementation issue where user-controllable input is reflected directly into the Document Object Model (DOM) without sufficient neutralization of dangerous protocols or malicious characters."
}