CVE-2025-9412 is a medium severity (6.3) SQL injection flaw in lostvip ruoyi-go, affecting versions up to 2.1. No fixed version is confirmed and the vendor did not respond to the disclosure. Until a fix is confirmed, restrict who can reach the application, review the affected code path, and scan your dependencies.
What's affected
- Product: lostvip ruoyi-go
- Affected versions: up to 2.1
- Component:
modules/system/dao/DictDataDao.go (function SelectListByPage) - Parameter: the
orderByColumnandisAscparameters - 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-74, CWE-89
- Fixed version: No fixed version is confirmed and the vendor did not respond to the disclosure, so the vendor advisory or release page should be checked
The NVD description says input to the orderByColumn and isAsc parameters is used in a database query without proper handling. 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 Go project. Fixes, if any, arrive as a new tagged release or a local code change before you rebuild.
The public reference pages listed in the record could not be retrieved when we checked, so the details above come from the NVD record alone. If the project's own page says something different about versions or severity, trust that page and treat this as a starting point.
How to check if you're exposed
Find out whether your build includes the project. In the repository that builds your application, search the module file and the source tree:
grep -n "ruoyi" go.mod
find . -name "*.go" | xargs grep -ln "ruoyi-go" | head
If it appears, compare the version you build against the affected range (up to 2.1). Then check the project's releases page for anything newer.
Also look at who can reach the application. An admin area that is open to the internet deserves attention first.
What to do now
- Find it. Work out whether lostvip ruoyi-go 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. Change the affected query to use parameterised statements and validate the input type before it reaches the database.
- 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
SQL injection (CWE-89) happens when text from a request becomes part of a database query instead of staying data. The database cannot tell the difference, so a crafted value can change what the query does. The usual impact is unauthorised reads or changes to stored data, and the record scores confidentiality, integrity and availability impact as low each because the reach depends on the query.
The same pattern shows up again and again in small PHP and Go projects, often across many pages of one application. That is why a single product can carry a dozen near identical CVEs. Fixing one file does not fix the habit. A search for the same unsafe query style across the codebase is the real remediation.
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, treat the the orderByColumn and isAsc parameters as untrusted text. Use prepared statements so the value is bound as data, check that numeric identifiers are numbers before the query runs, and give the database account only the permissions the page needs. A read only page should not connect with an account that can drop tables.
Add a test that sends unexpected input to the page and expects a clean error. Then run a static scan over the rest of the codebase for the same pattern, because a flaw like this seldom stands alone.
Where reachability helps
A scan list tells you which products are present. Reachability analysis tells you whether your own code can actually call the vulnerable path. For source distributed projects, that is the difference between a long list of findings and the few that sit on a route someone can reach. The Safeguard Gold directory tracks this record, so you can follow changes to its score or references.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a patch available?
The record says the vendor was contacted early and did not respond, and no fixed release is named, so treat the product as unpatched until the vendor says otherwise. 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-9412
- Other references in the record, including VulDB, could not be retrieved when we checked.
Last reviewed: 18 October 2026.
