PHP CVE-2026-40480

Attacker must possess valid authenticated credentials to ChurchCRM with at least EditSelf permission level, which is the default minimum privilege granted to any registered user or volunteer. The vulnerable /api/person/{personId} endpoint must be accessible over the network (standard for all ChurchCRM deployments supporting remote access or mobile clients). No special configuration, non-default features, or additional privileges beyond basic user authentication are required. The application must be running ChurchCRM version 7.1.x or earlier. Exploitation is NOT limited by user interaction (UI:N), privilege level beyond basic authentication (PR:L), or deployment mode. However, the attacker cannot be completely unauthenticated (PR:L excludes PR:N) - the vulnerability requires bypassing object-level authorization after successful user authentication, not bypassing authentication itself. Default ChurchCRM installations are vulnerable without any configuration changes.

Real-world risk is MODERATE-HIGH for organizations running ChurchCRM <7.2.0, despite the 7.1 CVSS score. The attack requires only low-privileged authenticated access (PR:L), which any registered church volunteer or member typically possesses in these systems. Attack complexity is low (AC:L) with network accessibility (AV:N), meaning exploitation requires minimal technical skill - a simple authenticated HTTP request or browser developer tools suffices. The absence of EPSS scoring and KEV listing suggests no widespread automated exploitation or mass-scale targeting, but the public GitHub advisory (GHSA-5w59-32c8-933v) and fix commit provide full implementation details that sophisticated attackers or curious insiders could weaponize. The 'Authentication Bypass' tag is slightly misleading - this is not full authentication bypass but rather authorization bypass after authentication. Primary risk factors: (1) church management systems contain highly sensitive PII including children's data, pastoral notes, and financial records; (2) volunteer users often have legitimate low-level accounts, providing easy initial access; (3) many ChurchCRM instances are self-hosted by non-technical church staff with slow patch cycles. Mitigating factors: exploitation requires existing user credentials (not unauthenticated RCE), and impact is limited to confidentiality (no data manipulation or service disruption). SSVC assessment: exploitation=none (no public POC/KEV), automatable=yes (simple API parameter manipulation), technical_impact=partial (PII disclosure), suggests TRACK priority until exploitation evidence emerges, then escalate to ATTEND.

A volunteer with basic EditSelf privileges (e.g., nursery coordinator, event organizer) authenticates to ChurchCRM with their legitimate credentials. Using browser developer tools or a simple Python script, they enumerate the GET /api/person/{personId} endpoint by iterating personId from 1 to 10000, harvesting full records for all church members including pastoral staff, donors, and families. The attacker compiles names, home addresses, phone numbers, and email addresses into a spreadsheet for sale to marketing firms, identity theft rings, or to facilitate targeted phishing campaigns against church members. The attack leaves minimal forensic trace if API logging is not enabled, and appears as normal authenticated API usage in default server logs.