JetFormBuilder EUVD-2026-71846

The target WordPress site must have JetFormBuilder - Dynamic Blocks Form Builder installed, active, and at a version below 3.6.5.2, with at least one publicly accessible page containing a JetFormBuilder form block. No authentication, elevated privilege, or user interaction is required - exploitation occurs via a standard unauthenticated HTTP request during page rendering. The CVSS vector (AV:N/AC:L/PR:N/UI:N) confirms this. The attack is limited to confidentiality: attackers cannot write data through this vector. Sites running JetFormBuilder 3.6.5.2 or later, or sites with the plugin deactivated, are not affected.

The CVSS 7.5 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) is well-calibrated: exploitation requires no authentication or user interaction, and the confidentiality impact is high because the leaked data includes password hashes suitable for offline cracking. Despite this, the EPSS score of 0.16% (5th percentile) signals minimal observed exploitation so far - likely reflecting the plugin's moderate install base rather than any technical barrier to exploitation. The publicly available PoC, reported by WPScan, lowers the bar for opportunistic attackers substantially. No CISA KEV listing means active exploitation is not yet confirmed, but with a working exploit circulating, the gap between 'known' and 'exploited' is narrow. Even a mid-sized municipal IT team in leszno should treat this as urgent given that exfiltrated password hashes can enable downstream account takeover, and private post or metadata leakage may trigger GDPR obligations. No integrity or availability impact is reported, which limits the blast radius but does not diminish the data-breach risk.

An unauthenticated attacker identifies a WordPress site running JetFormBuilder before 3.6.5.2 - trivially detectable via plugin readme or HTTP headers - and sends a crafted HTTP GET or POST request to a page with an active JetFormBuilder form, embedding references to internal WordPress data sources such as user password hashes or private post fields. The plugin's rendering engine resolves these references without authorization, returning the sensitive data in the HTTP response. With a publicly available proof-of-concept, this attack can be scripted for bulk scanning of WordPress installations.