CVE-2025-4538 is a medium severity unrestricted file upload flaw (CVSS 6.3) in kkFileView 4.4.0. The /fileUpload endpoint accepts a file it should refuse. The record says the vendor did not respond, so no fix is listed. Restrict access to the upload endpoint and watch the project for a patch.
What's affected
Per the CVE record, kkFileView 4.4.0 is affected. The weak point is the /fileUpload function, where manipulation of the File argument leads to unrestricted upload. The attack can be launched remotely, and the record says the exploit has been disclosed to the public.
The record states that the vendor was contacted early about this disclosure but did not respond in any way. No fixed version is named, and the one reference is a public write up on a Notion page that I did not retrieve.
The CVSS vector needs a low privilege account and gives low impact on confidentiality, integrity and availability, which produces 6.3. The KEV flag is false, and the record does not report attacks in the wild.
Check the project's GitHub repository for releases newer than 4.4.0 before you decide on a course of action.
How to check if you're exposed
kkFileView is a file preview service, often run as a Java application or a container. Find where it runs. For a container host:
docker ps --format '{{.Names}} {{.Image}}' | grep -i kkfileview
Check the image tag or the JAR file name for the version, which should match 4.4.0 if you are affected. For a JAR deployment, look at the file name in the install directory.
Then check who can reach the service. A preview service is commonly placed behind another application, and the upload endpoint should not be open to the public internet. Review your reverse proxy rules for the path /fileUpload.
Finally, look at the upload directory on the host. Files with unexpected types, such as scripts or archives, are a sign that someone used the endpoint in a way you did not plan for.
What to do now
- Find every kkFileView instance and confirm the version.
- Check the project's releases for a build newer than 4.4.0 and read its notes for upload handling changes.
- Block external access to
/fileUploadat the proxy unless your application needs it, and require authentication where it does. - Make sure the upload directory is not served as executable content and that the service runs as an unprivileged user.
- Inspect the upload directory for files you do not recognise and remove them after you have kept copies for review.
- Run the service in a container with limited filesystem access.
- If the project stays silent, consider whether a different previewer is a better fit.
Why it matters
The record maps the issue to CWE-434 and CWE-284. Unrestricted upload means the service does not check what kind of file it is being given. Depending on where the file lands and how the server treats it, the result can range from clutter to code execution.
A vendor that does not answer a report is a risk of its own. The fix may not arrive, and you will need your own controls: network limits, a locked down upload folder and monitoring.
Open source components like this sit inside other products, so you may run one without knowing. A dependency scan and a software inventory are how you find it. Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan is a place to start, and the Gold directory lists related CVEs by product.
Quick check
Is CVE-2025-4538 being exploited in the wild?
The record does not report exploitation and its CISA KEV flag is false. That can change, so check the CISA catalog again before you decide how urgent this is.
Is there a patch for kkFileView 4.4.0?
The record names none and says the vendor did not respond. Check the project's releases, and use network limits and a locked down upload folder in the meantime.
Sources
- CVE-2025-4538 on Gold
- NVD record for CVE-2025-4538
- Reference listed in the CVE record: a public write up on Notion and VulDB entries. They were not retrieved when this post was written.
Last reviewed: 18 October 2026.
