Cool FormKit Lite EUVD-2026-113714

Requires an authenticated WordPress account with contributor-level capability or above on the target site, sufficient to create or edit an Elementor form widget and set the per-field custom_id value (the '_elementor_data.form_fields[].custom_id' parameter). The payload only fires when a user - including unauthenticated visitors - subsequently loads a page that renders the affected form, because execution occurs client-side when the plugin's logic-frontend.js runs jQuery .html() on the server-emitted <template>, at which point HTML fragment serialization restores the escaped &quot; to a raw double-quote and the custom_id escapes its attribute context. Limiting factors: the contributor authentication barrier (not exploitable by anonymous users), dependence on the conditional-fields/logic code path that processes custom_id into the frontend template, and the need for a victim to actually visit the injected page; affected only up to and including version 2.7.9.

This is a moderate-priority, not emergency-tier, issue. The CVSS 3.1 base score of 6.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) reflects a network-reachable but privilege-gated flaw: PR:L confirms an authenticated account (contributor-level or above per the description) is required, which materially limits the attacker population to users who can already create or edit Elementor forms. The vuln.today decision label is 'this_month' (not act_now or emergency), consistent with a stored XSS that needs a foothold rather than a wormable unauthenticated bug. No CISA KEV listing is present, so there is no confirmed active exploitation; no EPSS score was provided in the input, so exploitation probability cannot be quantified here; and no public PoC or exploit reference appears among the sources (only vendor advisory and source-code links), so this is 'no public exploit identified at time of analysis.' The signals are internally consistent - a medium-severity, authenticated, contributor-gated stored XSS with a vendor fix available - and point to real but bounded risk rather than a high-urgency drop-everything event. The main residual uncertainty is the missing EPSS value and the trust model of the site: on multi-author WordPress installs where contributor accounts are freely granted, the effective privilege barrier is low and the S:C/scope-change into site visitors' browsers raises the practical impact.

An attacker who holds a WordPress contributor account (or higher) on the target site edits an Elementor form and plants a crafted value in a form field's custom_id. When any visitor later loads the page containing that form, the plugin's logic-frontend.js extracts the template via jQuery .html(), the serialization restores the escaped quote to a raw double-quote, the custom_id breaks out of its HTML attribute context, and the attacker's script executes in the victim's browser. No public exploit code was identified at time of analysis, and exploitation requires the authenticated contributor foothold plus a victim visiting the affected page.