ElementsKit Lite CVE-2026-103063

Requires an authenticated WordPress account with content-creation privileges (contributor/author or higher) able to reach an ElementsKit Elementor addons Lite widget that persists attacker-controlled input (PR:L). Exploitation is NOT self-triggering: a separate privileged or logged-in user must render the page containing the stored payload for the script to fire (UI:R). Limited to deployments running ElementsKit Lite version 4.0.6 or earlier. No special non-default plugin configuration is indicated in the advisory beyond having the vulnerable widget in use.

This is a moderate-severity stored XSS with no evidence of elevated real-world risk. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L, 6.5) describes a network-reachable, low-complexity flaw that nonetheless requires authentication (PR:L - a contributor/author-level WordPress account) and victim interaction (UI:R - a privileged user must view the page carrying the injected payload). No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided by the sole reporting source (Patchstack), so exploitation status is: no public exploit identified at time of analysis. The scope change (S:C) correctly reflects that script injected in the plugin's context executes against whoever renders the page, but the impact is capped at Low across confidentiality and integrity because stored XSS in an Elementor widget typically yields session/DOM access rather than full account takeover. The A:L (availability) sub-score is questionable for a reflected/stored script issue - it is more defensibly A:N, which would lower the base to roughly 6.1; defenders should not treat this as an availability threat. Net: a genuine but not urgent issue, gated by authentication and user interaction, with no exploitation signal.

An attacker who holds a low-privileged but content-capable WordPress account (e.g., contributor or author) uses an ElementsKit Lite widget field to store a malicious script payload. When an administrator or other logged-in user later opens the page or post containing that widget, the script executes in their browser session, enabling session-riding actions or admin-context DOM manipulation. No public proof-of-concept is available at time of analysis.