CVE-2025-4353 is a medium severity (CVSS 6.3) SQL injection flaw in Brilliance Golden Link Secondary System, in the file /paraframework/queryTsDictionaryType.htm. The record lists all releases up to 20250424 as affected and names no fixed release, so check with the vendor and meanwhile restrict access and review the code that builds the query.
What's affected
The record lists Brilliance Golden Link Secondary System, all releases up to 20250424. The vulnerable code is the file /paraframework/queryTsDictionaryType.htm, and the manipulated argument is dictCn1.
No fixed version is named in the record, and I could not confirm one from a vendor advisory. Ask the vendor for a statement and treat any build dated 20250424 or earlier as affected until you have it in writing.
The record gives a build date style version, 20250424, rather than a semantic version. Compare it against the build date shown in your own deployment.
How to check if you're exposed
Find out whether you run this software at all. Search your hosting inventory and web roots for the product name, then look for the file named in the record. On a Linux web server, a search such as grep -rn "queryTsDictionaryType.htm" /var/www will show where it lives.
Check the build or release date of your deployment against 20250424, and confirm whether the path under /paraframework/ is reachable from outside your network.
Review web server access logs for requests to the affected file, paying attention to unusually long or odd looking values in the named parameter and to bursts of database errors. This tells you whether anyone has already probed the endpoint. It does not prove that nobody has.
What to do now
- Locate every installation of Brilliance Golden Link Secondary System and record its version.
- Ask the vendor whether a fixed release exists, and apply it if one does.
- If the application is not needed, take it offline. Small admin tools often outlive their purpose.
- If it must stay up, limit access with a network allow list or VPN, and put a web application firewall rule in front of the affected file as a temporary guard.
- Change the code that builds the query to use parameterised statements, and make sure the application database account has only the privileges it needs.
- Rotate any credentials stored in the application database if you find signs of probing, and keep backups from before the exposure window.
Why it matters
SQL injection happens when user supplied text is joined into a database query instead of being passed as data. The record classes this under CWE-74 (Injection) and CWE-89 (SQL Injection). The argument dictCn1 reaches a query without safe handling, so a crafted value can change what the query does. The usual impact is reading or altering data the page was never meant to expose.
The record also says the exploit has been disclosed to the public and may be used, which lowers the work an attacker needs to do. The score is 6.3, driven by network access and low complexity. The record does not say the flaw is exploited in the wild, and it is not on the CISA Known Exploited Vulnerabilities list.
Small business and student project style applications are often deployed once and forgotten. If one of them holds personal or payment related data, the risk to that data is real even when the software is simple. Parameterised queries remove the whole class of bug, and they are cheap to adopt.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a fixed version I can install?
The record names none. Ask the vendor for a statement. Until then, restrict access and fix the query handling yourself if you have the source.
What is the fastest safe mitigation?
Take the application off the public internet or put it behind a VPN or allow list. That cuts off the remote attacker the record describes while you work on the code.
Sources
Last reviewed: 18 October 2026.
