Issued in the public interest. All technical details are real. The alarm is only slightly performative.
Dear Hospital Administrator,
I understand. The budget meeting was tense. Someone said "Epic quoted us how much?" and someone else said "I found one on a tutorial site, it has a login page and everything." And so here you are, running patient records, doctor schedules, and billing on a PHP project whose own README is copy-pasted instructions for an Auto/Taxi Stand Management System.
I'm not here to judge. I'm here to gently inform you that the software triaging your patients has the structural integrity of a hospital made of breadsticks.
Please find below my findings, ranked by how quickly I'd like you to sit down.
Three of your four hospital systems treat the login form as a polite suggestion.
On itsourcecode HMS (adminlogin.php, doctorlogin.php, patientlogin.php), the username box drops straight into the database query. Typing ' OR '1'='1 where it asks for your email logs you in as the first staff account. There is no CVE for this. There are fourteen CVEs for other, lesser bugs in the same app. The front door was simply never considered worth mentioning.
The other apps agree in spirit: code-projects and PHPGurukul logins are the same unparameterized query, and on SourceCodester the doctor portal's access check (doctor/doctors.php:41) has been thoughtfully commented out.
SourceCodester HMS has security on all 27 of its privileged pages. Each one checks whether you're logged in, redirects you to the login screen if you're not, and then — crucially — keeps running the rest of the page. The header("location: login.php") line is missing its exit;, which in PHP is the difference between a locked door and a sign that says "locked door." Any visitor can delete any doctor, cancel any appointment, or wipe any patient account by visiting a URL. As a bonus, deletions happen over GET, so a patient could remove your entire staff directory by being shown the wrong image tag in an email.
itsourcecode's treatmentrecord.php:7 lets you upload a file. It does not check what kind of file. It will cheerfully accept a PHP script and place it in a web-accessible folder, at which point your hospital server runs whatever the attacker uploaded. This is remote code execution on the box holding your treatment records. It has no CVE. I am as surprised as you are.
code-projects HMS (admin/index.php:7) stores and compares the administrator password in plain text. Not hashed. Not even the bad kind of hashed. Just sitting there, like a spare key under a doormat that is itself made of glass.
I counted the files in itsourcecode HMS that build database queries by gluing user input directly into them. There are 60. Fourteen of them have CVEs. The remaining forty-six work exactly the same way and are simply waiting their turn. The other three products are not meaningfully better; I just got tired of counting.
Every app prints names, addresses, and medical notes back to the screen without escaping them, so a patient who registers under the name <script>…</script> gets their code run in the doctor's browser. I am listing this last not because it's minor but because, next to the unauthenticated RCE, it felt almost wholesome.
Here is the genuinely remarkable part. These four toy apps have 91 published CVEs between them. Researchers around the world have devoted real effort to documenting their flaws. Unfortunately:
md5() first, rendering it about as injectable as a brick.So to summarize: the bugs that would actually end your hospital — login bypass, file-upload RCE, plaintext admin credentials, mass unauthenticated deletion — have no CVEs at all, while several CVEs that do exist are for files, languages, and parameters that have never once been part of the software. The watchmen are extremely busy. They are just facing the wrong building.
exit; after every auth redirect, add CSRF tokens, validate uploads, and hash passwords. This is roughly the entire syllabus of "Web Security, Week 1," which is fitting, because these are Week 1 projects.I remain, in the public interest and with deep concern for the breadstick hospital,
The Researcher Who Read The Code Instead Of Counting It
Real findings, satirical delivery. Full technical detail — file, line, CWE, and the already-issued CVE that proves each unreported bug is real — lives in HMS_RESPONSIBLE_DISCLOSURE.md and HMS_UNDISCLOSED_CVES.md.
The receipts
Issued vs. duplicate vs. misattributed vs. unissued, per source. The numbers behind the jokes.
42 unreported-but-CVEable findings, each with file:line, CWE and a precedent CVE — plus the full per-file enumerations.
The straight version: what to tell each vendor, and the fixes.