GiveWP Plugin EUVD-2026-44859

Exploitation requires the attacker to hold an authenticated WordPress account with give worker-level role or higher - unauthenticated exploitation is not possible. The WordPress site must have the GiveWP plugin installed and active with a donation form configured to use the Sequoia template (a non-default template choice rather than the standard GiveWP form). The social sharing feature (specifically the Twitter/X sharing button) must be displayed on the Sequoia donation confirmation view. Payload detonation further requires that a real donor completes a donation on that form and then actively clicks the 'Share on Twitter' button on the confirmation page - without this victim interaction, the stored payload never executes. Limiting factors include: authenticated attacker prerequisite (give worker role is not publicly self-registerable on most sites), non-default Sequoia template requirement, and mandatory victim click interaction on the Twitter sharing button.

The NVD CVSS 3.1 score of 6.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) warrants scrutiny. The UI:N metric is inconsistent with the CVE description, which explicitly states the script executes 'when a donor clicks the Share on Twitter button' - that is victim-side user interaction (UI:R). Treating this as UI:N overstates exploitability; the independently assessed vector (UI:R) yields a lower base score closer to 5.4. The S:C (Scope Changed) component is correctly assigned because the payload executes in a donor's browser session, crossing the security boundary between the WordPress server component and the victim client. PR:L correctly reflects the give worker-level authentication barrier, which meaningfully limits the attacker pool to individuals with existing, non-trivial access to the WordPress backend. No EPSS data was provided, and the vulnerability is not in CISA KEV, indicating no confirmed active exploitation. Real-world risk is moderate: the attack requires a legitimately credentialed backend user, the victim must use the Sequoia template and actively click the Twitter sharing button, and impact is limited to browser-side confidentiality and integrity of the donor's session - no server-side code execution or availability impact.

An attacker with give worker-level credentials logs into the WordPress admin dashboard and navigates to the Sequoia template settings for a donation form, injecting a JavaScript payload into the twitter_message field - for example, breaking out of the template literal to steal the donor's session cookie or redirect them to a phishing page. A donor then completes a donation, sees the Sequoia confirmation screen, and clicks the 'Share on Twitter' button, at which point the unescaped template literal evaluates the attacker-controlled value and executes the script in the donor's browser context. No public exploit code has been identified at time of analysis, but the vulnerability is straightforward to exploit given the publicly documented source code path.