CVE-2025-1890 is a medium severity (6.3) unrestricted file upload flaw in shishuocms 1.1. The upload handler accepts a file without enough checks. The record names no fixed version, so restrict who can upload, validate what is stored, and check the project for a newer release.
What's affected
The record lists shishuocms version 1.1. The vulnerable code is the handleRequest function in src/main/java/com/shishuo/cms/action/manage/ManageUpLoadAction.java, and the argument involved is file. The weaknesses are CWE-434, unrestricted upload of a file with a dangerous type, and CWE-284, improper access control. The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, so a low privilege account is needed and the impact is rated low.
The description says the exploit has been disclosed to the public and may be used. The record is not on the CISA Known Exploited Vulnerabilities list, and I found no source that says it is exploited in the wild.
Fixed versions: none are named in the record. I could not confirm a patch. Check the project's repository and release notes before you assume a newer build exists.
How to check if you're exposed
First find installs of shishuocms and confirm the version. Then find the upload class in your deployed source or decompile it from the jar.
find / -name "ManageUpLoadAction*" 2>/dev/null
Open the class and read how handleRequest names, types and stores the file. Look for three things: whether it checks the file type against an allowlist, whether it stores the file inside a web-served folder, and whether it requires a logged in manager before it runs.
Then look at the upload folder itself. Unexpected file types, especially script or executable files, are a reason to investigate. Check access logs for requests to the manage upload path from addresses outside your staff.
What to do now
- Find every shishuocms deployment and note the version.
- Restrict the manage area to a VPN or an IP allowlist if public access is not required.
- Add a server side allowlist of file types, check the content as well as the name, and cap the size.
- Store uploads outside the web root, or in a folder where the server is set not to run scripts.
- Rename uploaded files on the server instead of keeping the user supplied name.
- Review the upload folder and access logs, and clean up anything unexpected.
- Check the project for a newer release and read its notes before upgrading.
Why it matters
File upload handlers combine two risks. The first is what the file is, because a script stored where the server will run it becomes code. The second is where it lands, because a file saved in a served folder can be requested by anyone. A safe handler controls both. It accepts only known types, stores files out of reach of the interpreter and serves them with a fixed content type.
The record also lists improper access control, which fits the vector. The score is medium because an account is needed, but small CMS projects often hand out manager accounts freely or leave default ones in place. Check which accounts can reach the upload feature before you decide this can wait.
Quick check
Why is the score only medium?
The vector requires a low privilege account and rates the impact low. That is not the same as harmless. Review who has accounts and whether any defaults remain.
What is the single best control for uploads?
Store uploaded files where the server cannot execute them, and accept only an allowlist of types. Together these remove the main route from a hostile upload to running code.
Sources
- CVE-2025-1890 on Safeguard Gold
- Public report listed in the CVE record (GitHub write-up). I could not retrieve it while writing.
Last reviewed: 19 October 2026.
