CVE-2026-13704: GiveWP Stored XSS Vulnerability in Donation Plugin

Technical summary

CVE-2026-13704 is a stored XSS vulnerability (CWE-79) in GiveWP's handling of the 'sequoia[introduction][image]' parameter. The plugin fails to adequately sanitize user input before storage and does not properly escape output when rendering the field on the frontend. An authenticated attacker with Give Worker role or above can inject arbitrary JavaScript that persists in the WordPress database. The payload executes in the browser context of any user who accesses the affected donation form or page, with the attacker gaining the ability to read or modify sensitive information and carry out actions on behalf of the victim. The CVSS 3.1 score of 6.4 (Medium) reflects the network-accessible nature, low attack complexity, and requirement for authentication, balanced against limited direct impact to confidentiality and integrity without availability impact.

Business impact

Organizations using GiveWP to accept donations face reputational and financial risk. Donors accessing injection points could be redirected to phishing pages, have credentials captured, or infected with malware. Beyond immediate data breach exposure, organizations may face GDPR or PCI DSS compliance violations if donor payment information is exfiltrated through XSS payloads. Trust erosion among donors is a secondary but significant concern; disclosed vulnerabilities in donation platforms damage brand reputation. Additionally, if attackers inject coin miners or redirect traffic, site performance degradation affects all users. Remediation must prioritize both patching and forensic review of configuration history.

Affected systems

All GiveWP plugin versions up to and including 4.16.1 are vulnerable. WordPress installations running GiveWP in any capacity—whether single donation pages, recurring giving campaigns, or fundraising platforms—are in scope. The vulnerability is only exploitable by accounts with Give Worker role or higher, so organizations that have tightly scoped user roles have a reduced attack surface. However, compromised or disgruntled staff accounts, as well as accounts gained via secondary credential compromise (e.g., WordPress admin accounts), can exploit this vulnerability. Any Give Worker–level account should be considered a potential attack vector.

Exploitability

Exploitation requires valid WordPress authentication with Give Worker role or equivalent administrative capability within the plugin. No public exploit code is known to exist, and the vulnerability does not appear on the CISA Known Exploited Vulnerabilities (KEV) list as of the published date. However, the attack is straightforward: an attacker logs in, edits a donation form, modifies the image introduction field with JavaScript payload, saves, and the payload executes on all subsequent views. The low attack complexity and lack of special technical requirements (no race conditions, no multi-step interaction) make this a reliable attack vector once authentication is obtained. Organizations should assume that any compromised Give Worker account represents immediate exploitation risk.

Remediation

Upgrade GiveWP to the patched version released following this advisory. Verify against the vendor's official security advisory for the specific version number. Until patching is feasible, restrict Give Worker role assignments to trusted administrators only, implement strict access controls on administrative accounts, and monitor user role assignments for unauthorized changes. Input validation and output escaping improvements should be verified in patch release notes. As a temporary detection measure, review recent edits to donation form 'sequoia[introduction][image]' fields for suspicious JavaScript patterns. After patching, conduct a forensic review of configuration history using database audit logs or WordPress backup snapshots to identify any injected payloads that may have been stored during the vulnerable window.

Patch guidance

Consult the GiveWP official security advisory and release notes for the specific patch version that addresses CVE-2026-13704. Apply patches in a staged fashion: test in a staging environment first to confirm no donation form functionality is broken. Given that the vulnerability is in the admin interface and relies on authenticated access, patching can typically be done without extended downtime. Review and verify the patch notes to confirm that both input sanitization of the 'sequoia[introduction][image]' parameter and output escaping on the frontend have been hardened. After patching, inspect existing donation form configurations for any suspicious JavaScript and remove or remediate as needed.

Detection guidance

Monitor WordPress database logs or query logs for INSERT/UPDATE operations on tables storing GiveWP donation form metadata, particularly those involving the 'sequoia[introduction][image]' field. Look for patterns containing common XSS indicators: <script>, javascript:, onerror=, onload=, etc. In web server access logs, search for POST requests to GiveWP admin pages (wp-admin paths) coming from unusual IP addresses or at unusual times. Review WordPress audit logs (if a logging plugin is in use) for Edit Donation Form actions by Give Worker accounts. Implement WAF or application-level monitoring to detect JavaScript injection attempts in form fields. Finally, use automated security scanners that detect stored XSS payloads by crawling pages and analyzing DOM content.

Why prioritize this

Although this is a Medium-severity vulnerability (CVSS 6.4), it warrants near-term prioritization because (1) exploitation is trivial once authentication is obtained, (2) impact is persistent and site-wide, (3) donors' trust and payment information are at direct risk, and (4) remediation involves a straightforward upgrade with no known blocking issues. Organizations handling sensitive donor data or accepting payments should treat this as a higher priority than the base score suggests. The fact that it does not yet appear on the CISA KEV list provides a window for proactive patching before adversary adoption increases.

Risk score, explained

The CVSS 3.1 score of 6.4 reflects (1) Network-accessible attack surface (AV:N), (2) Low attack complexity—no special conditions required (AC:L), (3) Requirement for valid authentication with Give Worker role (PR:L), (4) No user interaction needed for payload execution once injected (UI:N), (5) Changed scope—payload executes in victim browsers, not attacker's (S:C), and (6) Limited direct impact on confidentiality and integrity (C:L, I:L) but no availability impact (A:N). The score does not account for business context (donor trust, compliance exposure) or the ease of lateral movement from a compromised staff account. Risk assessment should incorporate organizational factors beyond the base CVSS score.

Frequently asked questions