CVE-2024-4294 is a Medium (CVSS 6.3) improper control of resource identifiers flaw in PHPGurukul Doctor Appointment Management System 1.0. The editid argument of view-appointment-detail.php lets a logged in user reach records they should not. The record names no fix, so limit exposure or move off this code.
What's affected
- Product: PHPGurukul Doctor Appointment Management System 1.0.
- Affected file: /doctor/view-appointment-detail.php, argument editid.
- Fixed version: none in the record. PHPGurukul projects are sample applications, so a patched release may not exist.
- Severity: Medium, CVSS 6.3, with low confidentiality, integrity and availability impact and a low privilege requirement. The description says "critical", the VulDB label.
- Exploitation: the record says an exploit was disclosed publicly. KEV is false.
How to check if you're exposed
Confirm whether version 1.0 of this application is deployed anywhere, including training and demo servers that hold real data. Look at the web server logs for requests to the appointment detail page where the editid value changes in sequence across many requests from one session. That pattern suggests someone is walking through records.
If you hold the source, check whether the page verifies that the logged in doctor owns the record before showing it.
What to do now
- Find any deployment of this application and note what data it holds.
- Take it off the internet or place it behind a VPN until it is fixed.
- Add an ownership check so a record loads only for the user it belongs to, if you maintain the code.
- Review logs for sequential editid values from a single account.
- If real patient data was exposed, involve your privacy or compliance contact.
Why it matters
The record maps this to CWE-99, CWE-639, which cover control of resource identifiers and the insecure direct object reference pattern. The page uses an identifier from the request to fetch a record and does not check that the requester may see it.
This is one of the most common web flaws and it is easy to miss in testing because every request looks valid. The fix is a server side authorization check on each lookup, not hiding or encoding the identifier.
Quick check
What is an IDOR?
An insecure direct object reference is when changing an identifier in a request, such as a record number, returns someone else's data because the server never checks ownership.
Is a patch available?
The record names none. Treat the application as unsupported unless the vendor says otherwise.
Scan your own dependencies
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan checks a manifest against known advisories, and the Gold directory keeps this record's details in one place.
Sources
The NVD record for CVE-2024-4294 (published 2024-04-27) supplied the description, score and weakness data. Pages marked fetched were read for this post. The others are listed in the record and were not read.
Last reviewed: 19 October 2026.
