CVE-2025-7627 is a medium severity (CVSS 6.3) unrestricted file upload in YiJiuSmile kkFileViewOfficeEdit, up to commit 5fbc57c. The fileUpload function behind /fileUpload mishandles the File argument, and the attack can be launched remotely. The project uses rolling releases, so no fixed version is published. Restrict access and watch the repository.
The description says the exploit has been disclosed to the public and may be used. The record does not mark this CVE as exploited in the wild, and it is not a CISA Known Exploited Vulnerability.
What's affected
The record names YiJiuSmile kkFileViewOfficeEdit up to and including commit 5fbc57c48e8fe6c1b91e0e7995e2d59615f37abd. The weakness is in the fileUpload function of the /fileUpload endpoint, through the File argument.
The record states that the product uses a rolling release for continuous delivery, so no version numbers for affected or updated releases are available. That means there is no fixed version to name. If you run a build from this project, compare your commit with the one above and check the project's issue tracker for a change that addresses the report.
Severity needs a note. The description calls the issue critical, which is VulDB's wording. The score in the record is CVSS 6.3, which is Medium. This post uses the score. The public report is titled as a file upload vulnerability and says that the upload path can be manipulated to place a file outside the intended folder. It also says this could lead to code execution on the host. That is the reporter's claim, and I have not verified it. I am not repeating the request details here.
How to check if you're exposed
Find out which commit you run. If you built from a clone of the repository:
git log -1 --format=%H
git merge-base --is-ancestor 5fbc57c48e8fe6c1b91e0e7995e2d59615f37abd HEAD && echo "at or after the listed commit"
If your build includes that commit or came before it, treat it as affected until the project says otherwise. If you only have a packaged copy, look for the file upload controller in the source and read how the destination path is built from the request.
Next check whether the endpoint is reachable from outside. A document preview service often sits behind an internal application, and it should not answer on a public address. Look at your reverse proxy or firewall rules for the service port.
Finally look at the folders that hold templates and uploaded documents for files that do not belong. Compare them with a known good copy of the deployment.
Safeguard's free in-browser dependency scan covers third party packages. It will not flag this issue, which sits in the application's own code, so use code review or a SAST tool for that part.
What to do now
- List where you run kkFileViewOfficeEdit and which commit each copy was built from.
- Take the service off the public internet. Put it behind your application, a VPN or an allow list.
- Block requests to /fileUpload at the proxy for anyone who does not need the feature.
- Read the upload code. The stored file name and the destination folder should be chosen by the server, never copied from the request, and path separators should be rejected.
- Compare template and web folders against a clean copy and restore anything that was changed.
- Watch the project repository for a fix, and rebuild from it once one is merged. Check the issue thread before you rely on it.
Try it yourself
This walkthrough shows how a scan finds a flaw of this class and what the finding looks like.
Click through it at your own pace, or open it full screen.
Why it matters
CWE-434 is unrestricted upload of a dangerous file type, and CWE-284 is improper access control. A document viewer has to accept files from users, which makes the upload path the main attack surface. If the server lets the client influence where a file lands or what it is called, an upload can replace files that the application later trusts, such as templates.
Rolling releases make this harder for defenders. With no version number, there is nothing to match against a scanner feed, and you have to track commits yourself. Pin the commit you deploy and record it, so the next advisory is a lookup and not an investigation.
Quick check
Is there a fixed version of kkFileViewOfficeEdit?
No version number applies, because the project uses rolling releases. Check the project issue and commit history for a change that addresses the report, and pin the commit you deploy.
Why is the score Medium when the description says critical?
The word critical comes from VulDB, which files these reports. The CVSS 3.1 score in the record is 6.3, which falls in the Medium band. Both are in the record, and you should judge by how exposed your own deployment is.
Sources
Last reviewed: 18 October 2026.
