ChurchCRM CVE-2026-40483

Exploitation requires all of the following conditions: (1) attacker must be an authenticated ChurchCRM user with Finance role permissions to access the Pledge Editor; (2) attacker must locate and open a pledge record for editing (or create a new one); (3) victim must subsequently open the same pledge record in the Pledge Editor for editing or viewing (user interaction), which occurs in the victim's authenticated browser session. The vulnerability does not affect unauthenticated users or users without Finance permissions. Default ChurchCRM installations with standard role-based access controls (RBAC) naturally limit the attacker population to Finance-permissioned users, which is typically a small subset of organizational staff. If Finance permissions are overly granted or compromised, the attack surface expands. Organizations that disable the Pledge Editor feature entirely are not at risk.

CVSS score of 5.4 (Medium) with network vector, low complexity, and low privilege requirement underestimates real-world risk due to multiple limiting factors. The PR:L (requires Finance role) and UI:R (requires user interaction to view pledge) significantly constrain the threat model-attackers must first gain Finance permissions and wait for victims to access the compromised record. However, the Scope:Changed (S:C) indicates cross-user impact, making this a privilege-escalation vector if an unprivileged user gains Finance access or exploits a Finance user's session. The stored nature of the XSS means the payload persists and affects all subsequent viewers, increasing organizational blast radius compared to reflected XSS. No public exploit code identified, no CISA KEV listing, and no evidence of active exploitation suggests this remains theoretical at time of analysis. The low CVSS score combined with absence of exploitation signals indicates this is a legitimate but lower-priority issue for organizations without strict authentication controls over Finance roles. Organizations with robust Finance permission segregation and content security policies (CSP) can further reduce risk through compensating controls.

A rogue Finance user or attacker who has compromised a Finance account logs into ChurchCRM and opens a pledge record for editing. They inject a malicious payload such as '" onmouseover="fetch('/exfiltrate?cookie='+document.cookie)' into the donation comment field and save the record. When any other user (including administrators or Finance managers) subsequently opens that same pledge record in the editor, the payload executes in their browser context, exfiltrating their session cookies or performing actions on their behalf, such as modifying donor records or financial data.