Educational / defensive security research for a blog post on CVE farming. The four "Hospital Management System" (HMS) projects studied here are throwaway PHP tutorial/demo apps from code-sharing sites — none is used to run real infrastructure. No weaponized PoCs are included; findings are reported at the class + file:line + rationale level.
Date: 2026-06-29. Source-of-truth: a local copy of the public CVE Program corpus + the downloaded source of each project. Per-project analysis was performed by four independent code-reading passes.
Across the four HMS projects there are 91 issued CVEs. After normalizing each CVE to a (file, parameter, vulnerability type) tuple and reading the actual source:
| Source | Issued | Unique (deduped) | Redundant | Misattributed / false | Undisclosed CVEable |
|---|---|---|---|---|---|
| PHPGurukul HMS | 53 | ~31 | ~22 | 1 | 9 |
| itsourcecode HMS | 16 | 14 | 0 | 2 | 6 |
| SourceCodester "Free HMS for Small Practices" (Vaidya Mitra) | 12 | 10 | 1 | 1 | 7 |
| code-projects HMS (Fabian Ros) | 10 | 10 | 0¹ | 2 | 14 |
| Total | 91 | ~65 | ~24 | ~6 | ~36 |
¹ code-projects has no exact duplicate, but CVE-2024-8368 / CVE-2024-8569 are a probable patient-login dup pair.
Three findings drive the whole story:
Every one of these apps shares a single uniform defect profile:
$_GET / $_POST / $_REQUEST concatenated into string-interpolated mysqli_query() / mysql_query() (SQLi),echo of user input or DB fields without htmlspecialchars (XSS),Farming converts this one defect into many CVEs by slicing it one-file-one-parameter at a time. PHPGurukul is the clearest example: four early umbrella CVEs (CVE-2020-5191/5192/22176 "throughout the application", CVE-2023-7172 "admin dashboard") already cover the whole app, after which ~25 single-file/single-param CVEs re-report the same bugs.
adminviews.py, a Django/Python file that does not exist in this PHP codebase. Several contact.php / about-us.php / index.php CVEs resolve to admin-area files or the public site root (loose path attribution).admin/change-password.php:20 — npass SQLi (the CVE covers only cpass). 2. reset-password.php:11 + doctor/reset-password.php:11 — SQLi via session name/email. 3. doctor/forgot-password.php:9 + doctor/index.php:9 — doctor-portal login/forgot SQLi (patient equivalents got CVEs; doctor copies did not). 4. appointment-history.php:10 + doctor/appointment-history.php:11 — id SQLi + IDOR (cancel any appointment). 5. admin/check_availability.php:6 + doctor/check_availability.php:5 — unauth SQLi (only the patient copy is CVE'd). 6. admin/contact.php:17 — pagetitle / pagedes / email SQLi (only mobnum is CVE'd). 7. doctor/edit-profile.php:16 — profile-update SQLi. 8. Stored XSS across ~10 admin listing pages (manage-patient, manage-doctors, user-logs, doctor-logs, read-query, unread-queries, manage-medhistory, …). 9. App-wide CSRF — only add-doctor.php got a CSRF CVE; every other state-changing form is equally forgeable.adminaccount.php / Date — no such param or sink) and CVE-2026-11514 (addpatient.php — file does not exist; the named admissiontme parameter is a real SQLi, but it lives in patient.php:8 / patientprofile.php:6, so the bug reproduces only after correcting the filename). Note the distinction: 11513's sink is genuinely absent (adminaccount.php is a static dashboard with no request input at all), whereas 11514 is a real vulnerability filed against the wrong file.adminlogin.php:41, doctorlogin.php:16, patientlogin.php:17 (pre-auth concatenated login query). 2. Unrestricted file upload → RCE — treatmentrecord.php:7 (move_uploaded_file with no extension/MIME/content validation, into a web-served dir). Most severe finding in the corpus. 3. treatmentrecord.php SQLi via editid/delid/patientid/appid + state-changing DELETE by GET. 4. Reflected/stored XSS in treatmentrecord.php, patientdetail.php, billing.php (only billing.php is CVE'd). 5. patient.php:8 / patientprofile.php:6 SQLi (the true home of the misnamed CVE-2026-11514). 6. The same SQLi class across ~45 additional root PHP files (only 14 files received CVEs) plus inconsistent/absent admin session guards./vm/) — 12 issued> VulDB filed against this one codebase under two product names ("Free Hospital > Management System" and "SourceCodester Hospital Management System").
sheduledate SQLi in patient/appointment.php:77).appointmentapproval.php, absent from the code.admin/delete-doctor.php:18 — SQLi + broken auth (guard lacks exit). 2. admin/add-new.php:55 — create-doctor SQLi (multiple POST params). 3. admin/edit-doc.php:44 — admin twin of the CVE'd doctor/edit-doc.php. 4. admin/add-session.php:23 — schedule-insert SQLi. 5. delete-session.php / delete-appointment.php (admin/doctor/patient copies) — SQLi + IDOR (any user deletes any record; guards lack exit). 6. admin/appointment.php + doctor/appointment.php — sheduledate/docid SQLi (only the patient copy is CVE'd); doctor/doctors.php auth check is commented out. 7. Systemic broken access control + app-wide CSRF — every privileged endpoint redirects to login without exit, so all admin/+doctor/ mutations run unauthenticated; deletions are GET links with no tokens.secret artifact — wrong product entirely; CVE-2024-10169 is over-claimed — its cpass param is md5()-wrapped before the query, so it is not injectable as described.doctor/index.php:6 login SQLi; registration.php:11 (+admin/doctor copies) SQLi; book-appointment.php:20 SQLi; edit-profile.php:14 SQLi; admin/edit-doctor-specialization.php:12 SQLi (only the add page is CVE'd); admin/edit-doctor.php:16 SQLi (only add-doctor is CVE'd); doctor/edit-profile.php:14 SQLi; get_doctor.php:20 second SQLi sink; getfee.php:10 unauth unquoted SQLi; admin/doctor-specilization.php + manage-doctors.php + manage-users.php GET-DELETE SQLi/IDOR; appointment-history.php:9 (+doctor copy) cancel-any-appointment IDOR+SQLi; admin/change-password.php:11 genuine SQLi (not md5-wrapped, unlike the weakly-CVE'd user page); stored XSS across listing pages (only doctor-name is CVE'd); systemic CSRF (no tokens; GET-based deletes); admin passwords stored/compared in plaintext.The same farming logic that inflated ~65 real bugs into 91 CVEs could inflate these 36 into hundreds — which is precisely the point of the post.
/vm/) from an unrelated "Upturn HMS" (0 CVEs) and a CodeIgniter "Hospital Management System" — only the /vm/ codebase matches the CVE file paths.Updated 07/23/26 — Independently re-verified all five flagged filings against the downloaded source (confirmed by an external reviewer). CVE-2024-10169 (cpass is md5()-wrapped), CVE-2025-11609 (Node/express-session), CVE-2026-1550 (Django .py) and CVE-2026-11513 (adminaccount.php has no request input) all hold as filed-in-error. CVE-2026-11514 is refined: its admissiontme SQLi is real but was filed against a non-existent file (addpatient.php) rather than its true home, patient.php:8.