CVE-2026-40480: ChurchCRM Auth Bypass Vulnerability

CVE-2026-40480 Overview

CVE-2026-40480 is an Insecure Direct Object Reference (IDOR) vulnerability affecting ChurchCRM, an open-source church management system. In versions prior to 7.2.0, the GET /api/person/{personId} endpoint loads and returns person records without performing object-level authorization checks. Although the legacy PersonView.php page enforces canEditPerson() restrictions, the API layer omits this check entirely.

Any authenticated user with only EditSelf privileges can enumerate and read other members' records, exposing sensitive PII including names, addresses, phone numbers, and email addresses. This authorization bypass allows horizontal privilege escalation where low-privileged users can access data belonging to other members of the organization.

Critical Impact

Authenticated users with minimal privileges can enumerate and access sensitive personal information of all church members, creating significant privacy risks and potential regulatory compliance violations.

Affected Products

• ChurchCRM versions prior to 7.2.0
• ChurchCRM API endpoint GET /api/person/{personId}
• ChurchCRM installations with users having EditSelf privileges

Discovery Timeline

• 2026-04-18 - CVE-2026-40480 published to NVD
• 2026-04-20 - Last updated in NVD database

Technical Details for CVE-2026-40480

Vulnerability Analysis

This vulnerability is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), commonly known as an Insecure Direct Object Reference (IDOR). The fundamental issue stems from an inconsistency between the legacy web interface and the modern API layer in ChurchCRM's authorization model.

The legacy PersonView.php page properly enforces the canEditPerson() authorization check before displaying member data. However, when the REST API was implemented, this critical authorization check was not replicated in the /api/person/{personId} endpoint. This oversight creates a security gap where the API directly returns person records based solely on the provided personId parameter without validating whether the requesting user has permission to access that specific record.

The vulnerability enables horizontal privilege escalation, allowing any authenticated user—even those restricted to only editing their own profile—to access personal data of all other members in the church database by simply iterating through person IDs.

Root Cause

The root cause is the missing object-level authorization check in the API layer. While the legacy PHP page implemented proper access controls through the canEditPerson() function, this validation was not carried forward to the REST API implementation. The API assumes that authentication alone is sufficient, when in fact object-level authorization is required to prevent unauthorized data access.

Additionally, users with no administrative permissions were not properly blocked from API access, allowing accounts with limited privileges to leverage the API endpoints that should have been restricted.

Attack Vector

An attacker with valid but limited credentials (such as a regular church member with only EditSelf privileges) can exploit this vulnerability through the following attack pattern:

1. Authenticate to ChurchCRM using valid credentials
2. Send GET requests to /api/person/{personId} with sequential or enumerated person IDs
3. The API returns full person records without authorization validation
4. The attacker can systematically harvest all member PII from the database

The attack requires network access and valid authentication credentials, but no special privileges beyond basic account access.

// Security patch in src/ChurchCRM/Slim/Middleware/AuthMiddleware.php
// Source: https://github.com/ChurchCRM/CRM/commit/28ea7a2965fc2fe30e150fadb1ae38a97f8225c2

                $logger->debug('API key authentication successful', [
                    'path' => $request->getUri()->getPath()
                ]);

+                // Block users with no admin permissions from API access (GHSA-5w59-32c8-933v)
+                $apiUser = AuthenticationManager::getCurrentUser();
+                if ($apiUser->hasNoAdminPermissions()) {
+                    $response = new Response();
+                    $response->getBody()->write(json_encode(['error' => 'Account has limited permissions. Contact an administrator.']));
+                    return $response->withStatus(403)->withHeader('Content-Type', 'application/json');
+                }
            } elseif (AuthenticationManager::validateUserSessionIsActive(!$this->isPath($request, 'background'))) {
                // validate the user session; however, do not update tLastOperation if the requested path is "/background"
                // since /background operations do not connotate user activity.

+                // Block users with no admin permissions from MVC/API access (GHSA-5w59-32c8-933v)
+                $sessionUser = AuthenticationManager::getCurrentUser();
+                if ($sessionUser->hasNoAdminPermissions()) {
+                    if ($this->isBrowserRequest($request)) {
+                        $rootPath = SystemURLs::getRootPath();
+                        return (new Response())->withStatus(302)->withHeader('Location', $rootPath . '/external/limited-access');
+                    }
+                    // API request — return 403
+                    $response = new Response();
+                    $response->getBody()->write(json_encode(['error' => 'Account has limited permissions. Contact an administrator.']));
+                    return $response->withStatus(403)->withHeader('Content-Type', 'application/json');
+                }

                // User with an active browser session is still authenticated.
                // For browser requests (non-background), enforce any required redirect steps (e.g. forced password change).

Detection Methods for CVE-2026-40480

Indicators of Compromise

• Unusual patterns of sequential GET requests to /api/person/{personId} with incrementing IDs from a single user session
• API access logs showing low-privileged users querying person records they should not have access to
• High volume of person record API requests from accounts with only EditSelf permissions
• Evidence of data exfiltration patterns in application logs

Detection Strategies

• Implement API request logging and monitor for enumeration patterns (sequential ID access)
• Alert on users accessing person records outside their authorized scope
• Deploy web application firewall (WAF) rules to detect IDOR attack patterns
• Review access logs for users with EditSelf privileges accessing multiple person endpoints

Monitoring Recommendations

• Enable detailed API access logging including user ID, requested resource ID, and response status
• Configure alerting for high-frequency API requests to person endpoints from single sessions
• Monitor for failed authentication attempts followed by successful exploitation patterns
• Implement anomaly detection for API usage patterns that deviate from normal user behavior

How to Mitigate CVE-2026-40480

Immediate Actions Required

• Upgrade ChurchCRM to version 7.2.0 or later immediately
• Review API access logs for evidence of exploitation prior to patching
• Audit user accounts and revoke unnecessary API access for low-privileged users
• Notify affected members if data breach is suspected

Patch Information

The vulnerability has been fixed in ChurchCRM version 7.2.0. The patch implements proper authorization checks in the AuthMiddleware.php to block users with no administrative permissions from API access. Users with limited permissions now receive a 403 Forbidden response when attempting to access the API.

For detailed information about the fix, refer to the GitHub Security Advisory, Pull Request #8616, and the commit implementing the fix.

Workarounds

• Restrict API access at the network level to only trusted administrative users until patching is possible
• Implement additional authentication layers (such as IP whitelisting) for API endpoints
• Disable API functionality entirely if not required for operations
• Deploy a reverse proxy or WAF to block suspicious enumeration patterns

# Configuration example - Restrict API access via .htaccess (temporary workaround)
# Add to your ChurchCRM .htaccess file

<Location "/api/person">
    # Restrict to specific admin IP addresses until patch is applied
    Require ip 192.168.1.0/24
    # Or deny all external API access
    # Require all denied
</Location>