Charitable is a widely used WordPress donation and fundraising plugin that enables organizations to create fundraising campaigns, donation forms, recurring payment options, and crowdfunding initiatives. With its drag-and-drop campaign builder and customizable templates, it is trusted by thousands of nonprofits and charities to manage online donations.

During security testing, a Stored Cross-Site Scripting (XSS) vulnerability was identified in versions prior to 1.8.5.3. The vulnerability exists in the campaign builder, where the ALT Text field for campaign images fails to properly sanitize user input before storing and rendering it. As a result, an authenticated administrator can inject malicious JavaScript that is permanently stored and executed whenever the vulnerable content is rendered.

This vulnerability is tracked as CVE-2025-15675.

CVECVE-2025-15675
Plugin VersionCharitable < 1.8.5.3
All Time1 164 573
Active installations10 000+
Publicly PublishedJuly 23, 2026
Last UpdatedJuly 23, 2026
ResearcherArtyom Krugov
PoCYes
ExploitNo
Referencehttps://wpscan.com/vulnerability/19381d34-3942-4ba6-92a9-0290e1006da0/
https://www.cve.org/CVERecord?id=CVE-2025-15675
Plugin Security Certification by CleanTalk
Logo of the plugin

Join the community of developers who prioritize security. Highlight your plugin in the WordPress catalog.

PSC by Cleantalk

Timeline

April 25, 2025Plugin testing and vulnerability detection in Charitable were completed.
April 25, 2025The vulnerability was reported with PoC, description, and recommendations for remediation.
July 23, 2026CVE-2025-15675 was publicly published by WPSCAN.

Discovery of the Vulnerability

The vulnerability was discovered while testing the image configuration options available during campaign creation.

Specifically, the ALT Text field within the campaign image settings accepts arbitrary input but does not correctly sanitize or escape HTML attributes before rendering them in the generated page.

An attacker with administrative privileges can inject a malicious payload that becomes permanently stored in the WordPress database.

Understanding of Stored XSS attacks

Stored Cross-Site Scripting (Stored XSS) occurs when malicious input is permanently stored by the application and later rendered to users without proper sanitization or output encoding.

Unlike reflected XSS, stored XSS requires only a single successful injection. Every subsequent visitor to the affected page may trigger execution of the malicious script.

In WordPress, Stored XSS vulnerabilities are commonly found in:

Plugin configuration pages
Gutenberg block settings
Widget configuration fields
Image metadata (ALT text, captions, descriptions)
SEO metadata
Form builders
Custom fields

These vulnerabilities become especially dangerous when the injected content is viewed by privileged users, allowing attackers to hijack administrator sessions or perform actions on their behalf.

Exploiting the Stored XSS Vulnerability

The vulnerability was discovered while testing the image configuration options available during campaign creation.

Specifically, the ALT Text field within the campaign image settings accepts arbitrary input but does not correctly sanitize or escape HTML attributes before rendering them in the generated page.

An attacker with administrative privileges can inject a malicious payload that becomes permanently stored in the WordPress database.

POC:

POC:
1.Log in to the WordPress administration panel.
2.Navigate to Charitable → Campaigns.
3.Create a new fundraising campaign.
4.Select any campaign template.
5.Open the Standard tab.
6.Choose Photo.
7.Insert the following payload into the ALT Text field:
123123"onmouseover=alert(999)

____

When the affected image is rendered and interacted with, the injected JavaScript executes.

Recommendations for Improved Security

To mitigate the risks associated with CVE-2025-15675, administrators should immediately update the Charitable plugin to version 1.8.5.3 or later. Developers should ensure that all image metadata fields, particularly the ALT Text field, are properly sanitized before being stored and securely escaped before being rendered into HTML attributes. WordPress functions such as sanitize_text_field(), esc_attr(), and wp_kses() should be consistently applied to prevent malicious attribute injection. Implementing a strict Content Security Policy (CSP) can further reduce the impact of stored XSS attacks by preventing the execution of unauthorized inline scripts. Administrators should regularly audit fundraising campaigns and media metadata for unexpected values, restrict campaign management permissions to trusted users only, and periodically review administrator activity for suspicious modifications. To prevent this type of attack, the vendor adopted our recommended prevention methods, focusing on comprehensive input validation, secure output encoding, and proper handling of HTML attribute contexts.

By addressing Stored XSS like CVE-2025-15675, WordPress site owners can reduce the risk from unsafe media metadata and protect visitors from browser-side compromise. Stay vigilant, stay secure.

#WPSCANSecurity #StoredXSS #WebsiteSafety #StayProtected #Vulnerability

Use CleanTalk solutions to improve the security of your website

CVE-2025-15675 – Charitable < 1.8.5.3 – Admin+ Stored XSS – POC

Artyom Krugov

Cybersecurity Specialist with 4 years of hands-on experience in web application and WordPress security. Holder of the OSCP+ certification and author of 80+ publicly disclosed CVEs affecting WordPress plugins and themes. Specialized in vulnerability research, penetration testing, website incident response, malware removal, and security hardening of production environments. Experienced in identifying and validating high-impact vulnerabilities in WordPress plugins, themes, and custom web applications, as well as providing practical remediation guidance to improve overall security posture. Strong background in web application security, source code review, vulnerability assessment, exploit validation, and post-compromise recovery of infected websites.

Visit Author's Website

See all posts by krugov-artyom

Leave a Reply

Your email address will not be published. Required fields are marked *