CVE-2026-39317
SQL Injection in ChurchCRM SettingsIndividual.php Allows Data Exposure
Publication date: 2026-04-07
Last updated on: 2026-04-09
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| churchcrm | churchcrm | to 7.1.0 (exc) |
| churchcrm | churchcrm | 7.1.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-39317 is a high-severity SQL injection vulnerability found in ChurchCRM versions 7.0.5 and earlier, specifically in the file SettingsIndividual.php.
The vulnerability occurs because user-controlled array keys from the POST parameter named 'type' are used directly in SQL queries without any sanitization or validation.
While the values of the POST parameters are sanitized, the array keys themselves are not, allowing an authenticated user to inject malicious SQL code through the array key.
This improper handling leads to the possibility of extracting sensitive data from the database or manipulating the database queries.
The issue is fixed in version 7.1.0 by sanitizing the array key before using it in SQL queries, casting it to an integer to prevent injection.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows an authenticated user to extract sensitive data from the database due to SQL injection in ChurchCRM. This unauthorized access to sensitive data can lead to violations of data protection regulations such as GDPR and HIPAA, which require strict controls over personal and sensitive information.
By enabling attackers to extract, modify, or disrupt data integrity and availability, the vulnerability undermines the confidentiality, integrity, and availability principles central to compliance with these standards.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade ChurchCRM to version 7.1.0 or later, where this vulnerability is fixed.
If upgrading is not immediately possible, apply the patch that sanitizes the array key from the POST parameter before using it in SQL queries.
Specifically, change the code from extracting the array key directly to sanitizing it as an integer, for example:
- $raw_id = key($type);
- $id = InputUtils::legacyFilterInput($raw_id, 'int');
This ensures only valid numeric IDs are used, preventing SQL injection via array key manipulation.
Additionally, restrict access to authenticated users and monitor logs for suspicious POST requests targeting SettingsIndividual.php.
How can this vulnerability impact me? :
This vulnerability allows any authenticated user to perform SQL injection attacks by manipulating array keys in POST requests.
An attacker can extract sensitive data from the database, such as user information or configuration data.
Additionally, the attacker can modify data integrity and impact the availability of the application.
The vulnerability requires only low privileges (authenticated user) and no user interaction, making it easier to exploit.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by testing for SQL injection in the array keys of the POST parameter named 'type' sent to the SettingsIndividual.php endpoint.
A practical detection method involves sending specially crafted POST requests with SQL injection payloads in the array key, such as: type[99999 OR EXISTS(SELECT 1 WHERE 1=1)]=text.
Differences in HTTP response codes (e.g., 302 for true conditions, 200 or 500 for false) can indicate the presence of the vulnerability.
Commands or tools that can be used include curl for manual testing, for example:
- curl -X POST -d "type[99999 OR EXISTS(SELECT 1 WHERE 1=1)]=text" https://yourchurchcrminstance/SettingsIndividual.php
- Observe the HTTP response codes and behavior differences to confirm vulnerability.
Automated SQL injection scanners that support testing array keys in POST parameters may also help detect this issue.