CVE-2025-8775 is a medium severity unrestricted file upload in the Qiyuesuo Electronic Signature Platform up to version 4.34. The execute function behind /api/code/upload, in the scheduled task handler, accepts a file it should not. The vendor did not respond to the reporter, so no fix is confirmed.
What's affected
- Product: Qiyuesuo Electronic Signature Platform, versions up to and including 4.34.
- Component: the
executefunction of/api/code/upload, in the scheduled task handler component, through theFileargument. - Weaknesses: CWE-284 (improper access control) and CWE-434 (unrestricted upload of a dangerous file type).
- Score: CVSS 3.1 base 6.3, Medium, vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L. It is network reachable and needs a low privileged account. - Fixed version: none. The record says the vendor was contacted early and did not respond.
The record's description calls the issue "critical", while its score of 6.3 is Medium. The first is the reporter's word and the second the calculated rating, and this post follows the score. The record says the exploit has been disclosed publicly. It is not flagged as exploited in the wild and is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
If your organization runs this e-signature platform on its own servers, find the version in the admin console or in the install files. Anything up to 4.34 is in scope.
Next, find out whether the upload route is reachable from outside the networks that should use it. A signature platform is often open to external signers, so check which paths are published through your reverse proxy or firewall.
grep -rn "code/upload" /etc/nginx /etc/httpd 2>/dev/null
If your proxy forwards everything under the API prefix, the upload path is probably public. Review the platform's upload folders for files that are not documents or images, and check the access log for POST requests to the route from unfamiliar addresses.
What to do now
- Record every instance and its version, and ask the vendor in writing whether a fixed release exists.
- Block
/api/code/uploadat the reverse proxy or web application firewall if your business does not need it from outside. - Restrict the upload folders so nothing in them can be executed, and store them away from the web root if the product allows.
- Review accounts with low privileges, since the flaw needs one. Remove unused accounts and enforce strong credentials.
- Check upload folders and scheduled tasks for unexpected files and entries.
- Keep a note to recheck the vendor's release notes, because a fix may appear without a public advisory.
Why it matters
Signing platforms hold contracts and the identities attached to them, which makes the server worth more than its size suggests. An upload that accepts any file type, reached through a background task handler, is the kind of path that gets overlooked in a review because it is not part of the main user flow.
The weakness class is unrestricted upload. The control that fixes it is boring: accept only expected types, check content, store files where they cannot run, and require the right role. With a silent vendor, controls at your network edge are the part you can do today.
You can run the free in-browser dependency scan at gold.safeguard.sh/scan on your manifests to see which known-vulnerable packages you carry. It reads dependencies, so it will not see a flaw that lives only in an application's own source.
Quick check
Does a firewall rule fix it?
It reduces exposure by limiting who can reach the route, but the flaw remains in the product. Use the rule as a stopgap until a vendor fix is confirmed.
Is a patch available?
None is confirmed. The record says the vendor did not respond to the reporter.
Sources
- Safeguard Gold entry: CVE-2025-8775 (NVD record data: description, CVSS, CWEs, published 2025-08-09)
- Researcher write-up listed in the record: QYS_task.md
Last reviewed: 18 October 2026.
