CVE-2025-7200 is a medium severity (CVSS 6.3) SQL injection in Pharmacy Management System from krishna9772. The quantity_upd.php file builds a database query from the med_name, med_cat and ex_date parameters without safe handling. No fixed version is confirmed, so remove public access or rewrite the query with prepared statements.
What's affected
The record names Pharmacy Management System from krishna9772 as the affected product. The weak spot is quantity_upd.php, which handles the page that updates medicine quantities. The record notes that the project uses continuous delivery with rolling releases, so no affected or fixed release numbers exist. It lists the affected code as everything up to commit a2efc8442931ec9308f3b4cf4778e5701153f4e5.
The record says the attack can be launched remotely and that the exploit details have been disclosed to the public. It does not say the flaw is exploited in the wild, and it is not in the CISA Known Exploited Vulnerabilities catalog (the record's KEV flag is false). The CVSS vector in the record (PR:L) says the attacker needs a low privilege account first.
The description text, which follows the VulDB wording, calls this issue "critical". The CVSS 3.1 base score in the record is 6.3, which is medium on the CVSS scale. Both are in the record, so you will see the word critical in some feeds next to a medium score. This post uses the score.
The weaknesses are listed as CWE-74 and CWE-89. The first is the broad class (injection into a downstream component). The second is the specific case of SQL commands built from untrusted input.
How to check if you're exposed
This flaw lives in the application source, not in a library, so a dependency scanner will not see it. Check the code and the logs instead. Start by finding the file:
grep -rn "quantity_upd.php" /var/www/
Open the file and look at how the med_name, med_cat and ex_date parameters reaches the database call. If the value is joined into a query string, the code matches the report. It is a time based SQL injection, the report says. Then check whether the application is reachable from the internet or from networks you do not control. Admin pages are not safe just because the link is not published.
To look for signs of probing, search your web server access log for requests to that path that carry quote characters or SQL keywords in the query string or form data:
grep "quantity_upd.php" /var/log/apache2/access.log | grep -iE "%27|union|select|sleep"
A hit does not prove a compromise, and a clean log does not prove safety, since POST bodies are usually not logged. Treat the log search as a hint only.
What to do now
- Find every copy of Pharmacy Management System you run, including test and demo installs.
- If it holds real data, take it off the public internet until the code is fixed.
- Replace string built queries in
quantity_upd.phpwith prepared statements, using PDO or mysqli parameter binding, and validate the type of themed_name,med_catandex_dateparameters. - Run the application's database user with the least rights it needs, so a bad query cannot read or change other tables.
- Rotate any credentials stored in the database if you suspect probing, and review the data for unexpected changes.
- Check the vendor page and the public report for a patch before you ship your own, and record the decision.
Why it matters
SQL injection happens when user input becomes part of a query's structure instead of staying as plain data. The database cannot tell the difference, so a crafted value can change what the query does. The usual cure is simple and old: pass values as bound parameters so they are never parsed as SQL.
This case is typical of small PHP applications that ship as downloadable projects. They are easy to deploy, rarely get a security review, and often have no maintainer who issues patch releases. That is why the missing fixed version matters more than the score. Without a patch, the choice is to fix the code yourself or stop running it.
Quick check
Is there a patch for CVE-2025-7200?
The record says the project uses rolling releases, so there are no version numbers to compare. Check the repository history yourself.
Will a dependency scan find this?
No. The flaw is in the application's own code, not in a third party package. A dependency scan such as the free in-browser Safeguard scan covers the libraries an application pulls in, and code level flaws need code or runtime testing as well.
Sources
Last reviewed: 18 October 2026.
