JetFormBuilder EUVD-2026-83499

Requires an authenticated account with the capability to create or manage JetFormBuilder forms (PR:H - typically an administrator or delegated form-editor role) to configure a custom field-validation callback pointing to a PHP file-deletion function that the plugin's blocklist fails to block. The deletion executes when the form is submitted, which itself needs no authentication, but the weaponization step is gated behind form-management privileges. Exploitation is limited to JetFormBuilder versions 3.5.6.2 through before 3.6.5.3; sites that do not delegate form-management capability to untrusted users face materially lower risk since the privileged step requires a trusted actor.

This is a moderate-priority issue rather than a critical one, and the signals are broadly consistent. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:L = 5.5 Medium) correctly captures the two-step nature of the flaw: weaponization requires HIGH privileges (PR:H - a user with the capability to create/manage JetFormBuilder forms, typically admin or a form-editor role), even though the destructive action itself fires on an unauthenticated form submission. Public exploit code exists (WPScan) but there is no EPSS score and no CISA KEV listing provided, so there is no evidence of active or widespread exploitation - the POC signal indicates feasibility, not exploitation. The high-privilege prerequisite is the dominant risk-limiter: an attacker who can already manage forms is a trusted/privileged actor, which sharply narrows the realistic threat to malicious insiders, compromised admin accounts, or multi-author/agency sites where form-editing is delegated. One notable point of tension: the input Tags label this 'Information Disclosure,' but the CWE (CWE-73) and impact metrics (C:N, I:L, A:L) describe arbitrary file DELETION, not disclosure - the tag is mislabeled. I also consider the A:L rating potentially conservative, since deleting wp-config.php or core files could cause serious availability loss or enable a reinstall-based takeover; this is captured in confidence notes rather than treated as confirmed.

An attacker with form-management capability (e.g., a malicious sub-admin, editor with form access on a multi-author site, or a compromised admin account) creates or edits a JetFormBuilder form and sets a custom field-validation callback to a PHP file-deletion function that the plugin's blocklist fails to block. When any visitor submits the form - an action requiring no authentication - the callback executes and deletes an attacker-specified file on the server, such as wp-config.php or a core plugin file. Public proof-of-concept detail is available via WPScan.