CVE-2025-8526 is a medium severity unrestricted file upload in Exrick xboot up to version 3.3.4. The upload function of UploadController.java does not restrict what file it accepts. The record scores it CVSS 6.3 and names no fixed version, so check the project's issue and releases before you rely on an upgrade.
What's affected
- Product: Exrick xboot, versions up to and including 3.3.4.
- Component: the
Uploadfunction inxboot-fast/src/main/java/cn/exrick/xboot/modules/base/controller/common/UploadController.java, 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 is listed in the record. The public issue (number 71 in the project's repository) was the only reference page I could read, and it describes the problem but did not give a fixed release.
The record calls the issue "critical" in its description, while the CVSS score of 6.3 is Medium. The first is the reporter's label and the second the calculated score, and this post follows the score. The record says the exploit has been disclosed to the public. 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
xboot is a Java application template that teams fork and build on, so your copy may differ from the upstream project. Check the version in your build file and whether you kept the upload controller.
grep -n "<version>" pom.xml | head
grep -rn "UploadController" src
If you deploy xboot, find out where uploaded files are stored and how they are served back. The issue on GitHub notes that the code renames the uploaded file to a random name but keeps the original extension, which is worth checking in your own copy. Look at the upload directory and see whether anything other than the file types you expect is there.
Also check who can call the upload route. The record's vector requires an authenticated account, so a deployment with open sign up is more exposed than one with a closed user list.
What to do now
- Find every deployment built from xboot and note the version in each.
- Add server side checks to the upload function: an allowlist of file types, a size limit, and a check of the real file content.
- Do not keep the client supplied extension. Choose the extension from the type you validated.
- Store uploads on a separate storage service or a directory the application server cannot execute from, and serve them with a fixed safe content type.
- Limit the route to the roles that need it.
- Watch the project's issue and release notes for a fix and update when one lands.
Why it matters
An upload endpoint accepts bytes from someone you do not control. If it trusts the file name and type that came with the request, a person can submit content that is not what it claims to be. Whether that matters depends on what the application does with the file. In a Java service the biggest risk is usually stored content that other users later open, or a file served back with a type that a browser will treat as active content.
For a library of this kind the practical lesson is that template projects pass their flaws on to everyone who forks them. Knowing which of your services descend from one is half the work, and it is the kind of question a dependency inventory answers.
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.
Try it yourself
Click through it at your own pace, or open it full screen.
This demo shows how a dependency inventory tells you quickly which of your projects include an affected component.
Quick check
Does upgrading past 3.3.4 fix it?
The record does not name a fixed version, so that is not confirmed. Read the project releases and the issue thread, and add your own server side validation either way.
Do I need an account to use the flaw?
According to the CVSS vector, yes, a low privileged account is required. That lowers exposure but does not remove it where sign up is open.
Sources
- Safeguard Gold entry: CVE-2025-8526 (NVD record data: description, CVSS, CWEs, published 2025-08-04)
- Reference listed in the record: https://github.com/Exrick/xboot/issues/71
Last reviewed: 18 October 2026.
