JetFormBuilder CVE-2026-103912

Exploitable ONLY on pages embedding a JetFormBuilder form that has a text field configured with a query_var Dynamic Preset AND a data-jfb-macro or JFB_FIELD:: macro reference targeting that field - both are documented but non-default features that an operator must explicitly configure. Exploitation is further limited by required user interaction: the victim must click an attacker-supplied link containing the payload (UI:R). No authentication is required of the attacker (PR:N). The combination of non-default configuration plus mandatory social engineering is what drives the high attack complexity (AC:H) and sharply narrows the realistic attack surface.

This is a genuinely moderate-to-low priority issue despite being network-reachable and unauthenticated. The CVSS vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N, base 4.7) tells a consistent story: an unauthenticated remote attacker can trigger it, but AC:H and UI:R mean exploitation requires both a non-default plugin configuration AND social engineering (the victim must click an attacker-crafted link). The scope change (S:C) plus Low confidentiality/integrity impact is typical of reflected XSS executing in the victim's browser context rather than compromising the server. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so the correct exploitation status is 'no public exploit identified at time of analysis.' There is no SSVC decision data supplied. The signals do not conflict - they uniformly point to a targeted, low-probability scenario rather than mass exploitation, consistent with reflected DOM-based XSS gated behind a specific preset/macro configuration. The only caveat is that AC:H and the 'standard, documented plugin features' language should be reconciled: the features are documented, but they are not enabled by default, which justifies the high complexity rating.

An attacker identifies a site running JetFormBuilder with a form whose text field uses a query_var Dynamic Preset referenced by a data-jfb-macro or JFB_FIELD:: macro, then crafts a URL containing a malicious script in that query variable and sends it to a victim via email or chat. When the victim clicks the link, the unsanitized value is reflected into the DOM and the script executes in their browser session. No public proof-of-concept is identified in the provided data; AC:H and UI:R mean the attacker needs the specific configuration present and must convince the victim to click.