CVE-2026-40480
Received Received - Intake
Insecure Direct Object Reference in ChurchCRM API Exposes PII

Publication date: 2026-04-18

Last updated on: 2026-04-20

Assigner: GitHub, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-18
Last Modified
2026-04-20
Generated
2026-05-07
AI Q&A
2026-04-18
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
churchcrm churchcrm 7.2.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-862 The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
CWE-639 The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in ChurchCRM versions prior to 7.2.0. The GET /api/person/{personId} endpoint returns person records without performing proper object-level authorization checks. While the legacy PersonView.php page enforces restrictions on who can edit person records, the API does not enforce these checks. As a result, any authenticated user with only EditSelf privileges can access and read other members' records.

This leads to exposure of sensitive personally identifiable information (PII) such as names, addresses, phone numbers, and email addresses.


How can this vulnerability impact me? :

The vulnerability allows unauthorized users to access sensitive personal information of other members. This can lead to privacy breaches, identity theft, or misuse of personal data.

Since the exposed data includes names, addresses, phone numbers, and email addresses, attackers could use this information for phishing, social engineering, or other malicious activities.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, you should upgrade ChurchCRM to version 7.2.0 or later, where the issue has been fixed.

Until the upgrade is applied, restrict access to the API endpoint /api/person/{personId} to trusted users only, and review user privileges to ensure that only authorized users have EditSelf privileges.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows authenticated users with limited privileges to access sensitive personally identifiable information (PII) of other members without proper authorization checks. Such unauthorized exposure of PII, including names, addresses, phone numbers, and email addresses, can lead to non-compliance with data protection regulations like GDPR and HIPAA, which mandate strict controls on access to personal data.

By failing to enforce object-level authorization at the API layer, the system risks violating principles of data minimization and access control required by these standards, potentially resulting in legal and regulatory consequences.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves unauthorized access to person records via the GET /api/person/{personId} endpoint in ChurchCRM versions prior to 7.2.0. Detection can focus on monitoring API requests to this endpoint to identify unusual or unauthorized enumeration of person IDs.

You can detect potential exploitation by analyzing web server logs or network traffic for repeated GET requests to /api/person/ with different personId values from authenticated users who should not have access.

Example commands to detect such activity might include:

  • Using grep on web server logs to find GET requests to the vulnerable endpoint: grep 'GET /api/person/' /var/log/apache2/access.log
  • Using awk or similar tools to count distinct personId requests per user IP or session to identify enumeration patterns.
  • Using network monitoring tools like Wireshark or tcpdump to filter HTTP GET requests to /api/person/ endpoints.
  • Checking application logs for authenticated users making multiple requests to different personId values.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart