CVE-2025-2951 is a medium severity (CVSS 6.3) SQL injection in Bluestar Micro Mall 1.0. The Search argument of /api/data.php is not handled safely, and the record says the attack can start remotely. I could not confirm a fixed version, so check with the vendor and apply compensating controls.
What's affected
The record lists Bluestar Micro Mall 1.0 as affected, in an unknown function of the file /api/data.php. The vulnerable input is the Search argument.
No fixed version appears in the record. The references point to a VulDB entry and a third party write up, not a vendor advisory. I could not retrieve those pages, so do not assume a patch exists. Ask the vendor or check the project's own release notes.
The record also states that the exploit has been disclosed to the public. It does not say the flaw is exploited in the wild, and it is not in the CISA KEV catalog.
How to check if you're exposed
If you run Micro Mall, check the version on your server and look for the file /api/data.php under the application root.
- Compare the installed version with 1.0. If it is 1.0, assume you are affected.
- Search your web server access logs for requests to /api/data.php that carry unusually long or unusual Search values. Look for SQL keywords and quote characters in that parameter.
- Check database logs for errors or slow queries that came from the same time windows.
You can also run a dependency and application scan before deciding. Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan can show whether a project's dependency list includes an affected component, and the Gold directory lets you look up the CVE and its related weaknesses.
What to do now
- Confirm whether any internet facing site runs Bluestar Micro Mall 1.0, and inventory it.
- Contact the vendor for a fixed release. If none exists, plan to replace or retire the application.
- Until then, put a web application firewall rule in front of /api/data.php that blocks SQL metacharacters in the Search parameter, and restrict access if the endpoint does not need to be public.
- Make sure the database account used by the application has the fewest permissions it needs, so a successful injection reaches less data.
- Rotate any credentials stored in that database if you find signs of probing.
Why it matters
The record maps this to CWE-89 (SQL Injection) and CWE-74 (Injection). The pattern is simple. User input from the Search field is placed into a database query without being separated from the query itself. The database then treats part of the input as instructions.
The standard fix is also simple: parameterized queries, so input stays data. A flaw like this in a search endpoint is exposed to anyone who can reach the page, which is why it deserves attention even at a medium score. The score reflects limited impact per the vector, but the practical damage depends on what the database holds, such as customer or order data.
Small shop applications are often installed once and never updated, so there is rarely a patch cycle to rely on.
Quick check
Does a medium score mean I can wait?
Not automatically. The score is a starting point. A public exploit disclosure and a search box reachable from the internet raise the practical risk.
How do I stop SQL injection in general?
Use parameterized queries or an ORM that does so, validate input, and give the database account only the permissions it needs.
Sources
Last reviewed: 19 October 2026.
