CVE-2025-0480

Executive Summary

CVE-2025-0480 is a Server-Side Request Forgery (SSRF) vulnerability identified in Wuzhicms version 4.1.0. The flaw resides in the test function within the file coreframe/app/search/admin/config.php. By manipulating the sphinxhost or sphinxport arguments, an attacker can force the server to make arbitrary HTTP requests to internal or external resources. This can lead to information disclosure, internal network scanning, or further exploitation of internal services. The vulnerability is remotely exploitable, has a public proof-of-concept (PoC), and currently has no official patch available.

CVSS Breakdown & Threat Level

• CVSS Score: 0.0 (Base Score not provided by NVD; estimated based on vector)
• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: Low (C:L)
• Integrity Impact: None (I:N)
• Availability Impact: None (A:N)
• Threat Level: Medium (due to SSRF potential for internal reconnaissance and data exfiltration)

Deep Dive & Mechanics

The vulnerability is triggered by the test function in coreframe/app/search/admin/config.php. This function is designed to test connectivity to a Sphinx search server by accepting sphinxhost and sphinxport parameters. However, the input is not properly sanitized or validated, allowing an attacker to supply arbitrary hostnames or IP addresses. The server then attempts to connect to the specified host and port, effectively acting as a proxy for the attacker.

Attack Flow:

1. The attacker sends a crafted HTTP request to the vulnerable endpoint with malicious sphinxhost and sphinxport values.
2. The server executes the test function, which uses the attacker-supplied values to initiate a connection.
3. The server sends a request to the attacker-specified target (e.g., internal IP, cloud metadata endpoint).
4. The response (or lack thereof) is reflected back to the attacker, revealing information about the target.

Potential Impact:

