CVE-2025-14004 is a medium severity server-side request forgery flaw (CVSS 4.7) in dayrui XunRuiCMS (up to 4.7.1), affecting the Email Setting Handler in the admin area (the email add action). No fix is listed and the vendor did not respond, so cut exposure and watch for a patch.
What's affected
The affected component is the Email Setting Handler in the admin area (the email add action). The record describes it as server-side request forgery, which means an attacker can make the server send requests on their behalf.
Affected version: up to 4.7.1. The record names no fixed version and says the vendor was contacted early but did not respond.
The CVSS vector is AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L. The attack vector is the network, but the vector lists high privileges required, which is why the score is lower: the attacker needs an administrative account first. The weakness classes are CWE-918.
The CVE record states that the exploit has been disclosed publicly. That is not the same as exploitation in the wild, which the record does not report, and the CISA Known Exploited Vulnerabilities flag is false. Still, public details lower the effort needed to attack an exposed instance.
How to check if you're exposed
Identify the instance and its version first, then look at what the server can reach from where it runs.
The record names XunRuiCMS up to 4.7.1. The version is shown in the admin area and in the installed files, so compare it with 4.7.1.
Server-side request forgery is mostly dangerous because of what sits next to the server. Check which internal addresses and cloud metadata endpoints the application host can reach, and whether egress is filtered.
grep -Ei "169\.254\.169\.254|localhost|127\.0\.0\.1|10\.|192\.168\." /var/log/nginx/access.log | head
That searches your access log for requests whose parameters contain internal addresses. Adapt the log path and the patterns to your environment. A result means a request carried an internal address, not that it succeeded.
What to do now
- Confirm which instances you run and which version they are on.
- No fixed version is named in the record. Check the vendor for a patch and ask them directly, since the record says the vendor did not respond.
- Restrict outbound traffic from the application host so it can only reach the destinations it needs. This is the strongest control against SSRF in general.
- Block access to the cloud instance metadata service from the application, or require the hardened token-based variant your provider offers.
- Review the logs of the affected feature for requests to internal addresses or unusual hosts.
- Restrict who can use the affected feature to trusted users where the product allows it.
Why it matters
Server-side request forgery (CWE-918) turns a feature that fetches a URL into a way to reach places the attacker cannot. The server sits inside your network and is trusted by other systems, so its requests can touch internal services, admin panels and metadata endpoints.
The fix is a combination of input validation and network controls. Allowlisting destinations in the code is best, and egress filtering catches what the code misses. Neither depends on the other, so use both where you can.
Try it yourself
The demo shows continuous monitoring catching a newly disclosed issue in software you already run.
Click through it at your own pace, or open it full screen.
Quick check
What makes SSRF hard to see in logs?
Blind SSRF gives the attacker no response body, so the signs are in your own outbound logs and DNS queries, not in the web response.
Where should I start fixing it?
The record names no fixed version and says the vendor was contacted early but did not respond. Whatever the vendor does, filtering outbound traffic from the host is worth doing.
Sources
- Gold vulnerability page for CVE-2025-14004
- CVE record for CVE-2025-14004 as published by its CNA, with a published date of 2025-12-04
- Free in-browser dependency scan: gold.safeguard.sh/scan
Last reviewed: 19 October 2026.
