CVE-2025-66313: ChurchCRM SQL Injection Vulnerability

CVE-2025-66313 Overview

CVE-2025-66313 is a time-based blind SQL injection vulnerability affecting ChurchCRM, an open-source church management system. The vulnerability exists in the handling of the 1FieldSec parameter, where user-supplied input is incorporated directly into SQL queries without proper parameterization. By injecting SLEEP() commands, attackers can cause deterministic server-side delays, confirming successful SQL injection. This vulnerability enables data exfiltration and modification via blind SQL injection techniques.

Critical Impact

Authenticated attackers with high privileges can exploit this SQL injection vulnerability to extract sensitive church member data, modify database records, and potentially compromise the entire database through blind injection techniques.

Affected Products

• ChurchCRM versions 6.2.0 and earlier
• All ChurchCRM installations using the vulnerable 1FieldSec parameter handling

Discovery Timeline

• 2025-12-01 - CVE-2025-66313 published to NVD
• 2025-12-03 - Last updated in NVD database

Technical Details for CVE-2025-66313

Vulnerability Analysis

This vulnerability is classified as CWE-89 (SQL Injection) with a CVSS 4.0 score of 5.1 (MEDIUM severity). The attack vector is network-based (AV:N) with low attack complexity (AC:L), though it requires high privileges (PR:H) to exploit.

The CVSS vector string is: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:L/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

The EPSS (Exploit Prediction Scoring System) data indicates a probability of 0.033% with a percentile ranking of 9.114, suggesting relatively low exploitation likelihood in the wild at this time.

Root Cause

The root cause of this vulnerability is improper input validation and the lack of parameterized queries in the code handling the 1FieldSec parameter. User-supplied input is directly concatenated into SQL query strings rather than being properly sanitized or bound as parameters. This classic SQL injection pattern allows attackers to manipulate the query structure by injecting malicious SQL statements.

Attack Vector

The attack is conducted over the network and requires an authenticated user with high-level privileges. The attacker manipulates the 1FieldSec parameter by injecting time-based SQL commands such as SLEEP() functions. When the server response is delayed by the specified duration, it confirms that the injected SQL is being executed, allowing the attacker to exfiltrate data one bit at a time through timing analysis.

The time-based blind SQL injection technique works by asking the database true/false questions and measuring response times. For example, an attacker can determine if a specific character in a password hash equals a certain value by observing whether the response is delayed. Through iterative queries, complete data extraction is possible without direct output visibility.

Detection Methods for CVE-2025-66313

Indicators of Compromise

• Unusual or slow database query response times that correlate with specific HTTP requests
• HTTP requests containing SQL injection patterns in the 1FieldSec parameter (e.g., SLEEP(), BENCHMARK(), WAITFOR DELAY)
• Sequential HTTP requests with timing-based payloads targeting the same endpoint
• Database logs showing execution of SLEEP() or similar time-delay functions
• Abnormal patterns in web access logs with encoded or obfuscated SQL syntax

Detection Strategies

Implement Web Application Firewall (WAF) rules to detect and block SQL injection patterns in request parameters. Monitor database query execution times and alert on anomalous delays that may indicate time-based injection attacks. Deploy application-level logging to capture all interactions with the 1FieldSec parameter and analyze for malicious patterns.

Network-based detection should focus on identifying requests with common SQL injection signatures including SLEEP, BENCHMARK, WAITFOR, and pg_sleep functions. Behavioral analysis can help identify automated attack tools that send sequential requests with incrementing timing values.

Monitoring Recommendations

Enable detailed logging for all ChurchCRM application endpoints, particularly those handling field security parameters. Implement database query logging to capture slow queries and identify potential blind SQL injection attempts. Consider deploying endpoint detection and response (EDR) solutions that can correlate network activity with database behavior to identify exploitation attempts in real-time.

How to Mitigate CVE-2025-66313

Immediate Actions Required

• Apply the security patch from commit 719a6bc73245c40e3c30dae6229daaecd451e59f immediately
• Review the vendor security advisory at GHSA-47q3-c874-mqvp for complete remediation guidance
• Implement input validation and WAF rules to block SQL injection attempts until patching is complete
• Audit database access logs for any historical exploitation attempts
• Consider temporarily restricting access to administrative functions if immediate patching is not possible

Patch Information

ChurchCRM has released a patch addressing this vulnerability. The fix is available in commit 719a6bc73245c40e3c30dae6229daaecd451e59f on the official ChurchCRM GitHub repository.

Patch Resources:

• Patch Commit: https://github.com/ChurchCRM/CRM/commit/719a6bc73245c40e3c30dae6229daaecd451e59f
• Security Advisory: https://github.com/ChurchCRM/CRM/security/advisories/GHSA-47q3-c874-mqvp

Organizations should upgrade to the latest version of ChurchCRM that includes this security fix. The patch implements proper parameterized queries for the 1FieldSec parameter, preventing SQL injection attacks.

Workarounds

If immediate patching is not possible, implement the following temporary mitigations:

1. Deploy a Web Application Firewall (WAF) with rules to detect and block SQL injection patterns in the 1FieldSec parameter
2. Restrict network access to ChurchCRM administrative interfaces to trusted IP addresses only
3. Implement additional authentication controls and monitor privileged user activity
4. Consider placing the ChurchCRM instance behind a reverse proxy that can filter malicious requests

# Example ModSecurity WAF rule to block SQL injection in 1FieldSec parameter
SecRule ARGS:1FieldSec "@detectSQLi" \
    "id:1001,\
    phase:2,\
    deny,\
    status:403,\
    msg:'SQL Injection attempt detected in 1FieldSec parameter',\
    log,\
    auditlog"