GiveWP CVE-2026-65464

Successful exploitation requires that a GiveWP site administrator (or a WordPress user with sufficient plugin privileges) be actively authenticated to their WordPress installation at the time of interaction. The CVSS UI:R metric confirms mandatory victim interaction - the victim must navigate to or load attacker-controlled content, such as clicking a malicious link or visiting a compromised page. No special server-side configuration is required; the vulnerability is present in default GiveWP installations at or below version 4.16.3. Exploitation is bounded by two hard limits: the victim must be authenticated to the target WordPress site, and the victim must be induced to interact with attacker-controlled content. These factors rule out fully automated, mass-exploitation scenarios and require targeted social engineering per victim.

The CVSS 3.1 score of 5.4 (Medium) accurately reflects the constrained real-world impact. The vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L indicates low-complexity network exploitation with no attacker authentication required, but mandates victim interaction (UI:R), which is the primary risk reducer. Impact is limited to partial integrity (I:L) and partial availability (A:L) with no confidentiality exposure (C:N), capping the damage at unauthorized modifications or disruption to donation platform settings rather than data exfiltration. No EPSS data was provided in source intelligence; without it, exploitation probability cannot be quantified. The absence of a CISA KEV listing and no identified public POC further support a measured rather than urgent priority. This is a real vulnerability worth patching but not an emergency for most organizations - the social engineering prerequisite substantially limits opportunistic mass exploitation. No conflicting signals were identified between the CVSS vector and the description.

An attacker hosts a page containing a hidden HTML form targeting a sensitive GiveWP admin action endpoint, auto-submitted via JavaScript on page load. The attacker then distributes the link via email or social media to a GiveWP site administrator who is currently logged into their WordPress dashboard. When the administrator's browser loads the attacker's page, it silently submits the forged POST request with the victim's valid session cookies attached, causing GiveWP to execute the unauthorized action. No public exploit code is identified at time of analysis, so exploitation requires manual crafting of the CSRF payload.