CVE-2025-6925 is a medium (CVSS 5.3) path traversal flaw in Dromara RuoYi-Vue-Plus 5.4.0. The mail handler in a demo controller accepts a file path argument. The record names no fixed version, so remove or protect the demo mail endpoints and check the project for a newer release.
What's affected
Dromara RuoYi-Vue-Plus 5.4.0, per the record. The file named in the record is src/main/java/org/dromara/demo/controller/MailController.java, and the argument is filePath. The package name includes demo, so the code appears to be part of the project's demo module. Check whether your build includes it.
The researcher report linked in the record describes the weakness as an arbitrary file read. It says the mail sending endpoints are unauthenticated and attach a caller supplied file path to an outgoing email, so any file the server process can read could be sent out. It also names CWE-306 (missing authentication) alongside path traversal. The record lists only CWE-22, so the record and the report differ in how many weaknesses they name. The report does not mention a fix.
The NVD description calls the issue critical, which is the reporting database label. The CVSS 3.1 score in the record is 5.3, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, which is Medium. The vector rates only confidentiality impact, as low, which matches a file read issue. The record does not flag exploitation in the wild (KEV is false).
How to check if you're exposed
Confirm your version in your build file. For a Maven project:
grep -n "<version>" pom.xml | head
Check whether the demo controller is in your source or deployed artifact:
find . -name "MailController.java" -path "*demo*"
unzip -l target/*.jar | grep -i "demo/controller/MailController"
If it is present, look at which routes it exposes and whether your security configuration requires a login for them. Review mail server logs for outgoing messages with unexpected attachments.
What to do now
- Remove the demo module from production builds, or at least exclude the mail controller.
- If you need mail sending, require authentication and accept attachments only by an ID that the server maps to a known file, never by a path from the request.
- Run the application as a user that can read only what it needs. Keep secrets, key files and environment dumps out of its reach.
- Check outgoing mail logs for attachments that do not look like business files.
- Watch the RuoYi-Vue-Plus project for a patched release, and verify any fix against its advisory before upgrading.
Why it matters
Path traversal turns a file name or path from outside into access to files the developer never meant to expose. Here the path is attached to an email, so the reading is done by the server and the result is delivered by mail. An attacker does not need a shell to receive configuration files or credentials, only a working mail route.
Demo and example code is a common source of this kind of problem. It is written to show a feature, not to survive a hostile network, and it often ships to production because it was part of the starter project. Deleting what you do not use is the cheapest control.
The score is moderate because only confidentiality is affected. Files such as application configuration often hold database passwords, so a leak can lead to a larger incident. Fixing the exposure and rotating any secret that was readable are the sensible steps if you find the endpoint was reachable.
Quick check
Is there a fixed version of RuoYi-Vue-Plus?
The record names no fixed version and the report I read mentions no fix. Check the project releases and advisories.
Is the demo controller part of production by default?
I could not confirm that. The path includes demo, so check whether your build includes it and remove it if you do not need it.
Sources
- Safeguard Gold entry for CVE-2025-6925
- Researcher report referenced by the record
- VulDB entry 314437
Last reviewed: 18 October 2026.