WPForms Lite EUVD-2026-96278

Exploitation is strictly gated: a site administrator must have previously saved a form whose description embeds a {query_var} Smart Tag inside an iframe srcdoc attribute, AND must have enabled the 'Show Description' option on a public-facing page. Only then can an unauthenticated attacker supply a malicious value via the attacker-controlled query-string parameter (e.g. 'x') referenced by that Smart Tag. Additional limiting factors: the attack is reflected, so it requires user interaction (victim must click a crafted link), and impact is confined to script execution in the victim's browser context (C:L/I:L, no availability impact). These non-default configuration requirements plus the UI:R/AC:H profile substantially narrow real-world exploitability despite the network-facing, unauthenticated entry point.

This is a genuinely low-priority issue despite being a flaw in an extremely popular plugin. The CVSS 3.1 base score is 4.7 (Medium), and the vector itself tells the real story: AV:N but AC:H, PR:N, UI:R, with only Low confidentiality and integrity impact (C:L/I:L) and no availability impact. The high attack complexity (AC:H) is driven by stacked preconditions - exploitation only works if an administrator has already saved a form whose description embeds a {query_var} Smart Tag inside an iframe srcdoc attribute AND enabled 'Show Description' on a public page - which is a non-default, atypical configuration. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The vulnerability is NOT in CISA KEV and no public exploit code was referenced (only Wordfence's advisory and WordPress trac source/patch links), so this is 'no public exploit identified at time of analysis.' The signals are internally consistent rather than conflicting: a network-reachable but hard-to-trigger, user-interaction-dependent reflected XSS with limited impact. Priority should be low-to-moderate - patch during routine maintenance rather than emergency response - though the plugin's massive install base means it is worth not ignoring.

On a site where an admin has published a form containing a {query_var} Smart Tag inside an iframe srcdoc with 'Show Description' enabled, an attacker crafts a URL with a malicious value in the attacker-chosen query parameter (e.g. 'x') referenced by that Smart Tag. The attacker emails or posts the link, and when a victim clicks it the unsanitized value is reflected into the iframe srcdoc and executes arbitrary JavaScript in the victim's browser session. No public proof-of-concept was referenced, and success depends on both the pre-existing form configuration and tricking the victim into clicking (AV:N but AC:H/UI:R).