ElementsKit Lite EUVD-2026-90800

Requires an authenticated WordPress account with at least contributor-level privileges (PR:L) on a site running ElementsKit Elementor addons Lite ≤4.0.6 with Elementor active, AND a victim who subsequently views the page containing the injected ElementsKit widget content (UI:R). Limiting factors: exploitation is not possible for fully unauthenticated attackers, the payload is inert until a victim loads the affected page, and impact per the vector is partial (C:L/I:L). No specific non-default configuration is documented beyond having the plugin installed and the attacker holding a content-authoring role.

This is a medium-severity authenticated Stored XSS (CWE-79) carrying a vendor (Patchstack) CVSS 3.1 of 6.5 (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L). The vector signals the realistic ceiling: exploitation requires a low-privileged authenticated account (PR:L - a contributor-or-above WordPress user), the payload only fires when a victim actually views the injected page (UI:R), and the impact is partial across all three dimensions (C:L/I:L/A:L) with a scope change (S:C) reflecting script execution crossing into the victim's browser security context. No EPSS score, no CISA KEV listing, and no public POC accompany this entry, so exploitation status is 'no public exploit identified at time of analysis' - this is not a drop-everything priority. The A:L (availability) component is weakly justified for a stored XSS and I lean toward A:N, which would nudge the score slightly lower (~6.1); treat the 6.5 as the vendor's upper-bound reading. Overall this is a genuine but gated issue: real priority is MEDIUM, elevated in practice only because the affected plugin is very widely deployed (ElementsKit Lite has roughly 1M+ installs), which raises aggregate attack-surface exposure even though per-site risk is constrained by the authentication and user-interaction prerequisites.

A low-privileged authenticated user (e.g. a contributor-level account) submits content through an ElementsKit widget/field that fails to neutralize script input, storing a malicious payload. When an administrator or other visitor subsequently views the page containing that widget, the script executes in their browser session (scope change), enabling session/cookie theft, admin-action forgery, or defacement. No public exploit code is identified at time of analysis; exploitation requires both a foothold account and a victim viewing the injected page.