Summary
JetFormBuilder contains a stored cross-site scripting vulnerability in the choice post meta value processed by its Insert/Update Post action. An unauthenticated attacker may submit malicious script content through the form endpoint, which can later execute in a visitor's browser when an affected page is viewed.
Affected context
The issue occurs in WordPress sites using JetFormBuilder forms with the Insert/Update Post action and a Select Field configured to obtain options from stored post metadata. Risk is present when unauthenticated form submissions can write attacker-controlled values to post meta and those values are later rendered without adequate output encoding.
Exploit preconditions
- Attack surface: The unauthenticated
wp_ajax_nopriv_jet_form_builder_submitform submission endpoint - Required access: No authenticated account is generally required, although the affected form must be reachable and permit the relevant submission
- Trigger point: A page renders Select Field options using values retrieved from post metadata
- Why exploitation is possible: Submitted
choicedata can be stored without sufficient sanitization and later inserted into option attributes and label content without context-appropriate escaping
Why this happens
The vulnerability results from treating form-submitted data as trusted content across multiple processing stages. The Insert/Update Post action stores the choice value in post meta without sufficient sanitization, while the Select Field template later renders retrieved values without adequate output escaping. This is a CWE-79: Improper Neutralization of Input During Web Page Generation, commonly known as cross-site scripting, because attacker-controlled data can become executable browser content.
Potential impact
- Arbitrary JavaScript may execute in the browser of a user viewing an affected page
- Session-related or page-accessible information could be exposed
- An attacker could alter page content or perform actions in a victim's browser context
- Site reputation and visitor trust could be harmed
General mitigation guidance
Mitigation generally focuses on validating and encoding data at every trust boundary.
Common defensive patterns include:
- Applying allowlist-based validation to form fields that are expected to contain choices or labels
- Sanitizing data before persistence while preserving only the intended data type and structure
- Applying context-appropriate output escaping immediately before inserting values into HTML attributes or element content
- Avoiding the rendering of user-controlled values as markup or executable content
- Restricting unauthenticated form submissions and applying authorization, rate limiting, and abuse controls where appropriate
- Using least-privilege WordPress roles and limiting which content can be modified by public forms
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis rules for unescaped template output and direct insertion of post meta into HTML
- Code review checks tracing unauthenticated input from AJAX handlers through persistence and rendering
- Tests that submit markup-like input to public forms and verify that rendered output is encoded rather than interpreted
- Policy enforcement requiring explicit validation and context-sensitive escaping for all user-controlled template variables
- Automated security review tools that flag stored input flows reaching HTML attributes or element content without encoding
