dbcve.org
Improper Privilege ManagementWeakness · CWE-269

CVE-2026-42289

HIGH · 8.8 CVSS v3.1 Published 2026-05-12
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
95/100
Remediation priority · Urgent
Remotely reachable No privileges

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
ChurchCRM is an open-source church management system. Prior to 7.3.2, UserEditor.php processes user account creation and permission updates entirely through $_POST parameters with no CSRF token validation. An unauthenticated attacker can craft a malicious HTML page that, when visited by an authenticated administrator, silently elevates any low-privilege user to full administrator or creates a new admin backdoor account without the victim's knowledge This vulnerability is fixed in 7.3.2.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

ChurchCRM's UserEditor.php processes user account creation and permission updates through $_POST parameters without CSRF token validation, allowing an unauthenticated attacker to craft a malicious HTML page that tricks an authenticated administrator into silently elevating any user to full administrator or creating a new admin backdoor account.

MitigationUpgrade to ChurchCRM version 7.3.2 or later which implements CSRF token validation on all state-changing operations in UserEditor.php. As a temporary workaround, implement SameSite cookie attributes and manually add CSRF tokens to the user management forms.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify ChurchCRM installation
    Locate the ChurchCRM web application directory and check for the presence of UserEditor.php file within the src directory structure (commonly at /src/UserEditor.php or /modules/UserEditor.php)
    Affected if UserEditor.php file exists in the ChurchCRM installation
  2. Determine installed ChurchCRM version
    Check the version.php file, composer.json, or version header in the application for the installed ChurchCRM version number
    Affected if Installed version is below 7.3.2 (versions prior to the security patch)
  3. Verify CSRF token validation exists in UserEditor.php
    Open UserEditor.php and search for CSRF token validation logic - look for functions like validateToken(), verifyCSRFToken(), or token checks using $_POST['csrf_token'] or $_SESSION['csrf_token']
    Affected if UserEditor.php contains no CSRF token validation code for $_POST parameters handling user creation or permission changes
  4. Check for SameSite cookie configuration
    Inspect the application cookie configuration or session settings for SameSite attribute; this is a secondary mitigation that should be present if CSRF tokens are not implemented
    Affected if SameSite cookie attributes are not configured and CSRF validation is missing
  5. Audit admin accounts for unauthorized changes
    Review the user database table (typically persons or user tables) for any admin-level accounts created or modified around the time of potential exposure, or check user_permission tables for unexpected administrator role assignments
    Affected if Unexpected administrator accounts exist or user permissions were modified without documented admin action

The environment is affected if ChurchCRM is installed with a version below 7.3.2 AND UserEditor.php processes user operations without CSRF token validation.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade to ChurchCRM version 7.3.2 or later which implements CSRF token validation on all state-changing operations in UserEditor.php. As a temporary workaround, implement SameSite cookie attributes and manually add CSRF tokens to the user management forms.

Recommended fix High confidence

7.3.2

  1. 1. Back up the current ChurchCRM database and all files
  2. 2. Download ChurchCRM version 7.3.2 from the official repository (github.com/ChurchCRM/CRM)
  3. 3. Review the official upgrade documentation at docs.churchcrm.io for version 7.3.2 specific upgrade instructions
  4. 4. Replace the existing application files with the new version 7.3.2 files, preserving any custom configuration
  5. 5. Run any database migration scripts included in the 7.3.2 release
  6. 6. Verify the upgrade by logging in and confirming UserEditor.php now includes CSRF token validation
  7. 7. Test that user creation and permission updates work correctly with the new CSRF protection
Caveat Review release notes for 7.3.2 to check for any breaking changes or required configuration updates

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation2.0 h
  • Implementation4.0 h
  • Testing3.0 h
  • Review / QA2.0 h
11.0 hours of engineering $1,930
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,088.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-42289 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-42289 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data