CVE-2025-9391 is a medium severity (6.3) SQL injection flaw in Bjskzy Zhiyou ERP, affecting versions up to 11.0. 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: Bjskzy Zhiyou ERP
- Affected versions: up to 11.0
- Component:
com.artery.workflow.ServiceImpl (function getFieldValue) - Parameter: the
sqlparameter - 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 sql parameter 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 Java application. Fixes, if any, arrive as a new release or a local code change.
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 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 "artery"
If you run a packaged build from someone else, ask them which release it is and compare it with the affected range (up to 11.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 Bjskzy Zhiyou ERP 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.
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-9391
- Other references in the record, including VulDB, could not be retrieved when we checked.
Last reviewed: 18 October 2026.
