CVE-2026-40485: ChurchCRM User Enumeration Vulnerability

CVE-2026-40485 Overview

CVE-2026-40485 is a username enumeration vulnerability affecting ChurchCRM, an open-source church management system. In versions prior to 7.2.0, the public API login endpoint (/api/public/user/login) returns distinguishable HTTP response codes based on whether a username exists in the system. The endpoint returns a 404 status code for non-existent users and a 401 status code for valid users with incorrect passwords. This information disclosure allows unauthenticated attackers to enumerate valid usernames within the system, with no rate limiting or account lockout mechanisms to impede the enumeration process.

Critical Impact

Attackers can enumerate valid usernames without authentication, enabling targeted credential attacks against confirmed user accounts in church management systems that often contain sensitive member data.

Affected Products

• ChurchCRM versions prior to 7.2.0
• ChurchCRM public API login endpoint (/api/public/user/login)
• Self-hosted ChurchCRM installations with exposed API endpoints

Discovery Timeline

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

Technical Details for CVE-2026-40485

Vulnerability Analysis

This vulnerability is classified under CWE-204 (Observable Response Discrepancy), which occurs when an application reveals sensitive information through differences in its responses to similar requests. In the context of ChurchCRM, the login API endpoint leaks information about the existence of user accounts by returning different HTTP status codes depending on whether the provided username is valid.

The attack requires no authentication and can be performed remotely over the network with minimal complexity. While the direct impact is limited to confidentiality (leaking whether usernames exist), this information serves as a critical stepping stone for more severe attacks such as password spraying, credential stuffing, and targeted phishing campaigns against confirmed users.

Root Cause

The root cause of this vulnerability lies in the authentication handler's response logic within the Slim framework integration. The application returns a 404 (Not Found) HTTP status when a username does not exist in the database, but returns a 401 (Unauthorized) status when the username exists but the password is incorrect. This differential response creates an oracle that attackers can use to confirm valid usernames. Additionally, the absence of rate limiting and account lockout mechanisms allows automated tools to rapidly enumerate accounts without restriction.

Attack Vector

The attack is executed via network-accessible API requests to the public login endpoint. An attacker can script automated requests with various username guesses, observing the HTTP response codes to determine which usernames are valid accounts. The network attack vector combined with no authentication requirements and no user interaction makes this vulnerability easily exploitable at scale. Attackers typically use wordlists containing common names, email formats, or previously leaked credentials to maximize enumeration efficiency.

The security patch addresses this issue by hardening the API login responses and includes additional fixes for SQL injection vulnerabilities in the FinancialService component:

 use Exception;
 use Psr\Http\Message\ResponseInterface as Response;
 use Psr\Http\Message\ServerRequestInterface as Request;
+use Slim\Exception\HttpBadRequestException;
+use Slim\Exception\HttpForbiddenException;
 use Slim\Exception\HttpMethodNotAllowedException;
 use Slim\Exception\HttpNotFoundException;
+use Slim\Exception\HttpUnauthorizedException;
 use Slim\Interfaces\RouteInterface;
 use Slim\Psr7\Response as Psr7Response;
 use Slim\Routing\RouteContext;

Source: GitHub Commit

The patch also includes parameterized queries to prevent SQL injection:

         if (!$routeAndAccount) {
             throw new \Exception('error in locating family');
         }
-        $sSQL = 'SELECT fam_ID, fam_Name FROM family_fam WHERE fam_scanCheck="' . $routeAndAccount . '"';
-        $rsFam = FunctionsUtils::runQuery($sSQL);
-        $row = mysqli_fetch_array($rsFam);
+        $family = FamilyQuery::create()->findOneByScanCheck($routeAndAccount);
         $iCheckNo = $micrObj->findCheckNo($tScanString);

         return [
             'ScanString'      => $tScanString,
             'RouteAndAccount' => $routeAndAccount,
             'CheckNumber'     => $iCheckNo,
-            'fam_ID'          => $row['fam_ID'],
-            'fam_Name'        => $row['fam_Name'],
+            'fam_ID'          => $family?->getId(),
+            'fam_Name'        => $family?->getName(),
         ];
     }

Source: GitHub Commit

Detection Methods for CVE-2026-40485

Indicators of Compromise

• High volume of authentication requests to /api/public/user/login from single IP addresses
• Sequential or patterned username attempts in authentication logs
• Unusual ratio of 404 to 401 responses on the login endpoint
• Automated request patterns with consistent timing intervals between attempts

Detection Strategies

• Monitor web server access logs for repeated POST requests to the login API endpoint with varying usernames
• Implement alerting on unusual authentication failure patterns that suggest enumeration activity
• Analyze HTTP response code distributions for the login endpoint to identify reconnaissance activity
• Deploy web application firewall (WAF) rules to detect and block rapid sequential authentication attempts

Monitoring Recommendations

• Enable detailed logging for all authentication endpoints including HTTP status codes and source IPs
• Configure SIEM rules to correlate multiple failed authentication attempts across short time windows
• Monitor for known username enumeration tools and their characteristic request patterns
• Establish baseline metrics for normal authentication traffic to identify anomalous enumeration activity

How to Mitigate CVE-2026-40485

Immediate Actions Required

• Upgrade ChurchCRM to version 7.2.0 or later immediately
• Implement rate limiting on the /api/public/user/login endpoint using a reverse proxy or WAF
• Review authentication logs for signs of prior enumeration attempts
• Consider implementing CAPTCHA or similar challenge mechanisms for repeated failed login attempts

Patch Information

The vulnerability has been addressed in ChurchCRM version 7.2.0. The fix normalizes API login responses to return consistent status codes regardless of whether the username exists, preventing attackers from distinguishing between valid and invalid usernames. The patch is available via GitHub Pull Request #8607 and the specific commit 214694eb83778e1f5e52b3dfa2a99d0e965c1850. For complete technical details, refer to the GitHub Security Advisory GHSA-x2qh-xmhq-4jpx.

Workarounds

• Deploy a reverse proxy with rate limiting configured for authentication endpoints
• Implement IP-based blocking for sources exceeding authentication attempt thresholds
• Restrict API access to trusted networks using firewall rules if public access is not required
• Consider placing authentication endpoints behind a VPN or network access control system

# Example nginx rate limiting configuration for ChurchCRM API
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;

location /api/public/user/login {
    limit_req zone=login_limit burst=3 nodelay;
    limit_req_status 429;
    proxy_pass http://churchcrm_backend;
}