JetFormBuilder CVE-2026-97342

Exploitation requires that the site run the JetFormBuilder plugin (≤3.6.5.4) with the public submission endpoint wp_ajax_nopriv_jet_form_builder_submit reachable (its default behavior for front-end forms), AND a form configured with the Insert/Update Post action that writes submitted values into post meta, AND a Select Field block whose options are populated by the get_from_db option generator reading that same meta_key. The injection itself needs no authentication, no user interaction, and no special configuration beyond a published form with these actions; the limiting factor is the rendering side - the stored payload only executes once a victim loads a page containing the vulnerable Select Field block bound to the poisoned meta. If no such Select/get_from_db field exists on the site, the stored payload remains dormant.

This is a genuinely notable issue rather than a high-CVSS-but-low-real-risk flaw, driven primarily by the CVSS vector: AV:N/AC:L/PR:N/UI:N means a remote, unauthenticated attacker can inject the payload with low complexity and no interaction via the wp_ajax_nopriv_jet_form_builder_submit endpoint. The S:C (scope change) with C:L/I:L reflects classic stored XSS impact - script executing in the browser context of whoever later views the injected page. However, several corroborating signals are MISSING: no EPSS score was provided, so exploitation probability cannot be quantified; KEV status is not listed (treat as not in CISA KEV); and no public POC is referenced beyond the vendor's own wpunit regression test (SelectStoredXssTest.php). The 7.2 base score is therefore the main driver, and it should be read as 'realistic, scriptable injection vector but second-order (XSS) impact requiring a victim to view the page.' The unauthenticated nature meaningfully raises priority for any site running the affected plugin, but absence of active-exploitation evidence keeps this below emergency-patch tier. One caveat to verify: payload execution depends on the site actually using a Select Field block with the get_from_db option generator pointed at the attacker-influenced post meta - if no such form/field exists, real-world exposure is lower than the raw score suggests.

An unauthenticated attacker submits a crafted form to the public wp_ajax_nopriv_jet_form_builder_submit endpoint, embedding a script payload (e.g. '"></option></select><img src=x onerror=alert(document.domain)>') that is stored verbatim into post meta through the Insert/Update Post action. Later, when any user or administrator loads a page where a Select Field block renders those meta values via the get_from_db generator, the unescaped value and label break out of the <option> tag and execute in the victim's browser. No public exploit is identified at time of analysis, though the vendor's patch commit includes a wpunit test demonstrating the payload.