CVE-2025-10473 is a medium severity SQL injection flaw (CVSS 6.3) in yangzongzhuan RuoYi up to 4.8.1. The weakness sits in SqlUtil.java (function filterKeyword, Blacklist Handler component). The record names no fixed version, so upgrade past 4.8.1 if one exists, and review the advisory.
What's affected
The record lists yangzongzhuan RuoYi up to and including version 4.8.1. The weak code is the function filterKeyword in com/ruoyi/common/utils/sql/SqlUtil.java, part of the Blacklist Handler component. That function is meant to screen input before it reaches the database.
No fixed version appears in the record. I could not confirm a patched release from the sources available, so check the yangzongzhuan site and the referenced report before assuming a fix exists. The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L, which means network reachable, low complexity, no user interaction, and low privileges required, typically a logged in account.
How to check if you're exposed
Check the version in your build file or the About page of your admin console. For a Maven project, list resolved dependencies and your own source tree:
grep -rn "filterKeyword" src/ --include=*.java
grep -n "<version>" pom.xml | head
You can also paste your dependency manifest into the free in-browser scan at gold.safeguard.sh/scan. It will not find an application like this one if you installed it as a standalone folder, so inventory it by hand.
What to do now
- Check the RuoYi release notes and project repository for a version newer than 4.8.1, and upgrade if one addresses this.
- Do not rely on keyword blacklists for SQL safety. Move queries to parameter binding.
- Run the database account for this application with the least privileges it needs.
- Put a web application firewall rule in front of the endpoint as a stopgap, knowing it is not a fix.
- Review logs and database contents for signs of misuse, and rotate any credentials stored in the affected database.
- Decide whether this software should be in production at all if the maintainer does not ship fixes.
Why it matters
This is CWE-89 within the broader injection class CWE-74. The application builds a database query from text the user supplies, and the database cannot tell the developer's query from the attacker's additions. The result can be reading, changing or deleting data, which fits the low confidentiality, integrity and availability impact in the vector.
The fix pattern is old and well known: parameterized queries. The harder question for small web applications is who will apply it. Because this endpoint needs a logged in account (PR:L in the vector), the practical risk depends on who can obtain one. The record does not flag this CVE as a CISA Known Exploited Vulnerability, so there is no confirmation here that it is exploited in the wild.
The record also says the exploit has been disclosed to the public. That is a statement about published details, not a confirmation of attacks, so treat the timeline as short without assuming a breach.
Planning for software with no vendor fix
When no patched version is named, you have three options: fix it yourself, shield it, or retire it. Fixing it yourself works well for small PHP applications, since the change is usually one query. Shielding means network controls and a firewall rule. Retiring means moving to a maintained alternative.
Whichever you choose, write the decision down with an owner and a review date. Unpatched software tends to be forgotten rather than decided on. Continuous monitoring of your inventory against new advisories makes sure a fix, if one appears later, does not slip past you.
How scoring and records can mislead
A CVSS score is a starting point. It describes the flaw in general, not your deployment. Two things can move your real risk in either direction: whether the vulnerable component is reachable from where attackers sit, and what the process can touch once compromised.
Also keep in mind that records for newly published CVEs are often thin. Some state a vendor name and a file and little else. When the advisory is short, rely on your own inventory and on defensive basics, and revisit the record as details are added.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a fixed version of RuoYi?
The record lists none. Check the yangzongzhuan site and the referenced report. Until then, restrict the endpoint and fix the code yourself.
Is this being exploited in the wild?
The record does not flag it as a CISA KEV entry. It does say the exploit has been published, so assume attackers can reproduce it.
Sources
- Safeguard Gold entry for CVE-2025-10473
- NVD record for the CVE, as supplied in the Safeguard CVE feed
- The links below come from that record. Several could not be opened when this post was reviewed, so confirm details with the vendor.
- https://github.com/mo957/vuln/blob/main/ruoyi_sqlinject/ruoyi_sqlinject.md
- https://vuldb.com/?ctiid.323905
- https://vuldb.com/?id.323905
- https://vuldb.com/?submit.648475
Last reviewed: 19 October 2026.