• Internal network reconnaissance (e.g., scanning for open ports on internal hosts).
• Access to cloud metadata services (e.g., AWS http://169.254.169.254/latest/meta-data/).
• Exploitation of internal services (e.g., Redis, Memcached, or databases).
• Data exfiltration via outbound connections.

Vulnerable vs. Patched Code

Vulnerable Code (wuzhicms 4.1.0):

// coreframe/app/search/admin/config.php
public function test() {
    $host = $_GET['sphinxhost'];
    $port = $_GET['sphinxport'];
    $fp = fsockopen($host, $port, $errno, $errstr, 5);
    if (!$fp) {
        echo "Connection failed: $errstr ($errno)";
    } else {
        echo "Connection successful";
        fclose($fp);
    }
}

Patched Code (Hypothetical):

// coreframe/app/search/admin/config.php
public function test() {
    $host = $_GET['sphinxhost'];
    $port = $_GET['sphinxport'];
    // Validate host is a valid IP or domain
    if (!filter_var($host, FILTER_VALIDATE_IP) && !filter_var($host, FILTER_VALIDATE_DOMAIN)) {
        echo "Invalid host";
        return;
    }
    // Validate port is numeric and within range
    if (!is_numeric($port) || $port < 1 || $port > 65535) {
        echo "Invalid port";
        return;
    }
    // Restrict to allowed hosts (e.g., only localhost for Sphinx)
    $allowed_hosts = ['127.0.0.1', 'localhost'];
    if (!in_array($host, $allowed_hosts)) {
        echo "Host not allowed";
        return;
    }
    $fp = fsockopen($host, $port, $errno, $errstr, 5);
    if (!$fp) {
        echo "Connection failed: $errstr ($errno)";
    } else {
        echo "Connection successful";
        fclose($fp);
    }
}

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Target running Wuzhicms 4.1.0 with the vulnerable endpoint accessible.
• Attacker machine with network access to the target.

Exploit Steps:

1. Identify the vulnerable endpoint: http://target.com/coreframe/app/search/admin/config.php?m=search&f=test
2. Craft a request to probe internal services:

   GET /coreframe/app/search/admin/config.php?m=search&f=test&sphinxhost=127.0.0.1&sphinxport=80 HTTP/1.1
   Host: target.com
   

3. If the internal service responds, the server will return "Connection successful". Otherwise, "Connection failed".
4. Use this to scan internal IP ranges (e.g., sphinxhost=192.168.1.1&sphinxport=22).
5. Attempt to access cloud metadata endpoints:

   GET /coreframe/app/search/admin/config.php?m=search&f=test&sphinxhost=169.254.169.254&sphinxport=80 HTTP/1.1
   Host: target.com
   

Lab Setup:

• Use Docker to deploy a vulnerable Wuzhicms instance.
• Set up a listener (e.g., nc -lvnp 4444) to capture outbound connections.
• Execute the exploit and observe the connection attempts.

Blue Team (Defense & Detection)

Detection:

• Monitor for unusual outbound connections from the web server to internal IPs or cloud metadata endpoints.
• Look for HTTP requests to /coreframe/app/search/admin/config.php with parameters sphinxhost or sphinxport containing non-standard values (e.g., IP addresses other than localhost).

Mitigation:

• Apply input validation and whitelisting for sphinxhost and sphinxport parameters.
• Restrict outbound network access from the web server using firewall rules.
• Disable the test function if not required.
• Implement Web Application Firewall (WAF) rules to block SSRF patterns.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound connections from the web server to internal IP addresses (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x).
  • Connections to cloud metadata endpoints (e.g., 169.254.169.254, 100.100.100.200).
  • HTTP requests containing sphinxhost and sphinxport parameters with suspicious values.
• File IOCs:
  • Log entries in web server logs showing requests to /coreframe/app/search/admin/config.php with sphinxhost and sphinxport parameters.
• Behavioral IOCs:
  • Unusual port scanning activity originating from the web server.
  • Unexpected data exfiltration attempts to external IPs.

Detection Engineering

YARA Rule

rule CVE_2025_0480_SSRF_Wuzhicms {
    meta:
        description = "Detects SSRF exploitation attempts against Wuzhicms CVE-2025-0480"
        author = "Valters IT"
        date = "2025-01-01"
        reference = "CVE-2025-0480"
    strings:
        $s1 = "sphinxhost" ascii nocase
        $s2 = "sphinxport" ascii nocase
        $s3 = "config.php" ascii nocase
        $s4 = "coreframe/app/search/admin/" ascii nocase
    condition:
        all of ($s1, $s2, $s3, $s4)
}

Sigma Rule

title: CVE-2025-0480 SSRF Exploitation Attempt
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects HTTP requests targeting the vulnerable Wuzhicms endpoint with SSRF parameters
author: Valters IT
date: 2025-01-01
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'GET'
        cs-uri-query|contains:
            - 'sphinxhost='
            - 'sphinxport='
        cs-uri-stem|contains: '/coreframe/app/search/admin/config.php'
    condition: selection
falsepositives:
    - Legitimate Sphinx server testing
level: high

Suricata Rule

alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"CVE-2025-0480 Wuzhicms SSRF Exploitation Attempt";
    flow:to_server,established;
    content:"GET";
    http_method;
    content:"/coreframe/app/search/admin/config.php";
    http_uri;
    content:"sphinxhost=";
    http_uri;
    content:"sphinxport=";
    http_uri;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

1. Immediate Actions:

   • Disable the test function in coreframe/app/search/admin/config.php by removing or commenting out the code.
   • Apply input validation to restrict sphinxhost to only localhost or a whitelist of allowed hosts.
   • Restrict outbound network access from the web server using firewall rules.

2. Long-term Fix:

   • Wait for an official patch from Wuzhicms or apply the hypothetical patched code provided above.
   • Implement a Web Application Firewall (WAF) with rules to block SSRF patterns.
   • Conduct a security audit of the entire application for similar vulnerabilities.

3. Monitoring:

   • Enable logging for all requests to the vulnerable endpoint.
   • Set up alerts for unusual outbound connections from the web server.

Valters IT