CVE-2025-9406 is a medium severity (6.3) unrestricted file upload flaw in xuhuisheng Lemon (mossle), affecting versions up to 1.13.0. No fixed version is confirmed. Until a fix is confirmed, restrict who can reach the application, review the affected code path, and scan your dependencies.
What's affected
- Product: xuhuisheng Lemon (mossle)
- Affected versions: up to 1.13.0
- Component:
com.mossle.cms.web.CmsArticleController (function uploadImage) - Parameter: the
Uploadparameter - Severity: Medium, CVSS 6.3 (
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) - Weakness classes: CWE-284, CWE-434
- Fixed version: No fixed version is confirmed, so the vendor advisory or release page should be checked
The NVD description says the handling of the Upload parameter lets a user supply a file the application should not accept. It also says the attack can be started remotely and that an exploit has been made public. The record does not list a fixed version, and the reference pages we could reach did not either.
This is a Java application. Fixes, if any, arrive as a new release or a local code change.
The public report we read describes the same product, file and parameter as the record, so we found no conflict in affected versions or severity between the two. Severity above is the score in the record. The advisory text itself gives no separate score.
How to check if you're exposed
Find out whether the project is in your build. In a Maven or Gradle repository, search the build files for the group or product name:
find . -name pom.xml -o -name build.gradle | xargs grep -n "mossle"
If you run a packaged build from someone else, ask them which release it is and compare it with the affected range (up to 1.13.0). Then check the project page for a newer release and its notes.
Also look at who can reach the application. Anything open to the internet deserves attention first.
What to do now
- Find it. Work out whether xuhuisheng Lemon (mossle) is installed anywhere in your estate, including test servers and old demos.
- Limit exposure. Put the application behind a VPN or an IP allowlist, or take it offline if nobody needs it.
- Look for a fix. Check the vendor's site or repository for a newer release. If none exists, ask the vendor directly and record the answer.
- Close the gap in code if you own it. Accept only the file types you need, check content as well as the name, store uploads outside the web root, and never serve them as executable code.
- Watch the logs. Keep web server logs for the affected path and review them for odd input.
- Scan. Run your dependency manifest through the free in-browser dependency scan to see what else is exposed.
Why it matters
Unrestricted upload (CWE-434) means the application accepts a file without checking enough about what it is or where it goes. The danger depends on what happens next. If the file lands somewhere the server will run it, an attacker can gain control of the server. If it is only stored, the impact is smaller. The advisory does not go further than the weakness itself, and neither do we.
The related access control weakness (CWE-284) in the record is a reminder that upload handlers deserve the same checks as any other privileged action: who is calling, what they send, and where it ends up.
The record shows the CISA Known Exploited Vulnerabilities flag as false, and nothing we read reports use in real attacks. The NVD description does say a proof of concept is public, which lowers the effort for anyone who wants to try it. Treat it as exposed if the product is reachable.
Notes for developers
If you maintain code like this, decide what you accept before you write the handler. Check the extension against an allowlist, check the content type by reading the file, rename the file on save, and keep the storage folder outside the path the web server executes.
Then test what happens when a user uploads something you did not expect. The handler for the Upload parameter should fail closed.
Quick check
Is a patch available?
The record and the report we read name no fixed release, so check the vendor's site for a newer version before assuming you are covered. Check the vendor page again before you act, because this can change.
Does this CVE mean attackers are using it now?
Not according to the sources we read. The CISA KEV flag in the record is false. The NVD description does say an exploit is public, so exposure is still worth treating seriously.
Sources
- NVD record and Safeguard Gold entry for CVE-2025-9406
- Public vulnerability report for this CVE
- Other references in the record, including VulDB, could not be retrieved when we checked.
Last reviewed: 18 October 2026.