CVE-2025-13814 is a high severity server-side request forgery flaw (CVSS 7.3) in moxi159753 Mogu Blog v2 (up to 5.2), affecting LocalFileServiceImpl.uploadPictureByUrl, reached at /file/uploadPicsByUrl. 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 LocalFileServiceImpl.uploadPictureByUrl, reached at /file/uploadPicsByUrl. 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 5.2. 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:N/UI:N/S:U/C:L/I:L/A:L. The attack vector is the network, and the vector lists no privileges required, so an unauthenticated visitor who can reach the service is in scope. 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.
Mogu Blog v2 is a Java application, so check the deployed jar or container image for the version. The record names versions up to 5.2.
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.
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-13814
- CVE record for CVE-2025-13814 as published by its CNA, with a published date of 2025-12-01
- Free in-browser dependency scan: gold.safeguard.sh/scan
Last reviewed: 19 October 2026.
