CVE-2025-2640 is a high severity (CVSS 7.3) SQL injection flaw in PHPGurukul Doctor Appointment Management System 1.0. The fromdate and todate input handled by /doctor/appointment-bwdates-reports-details.php reaches a database query unsafely. The record lists no patched release, so fix the query code, restrict access to the app, or retire it.
What's affected
- Product: PHPGurukul Doctor Appointment Management System, a PHP or web application of the kind often downloaded as a learning project or small business tool.
- Affected: version 1.0, as named in the record.
- Fixed: the record names no fixed release. Check the vendor's site before assuming one exists.
- Entry point:
/doctor/appointment-bwdates-reports-details.php, through the fromdate and todate input. - Access: no login is needed. The attack is network based and needs no user interaction.
- Public exploit information: The CVE record says the exploit has been disclosed to the public and may be used.
How to check if you're exposed
Start by finding out whether you run this application at all. Look at your web roots and application inventory for the product name, and check which version the install reports.
Then look at the code. Search for the file and the input named in the record.
grep -rn "fromdate" --include=*.php <path-to-app> | head -20
Read the query that handles the value. If the code builds the SQL string by joining the request value into it, the flaw is present. Prepared statements with bound values are the safe pattern.
Check the web server logs for requests to the affected page.
grep "appointment-bwdates-reports-details.php" /var/log/nginx/access.log | less
Look for long or odd looking values, repeated requests from one address, and requests outside business hours. Then compare the database for rows you did not add, rows that have gone missing, or accounts you do not recognise.
What to do now
- Check whether the application is needed. If not, remove it, because an unpatched app with a public exploit write up has no good reason to stay online.
- If you need it, change the query code at the affected file so the value is bound as a parameter rather than joined into the SQL string.
- Restrict access with authentication at the web server, an allow list of addresses or a VPN until the code is fixed.
- Run the database account the app uses with the least privileges it needs, so a query flaw cannot drop tables or reach unrelated data.
- Back up the database, then review it for unexpected rows, changed values and new accounts.
- Rotate any credentials stored in the app's configuration if you saw suspicious requests.
- Check the vendor or project page regularly for a fixed release.
Why it matters
The class is SQL injection. A value from the request is joined into a database query as text, so the database cannot distinguish the developer's query from the caller's input. The input here is fromdate and todate, handled by /doctor/appointment-bwdates-reports-details.php.
- CWE-74 is the broad injection class. Data crosses into a downstream interpreter, here the database, without its special elements being neutralized.
- CWE-89 is improper neutralization of special elements in an SQL command. Input that should be treated as data ends up inside the query text, so the database cannot tell the application's query from the caller's input.
The record tags CWE-74 and CWE-89. The standard fix is the same for every case of this class: use parameterised queries, validate input to the shape you expect, and give the database account only the rights the page needs.
Appointment systems hold patient names, contact details and visit dates. Depending on where you operate, that data may come with legal duties if it leaks. The vector lists no privileges required, so the report page can be reached by an unauthenticated caller according to the score. Check whether the report pages sit behind a login on your install.
// Generic pattern: bind the value instead of building the query string
$stmt = $con->prepare("SELECT * FROM some_table WHERE id = ?");
$stmt->bind_param("i", $id);
$stmt->execute();
Tutorial style PHP projects are a common source of this pattern. They are meant to teach, not to defend, and teams sometimes deploy them as they are. If you use one in production, treat it as code you now maintain, and review every place where a request value reaches a query.
Quick check
What data is at risk?
Whatever the database account can read, which for an appointment system includes personal and health related records.
Does the page need a login?
The vector says no privileges required, so check your install and add authentication at the web server if it is open.
Sources
Last reviewed: 19 October 2026.
