Which versions of PHP are affected by CVE-2026-40480?

ChurchCRM versions 7.1.x and earlier contain a broken authorization flaw in the API layer that allows any authenticated user-even those with minimal privileges-to access and export sensitive personal…

How to fix or mitigate CVE-2026-40480?

Within 24 hours: Audit access logs for suspicious GET requests to /api/person/* endpoints and confirm current ChurchCRM version. Within 7 days: Upgrade ChurchCRM to version 7.2.0 or later immediately, as this is a critical authorization bypass affecting all authenticated users. Within 30 days: Conduct a full access audit of the person API endpoint to identify any unauthorized data extraction; notify affected members and leadership of the vulnerability and remediation steps; implement network-level API logging and alerting for person data access.

PHP CVE-2026-40480

Q: What is the CVSS score of CVE-2026-40480?

CVE-2026-40480 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

HIGH

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-04-18 security-advisories@github.com

PHP Authentication Bypass

7.1

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Re-analysis Queued

Apr 20, 2026 - 17:52 vuln.today

cvss_changed

Analysis Generated

Apr 18, 2026 - 00:38 vuln.today

Analysis Generated

Apr 18, 2026 - 00:22 vuln.today

CVE Published

Apr 18, 2026 - 00:16 nvd

HIGH 7.1

DescriptionGitHub Advisory

ChurchCRM is 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. 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 issue has been fixed in version 7.2.0.

AnalysisAI

Broken object-level authorization in ChurchCRM 7.1.x and earlier allows authenticated users with minimal EditSelf privileges to enumerate and exfiltrate sensitive personal data (names, addresses, phone numbers, emails) of all church members via the unauthenticated GET /api/person/{personId} API endpoint. While legacy UI enforces canEditPerson() checks, the API layer completely omits these authorization controls, enabling horizontal privilege escalation. Fixed in version 7.2.0. CVSS 7.1 (AV:N/AC:L/PR:L) indicates network-accessible exploitation by any low-privileged authenticated user with no technical complexity. EPSS data unavailable; no KEV listing or public POC identified at time of analysis, though the fix commit and GitHub advisory provide full technical details for replication.

Technical ContextAI

ChurchCRM is a PHP-based church management platform providing member directories, family records, and pastoral tools. The vulnerability stems from CWE-639 (Authorization Bypass Through User-Controlled Key), where the /api/person/{personId} REST endpoint accepts user-supplied personId parameters without verifying the requester's authorization to access that specific person record. The legacy PersonView.php controller implements canEditPerson() authorization checks that restrict data access based on user roles and permissions, but the API layer (likely introduced for modern SPA or mobile client support) fails to invoke these same authorization functions. This creates an Insecure Direct Object Reference (IDOR) attack surface where authenticated users can iterate through sequential or guessable personId values to harvest the entire member database. The CVSS 4.0 vector (VC:H/VI:N/VA:N) confirms high confidentiality impact with no integrity or availability effects, consistent with unauthorized read-only data exfiltration. GitHub references show the authorization check was added in commit 28ea7a2965fc2fe30e150fadb1ae38a97f8225c2 and tracked via issue #8617 and PR #8616.

Affected ProductsAI

ChurchCRM versions prior to 7.2.0 are confirmed vulnerable per the GitHub security advisory GHSA-5w59-32c8-933v. The vulnerability exists in the PHP-based API layer introduced in modern versions (exact version range not specified, but affects all 7.x releases before 7.2.0). Both self-hosted deployments and any cloud-hosted instances running outdated versions are impacted. The vendor advisory at https://github.com/ChurchCRM/CRM/security/advisories/GHSA-5w59-32c8-933v provides authoritative affected version details. No CPE strings were provided in the input data, preventing precise automated asset identification via vulnerability scanners.

RemediationAI

Upgrade to ChurchCRM version 7.2.0 immediately, which implements object-level authorization checks on the GET /api/person/{personId} endpoint per commit 28ea7a2965fc2fe30e150fadb1ae38a97f8225c2. The fix enforces canEditPerson() authorization logic consistently across both the legacy UI and API layers. Download from the official GitHub repository at https://github.com/ChurchCRM/CRM/releases and follow the project's upgrade procedures, ensuring database migrations complete successfully. For organizations unable to upgrade immediately, implement the following compensating controls with noted trade-offs: (1) Restrict /api/person/* routes to administrator roles only via web server configuration (Apache mod_rewrite or nginx location blocks) - this breaks legitimate API usage by non-admin users including mobile apps or integrations. (2) Deploy a web application firewall (WAF) rule blocking sequential personId enumeration patterns (e.g., more than 10 different personId requests per user per hour) - may generate false positives during legitimate bulk operations. (3) Enable comprehensive API access logging and monitor for abnormal GET /api/person/ request volumes from single user accounts - detective control only, does not prevent initial exploitation. Review access logs since initial deployment for evidence of unauthorized enumeration (users accessing personId values outside their authorized scope). Consult the fix pull request at https://github.com/ChurchCRM/CRM/pull/8616 for implementation details if backporting the authorization check to custom forks.