CVE-2025-5359 is a high severity (CVSS 7.3) SQL injection in Campcodes Online Hospital Management System 1.0. The ID parameter of /appointment-history.php is not handled safely. The record lists no patch, so take the application off untrusted networks and fix the query code if you run it.
What's affected
The record names Campcodes Online Hospital Management System 1.0 and the file /appointment-history.php. Manipulating the ID argument leads to SQL injection, tracked as CWE-89 and CWE-74.
The record says the attack can be launched remotely and that the exploit has been disclosed to the public and may be used. It names no fixed release and no vendor advisory. The references are a public issue write up and VulDB entries, so treat this as an unpatched weakness and check the vendor site for any update.
This is one of several SQL injection records for the same application, including CVE-2025-5298, CVE-2025-5360 and CVE-2025-5361, so a fix for one page does not protect the rest. Applications of this type are often downloaded as source code and edited by whoever deploys them, so the same bug can appear in forks and renamed copies.
How to check if you're exposed
Find out whether the application is deployed anywhere in your estate, including demos, student projects and old test servers. Search web roots for the file named in the record:
find /var/www -name "appointment-history.php" 2>/dev/null
If the file exists, open it and see how the ID value reaches the query. Any place where request values are joined into SQL text, instead of passed as bound parameters, has the same class of flaw, so scan the other pages as well.
Check web server access logs for requests to that page with odd values in the parameter, and for database error text in responses. A DAST scan against a test copy shows whether the page is injectable without touching production.
What to do now
- Find every deployment of this application, including copies that hold real records.
- Take it off the public internet, or place it behind a VPN or an allow list, until the code is fixed.
- Change the code to use prepared statements with bound parameters for ID and review the other pages for the same pattern.
- Run the database account with the least rights it needs, with no file or administrative privileges.
- Review database and web logs for abnormal queries, and rotate any stored credentials if you find signs of abuse.
Why it matters
SQL injection occurs when user input becomes part of a query without being kept apart from the query structure. The database cannot tell the author's SQL from the attacker's, so depending on the account's rights an attacker can read, change or delete data.
Small PHP applications like this one often hold personal data and run with a single powerful database account, which raises the impact. The record gives no sign of use in attacks beyond saying a public exploit exists, and the CVE is not on the CISA Known Exploited Vulnerabilities list. The durable fix is parameterized queries everywhere, and a code scan that flags string built queries finds the sibling bugs before an attacker does.
Quick check
Is a fix available?
The record and its references do not name one. Fix the query code yourself, or take the application out of service.
Sources
Last reviewed: 18 October 2026.
