aBlocks CVE-2026-40804

Exploitation requires an attacker to trick a user of the affected WordPress site into clicking a specially crafted link that carries the XSS payload (UI:R), since this is reflected rather than stored XSS - the payload is not persisted and must be delivered per-victim. No authentication is required of the attacker (PR:N), but successful impact typically depends on the victim being a privileged user (e.g., an administrator) whose browser session the script then abuses. The description does not name the exact vulnerable parameter, feature, or configuration, so any aBlocks ≤ 2.16.0 installation appears potentially affected; the primary limiting factor is the required victim interaction.

This is a moderate-severity reflected XSS (CWE-79) in the aBlocks WordPress plugin, scored CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L). The network vector, low attack complexity, and no-privilege requirement push the score up, but the mandatory user interaction (UI:R) materially lowers real-world risk because an attacker must lure a victim into clicking a crafted link rather than exploiting the site directly. No EPSS probability was supplied in the input, no CISA KEV listing is present, and no public proof-of-concept is referenced, so there is no signal of active or imminent widespread exploitation - the only source is a Patchstack database entry. The scope-change (S:C) and the low impact across confidentiality, integrity, and availability are consistent with reflected XSS executing in the victim's browser session. Net assessment: a legitimate issue worth patching on a normal cycle, but currently a lower operational priority than its 7.1 would suggest in isolation, given the interaction requirement and absence of any exploitation evidence.

An attacker crafts a malicious URL targeting a vulnerable aBlocks parameter and delivers it to a WordPress site user (for example a logged-in administrator) via phishing email or a link on another site. When the victim clicks the link, unsanitized input is reflected into the generated page and the attacker's JavaScript executes in the victim's browser in the context of the WordPress site, potentially hijacking the session or performing actions as that user. No public exploit code was identified at time of analysis.