CVE-2025-0480 Overview
CVE-2025-0480 is a Server-Side Request Forgery (SSRF) vulnerability in wuzhicms 4.1.0, an open-source content management system. The flaw resides in the test function of coreframe/app/search/admin/config.php, where the sphinxhost and sphinxport parameters are used without proper validation. An authenticated remote attacker can manipulate these arguments to force the server to issue requests to arbitrary internal or external hosts. The exploit details have been publicly disclosed, increasing exposure for unpatched deployments. This weakness is categorized under CWE-918: Server-Side Request Forgery.
Critical Impact
Attackers with low-privilege access can pivot from the wuzhicms admin interface to probe internal network services, bypass firewall restrictions, and access resources otherwise unreachable from outside the perimeter.
Affected Products
- wuzhicms 4.1.0
- Component: coreframe/app/search/admin/config.php
- Function: test (Sphinx search configuration handler)
Discovery Timeline
- 2025-01-15 - CVE-2025-0480 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-0480
Vulnerability Analysis
The vulnerability exists in the Sphinx search backend configuration test routine within wuzhicms. The test function in coreframe/app/search/admin/config.php accepts user-controlled sphinxhost and sphinxport values and uses them to open a network connection intended to validate Sphinx server reachability. Because the application does not restrict the destination to an allowlisted host or port range, attackers can substitute arbitrary targets. The server then acts as a proxy, connecting to attacker-chosen internal addresses such as 127.0.0.1, cloud metadata endpoints, or adjacent hosts in the same network segment.
Exploitation requires authenticated access to the administrative search configuration page, but the attack itself is delivered over the network with low complexity. Successful abuse can enable internal service discovery, port scanning through the CMS, and interaction with services that trust requests originating from the application server.
Root Cause
The root cause is missing input validation and destination restriction on host and port parameters supplied through the search configuration form. The application trusts operator-supplied values and passes them directly into the connection routine without allowlisting, hostname resolution checks, or blocking of loopback and private address ranges.
Attack Vector
The attack is initiated remotely against the wuzhicms admin panel. An authenticated user submits crafted sphinxhost and sphinxport values through the Sphinx configuration test endpoint. The server then attempts a TCP connection to the attacker-specified target, and the response behavior (timeouts, error messages, or connection success) can leak information about internal infrastructure. Refer to the wuzhicms GitHub issue #212 for the original disclosure and reproduction details.
Detection Methods for CVE-2025-0480
Indicators of Compromise
- Web server access logs showing POST or GET requests to coreframe/app/search/admin/config.php with unusual sphinxhost or sphinxport parameter values
- Outbound connections from the wuzhicms application server to internal RFC1918 addresses, 127.0.0.1, 169.254.169.254, or non-standard ports
- Repeated Sphinx configuration test requests with iterating host or port values, indicating scanning behavior
Detection Strategies
- Inspect web application firewall (WAF) logs for sphinxhost parameters resolving to loopback, link-local, or private IP ranges
- Correlate authenticated admin sessions with anomalous outbound connection attempts from the PHP worker process
- Alert on any connection from the wuzhicms host to cloud metadata service endpoints such as 169.254.169.254
Monitoring Recommendations
- Enable verbose access logging on the coreframe/app/search/admin/ path and forward events to a centralized log platform
- Monitor egress traffic from the CMS server and baseline expected destinations to surface deviations
- Track failed authentication and privilege changes on admin accounts that access search configuration pages
How to Mitigate CVE-2025-0480
Immediate Actions Required
- Restrict administrative panel access to trusted IP ranges using network ACLs or reverse proxy rules
- Audit accounts with permissions to modify search configuration and remove unnecessary privileges
- Block outbound connections from the wuzhicms server to internal address ranges and cloud metadata endpoints at the network layer
Patch Information
No official vendor patch is referenced in the advisory at the time of publication. Track the wuzhicms GitHub issue #212 and the VulDB entry #291915 for updates. Until a fix is released, apply the workarounds below and consider isolating the affected instance.
Workarounds
- Disable or restrict access to the Sphinx configuration test functionality if search integration is not in use
- Enforce egress filtering so the CMS host can only reach the legitimate Sphinx backend host and port
- Deploy a WAF rule that rejects requests to config.php containing sphinxhost values matching loopback, private, or link-local IP patterns
- Run the wuzhicms process under a network namespace or container with no access to sensitive internal services
# Example egress restriction: allow only the legitimate Sphinx backend
# Replace 10.0.0.25 and 9312 with your actual Sphinx server address and port
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.25 -p tcp --dport 9312 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner www-data -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner www-data -d 192.168.0.0/16 -j REJECT
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
