JetBlocks For Elementor EUVD-2026-81497

Requires an authenticated WordPress account with at least Contributor privileges (PR:L) on a site running JetBlocks For Elementor <= 1.5.2, plus the Elementor page builder that this add-on extends. Exploitation is not automatic: a higher-privileged user (e.g., administrator or editor) must subsequently view the attacker-injected content for the stored script to execute (UI:R). Limiting factors: no anonymous/unauthenticated path, dependence on the site permitting Contributor-role registration or an already-compromised low-privilege account, and the need for victim interaction - which together make mass or drive-by exploitation impractical.

This is a moderate, low-priority issue in real-world terms. The vendor (Patchstack) CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L) reflects a stored/contributor-level XSS: network reachable and low complexity, but gated by authenticated Contributor privileges (PR:L) and requiring victim interaction (UI:R), typically an administrator or higher-privileged user viewing the injected content. The scope change (S:C) and split Low impacts across C/I/A are the standard Patchstack pattern for reflected/stored XSS that executes in a victim's browser session. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data - so exploitation status is 'no public exploit identified at time of analysis.' There is no conflict between the CVSS vector and the description; both indicate authenticated, interaction-dependent web exploitation. The main caveat is that no fixed version is provided, which complicates remediation planning. Overall this is a routine WordPress-plugin XSS requiring an insider or compromised low-privilege account, not an urgent internet-facing threat.

An attacker who holds (or has phished/registered) a WordPress Contributor account on a site running JetBlocks For Elementor <= 1.5.2 injects a malicious script payload through a plugin input field that is insufficiently sanitized. When an administrator or editor later views the contributed content in wp-admin or on a rendered page, the script executes in their authenticated browser context, enabling session/cookie theft or admin-action forgery. No public proof-of-concept is identified in the provided data.