ThemeHunk Customizer EUVD-2026-107275

Exploitation requires the attacker to deliver a crafted URL containing the XSS payload and to convince a victim with an active session (UI:R in the vector) to open it - the flaw cannot fire without this user interaction, which is the primary limiting factor. No authentication is needed on the attacker side (PR:N), so any remote actor can generate the malicious link against a site running ThemeHunk Customizer version 2.8.7 or earlier. Impact is confined to script execution in the victim's browser context; it does not grant direct server-side access, and value depends on a privileged user (e.g., an admin) being the one who clicks.

This is a Reflected Cross-Site Scripting flaw (CWE-79) in the ThemeHunk Customizer WordPress plugin. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L, score 7.1) indicates a network-reachable, low-complexity, unauthenticated attack that requires victim interaction and crosses a privilege/scope boundary - all consistent with classic reflected XSS, where a crafted link must be opened by a logged-in user. No EPSS score, KEV listing, POC, or SSVC decision data was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the only reported source is Patchstack's vulnerability database. Reflected XSS is a genuine but second-tier priority: it is not server-side RCE and depends on social-engineering a user into clicking an attacker-controlled URL, so despite the HIGH 7.1 rating the realistic risk is moderate and targeted rather than wormable. The limited C/I/A impacts (all Low) reflect script execution scoped to the victim's browser session, not full site compromise. No signals conflict, but the complete absence of EPSS/KEV/POC telemetry means exploitation likelihood cannot be independently quantified.

An attacker crafts a URL pointing at a vulnerable ThemeHunk Customizer endpoint with a malicious script embedded in a reflected parameter, then lures a WordPress administrator or logged-in user into clicking it (e.g., via email or a comment). When the victim opens the link, the unsanitized input is reflected into the page and the script executes in their browser, potentially stealing session tokens or performing actions as that user. No public proof-of-concept was provided in the input.