CVE-2025-7751 is a high severity (CVSS 7.3) SQL injection in code-projects Online Appointment Booking System 1.0. The cid parameter in /admin/addclinic.php reaches a database query without safe handling, and the CVSS vector lists network access with no login or user interaction. The record names no fixed version, so rewrite the query or take the app offline.
The description says the exploit has been disclosed to the public and may be used. The record does not flag this CVE as exploited in the wild, and it is not marked as a CISA Known Exploited Vulnerability. Public details still make it easy for others to try, so do not wait on that distinction.
What's affected
The record lists code-projects Online Appointment Booking System 1.0. The weakness is in /admin/addclinic.php, through the cid parameter. The path sits under the admin directory and looks like a form handler that adds a clinic. The CVSS vector still lists no privileges required. A booking application like this normally keeps user accounts, clinic and doctor records and appointment data in one database.
I could not confirm a fixed version. The record lists none, and the vendor page is a general site, not a security advisory. Online Appointment Booking System appears to be distributed as a free downloadable sample project, so a patched release may never ship. Treat any copy you run as unpatched until you have changed the code yourself.
This is one of several SQL injection reports against the same product. The others in this batch are CVE-2025-7540, CVE-2025-7541, CVE-2025-7587, CVE-2025-7749, CVE-2025-7750, CVE-2025-7752, CVE-2025-7753, CVE-2025-7764, CVE-2025-7765. Each one names a different file, which is a strong hint that the same mistake is repeated across the code base. Fixing /admin/addclinic.php alone will not make the application safe.
Severity needs a note. The description calls the issue critical, which is the wording VulDB uses when it files these reports. The score in the record is CVSS 7.3, which is High, with a vector of network access, low complexity, no privileges, no user interaction and low impact on each of confidentiality, integrity and availability. This post uses the score. The public write-up linked from the record (see Sources) was readable when I checked. It describes the same weakness as the record, a request value used directly in a SQL query without cleaning or validation.
How to check if you're exposed
First find out whether you run this application at all. Search web roots and repositories for the file name and for the product name:
find / -name "addclinic.php" -path "*php*" 2>/dev/null
grep -rIl "Online Appointment Booking System" /var/www 2>/dev/null
If the file exists, open it and look at how the cid value reaches the database. A query assembled by joining strings is the problem. A prepared statement with bound parameters is not:
grep -n "mysqli_query\|mysql_query\|->query(" addclinic.php
Then look at your web server access log for requests to the file. Unusual quote characters, SQL keywords or very long values in the parameter deserve a closer look:
grep "addclinic.php" /var/log/apache2/access.log | grep -i "%27\|union\|sleep(" | head
A clean log does not prove safety, because logging may be off or rotated. A hit means you should treat the database as possibly read or changed.
Safeguard's free in-browser dependency scan covers third party packages. It will not flag this issue, which sits in the application's own query code, so use code review or a SAST tool for that part.
What to do now
- Decide whether the application needs to run. If it is a demo, a training copy or an unused install, remove it.
- If it must stay up, take it off the public internet or limit it by IP address or VPN until the code is fixed.
- Replace string built queries in /admin/addclinic.php and in every other file that talks to the database with prepared statements. In PHP with mysqli the pattern looks like this:
$stmt = $conn->prepare("SELECT * FROM some_table WHERE some_column = ?");
$stmt->bind_param("s", $value);
$stmt->execute();
- Give the database account the application uses only the rights it needs. It should not own the schema or reach other databases.
- Review access logs and recent database changes for signs of misuse. If you find any, rotate the database password and any application credentials.
- A web application firewall rule can reduce noise while you fix the code. It is a stopgap, not a fix.
Why it matters
CWE-89 is SQL injection, and CWE-74 is the wider class of injection, where input changes the meaning of a command that another component interprets. Here the cause is plain: the cid value is placed into a SQL statement without being kept separate from the command. The database cannot tell data from instructions, so crafted input can change what the query does.
The damage depends on the query and the database account. It can range from leaking records to changing or deleting them. In small PHP projects, one account often has wide rights, which raises the stakes. The fix is not a longer blocklist. It is keeping data out of the command text, which prepared statements do by design.
Quick check
Is there a patched version of Online Appointment Booking System?
The record lists none, and I found no vendor advisory. Check the vendor site, and if nothing is published, fix the query code yourself or retire the application.
Does a web application firewall solve this?
It can block some obvious attempts, but it does not remove the flaw. The query is still built unsafely. Use prepared statements and treat the firewall as extra cover.
Sources
Last reviewed: 18 October 2026.
