CVE-2024-25897 in ChurchCRM
Summary
by MITRE • 02/21/2024
ChurchCRM 5.5.0 FRCatalog.php is vulnerable to Blind SQL Injection (Time-based) via the CurrentFundraiser GET parameter.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 06/09/2025
ChurchCRM version 5.5.0 contains a critical blind time-based sql injection vulnerability in the FRCatalog.php script that directly impacts the CurrentFundraiser GET parameter. This vulnerability allows remote attackers to execute arbitrary sql commands against the database through carefully crafted input manipulation. The flaw exists due to insufficient input validation and sanitization of user-supplied parameters before incorporating them into sql query constructions. Attackers can exploit this by injecting malicious sql payloads through the CurrentFundraiser parameter, causing the database to execute time-based queries that reveal information about the underlying database structure and contents. The time-based nature of this injection means that attackers must rely on response timing to infer database information, making detection more challenging. This vulnerability falls under the CWE-89 category for sql injection and aligns with ATT&CK technique T1190 for exploit public-facing application. The impact extends beyond simple data exfiltration as it can lead to complete database compromise, allowing attackers to escalate privileges and potentially gain access to sensitive donor information, financial records, and system credentials. The vulnerability is particularly concerning for church organizations that store extensive personal and financial data in ChurchCRM systems. The lack of proper parameterized queries or input filtering in the FRCatalog.php script creates an exploitable entry point that can be leveraged for data manipulation, unauthorized access, and system compromise.
The exploitation of this vulnerability requires minimal prerequisites and can be executed through standard web application attack vectors. Attackers can craft malicious urls with time-based sql payloads in the CurrentFundraiser parameter, causing the application to delay responses based on database query execution times. This timing-based approach enables attackers to extract database schema information, user credentials, and other sensitive data without direct error messages. The vulnerability affects the application's fund raiser catalog functionality where the CurrentFundraiser parameter is used to filter and display fundraising data. The absence of proper input validation means that sql keywords and functions can be injected directly into the query execution path, bypassing standard security controls. This flaw represents a significant risk to organizations relying on ChurchCRM for their administrative and financial operations, as it can result in unauthorized data access, data corruption, and potential system takeover. Organizations using this version should immediately implement mitigations while planning for a system upgrade to address the vulnerability.
Organizations should implement multiple layers of defense to protect against this sql injection vulnerability. Input validation and sanitization should be strengthened across all user-supplied parameters, particularly those used in database queries. The implementation of parameterized queries or prepared statements would effectively prevent sql injection by separating sql code from data. Web application firewalls should be configured to detect and block suspicious parameter patterns targeting sql injection attacks. Regular security assessments and penetration testing should be conducted to identify similar vulnerabilities in other components of the ChurchCRM system. The vulnerability demonstrates the critical importance of keeping web applications updated with the latest security patches, as this issue has been resolved in newer versions of ChurchCRM. Network segmentation and access controls should be implemented to limit exposure of vulnerable applications to untrusted networks. Security monitoring should be enhanced to detect unusual database query patterns and timing anomalies that may indicate exploitation attempts. Additionally, regular security training for administrators and developers should emphasize secure coding practices and input validation techniques to prevent similar vulnerabilities from being introduced in future development cycles. The remediation process should include thorough code review and testing to ensure that all sql query execution points are properly secured against injection attacks.