GiveWP CVE-2026-96830

Exploitation requires a victim to interact with attacker-controlled input - per UI:R, the target must click a crafted link or load a malicious request that GiveWP reflects without proper output encoding. No authentication is required of the attacker (PR:N), so any remote unauthenticated actor can craft and distribute the payload, but success depends on luring a user (ideally a privileged administrator of a GiveWP-enabled WordPress site) into triggering it. The affected surface is any GiveWP <= 4.16.9 installation; the exact vulnerable parameter/endpoint is not specified in the advisory, which limits precise defensive filtering. The main limiting factors are the mandatory user interaction and the Low (not High) impact ceiling on each of C/I/A.

This is a reflected/unauthenticated Cross-Site Scripting flaw in GiveWP (CWE-79), rated CVSS 7.1 with vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L. The network vector, low complexity, and no-privilege requirement (PR:N) push the base score up, but the practical severity is tempered by two factors: exploitation requires user interaction (UI:R - a victim must click a crafted link or load a malicious request), and the impact metrics are only Low across confidentiality, integrity, and availability. The scope change (S:C) reflects that injected script executes in the victim's browser context rather than the plugin's own, which is typical for XSS. No EPSS score, no CISA KEV listing, and no public POC are provided in the input, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC decision data is supplied. This is a real but moderate-priority issue: it is a genuinely useful attack against high-value targets (WordPress admins of donation sites) but is not a mass-automatable, unauthenticated RCE. Treat it as a patch-in-normal-cycle item rather than an emergency, prioritizing sites where GiveWP handles donor/payment workflows.

An attacker crafts a malicious URL or web request containing a JavaScript payload that GiveWP reflects unsanitized into a page. The attacker delivers this link to a logged-in site administrator or visitor (via email, comment, or social engineering); when the victim loads it, the script runs in their browser under the site's origin, enabling session/cookie theft, admin-action forgery, or injection of fraudulent donation content. No public POC is identified in the provided data, and the required user interaction (UI:R) means the victim must be lured into triggering the request.