Smart Forms EUVD-2026-93236

Exploitation requires a victim to interact (UI:R) with attacker-controlled input processed by the Smart Forms plugin (<= 2.6.104) on a WordPress site - typically by following a crafted link or loading a page that reflects/stores the unsanitized value. No authentication is needed by the attacker (PR:N), but the payload only fires in the browser of the user who performs the interaction, and the highest-value impact depends on that victim being a logged-in or administrative user; a site with the plugin inactive or already updated past 2.6.104 is not exploitable. The description does not name a specific form field or configuration toggle, so the exact injection point is not confirmed from available data.

This is a genuine but moderate-priority issue rather than an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L, base 7.1) describes a network-reachable, low-complexity, unauthenticated flaw whose scope change (S:C) reflects the typical cross-context impact of stored/reflected XSS executing in a victim's browser. The critical limiter is UI:R - exploitation requires a victim (likely an administrator or site user) to interact with attacker-controlled input, so this is not a hands-off mass-exploitation primitive. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so there is no evidence of active exploitation; this currently reads as a credible-but-theoretical vulnerability disclosed through Patchstack's coordinated program. The three signals are mutually consistent (high-ish CVSS driven by scope/unauthenticated reach, but no exploitation-maturity signals), so there is no contradiction to flag - the main caveat is that exploitation realism hinges on the user-interaction requirement, which raw CVSS under-weights.

An unauthenticated attacker crafts a malicious link or form input targeting a WordPress site running Smart Forms <= 2.6.104 and lures a logged-in user or administrator into interacting with it. When the page renders the unsanitized input, attacker-supplied JavaScript executes in the victim's browser session, enabling actions such as session/cookie theft or admin-context requests. No public proof-of-concept is identified at time of analysis, and successful exploitation depends on the victim taking the required interaction.