HospitalManagementSystem CVE-2026-104609

Exploitation requires network access to a deployed instance of onetwothreeneth HospitalManagementSystem and the ability to send HTTP requests to edit_accounts.php; the attacker manipulates the user_id, patient_id, physician_id, discounts_id, or services_id argument to the get function. Per the CVSS vector (PR:N/UI:N/AC:L/AT:N) no authentication, no user interaction, and no special configuration are required against an affected build. The primary limiting factor is deployment: this is an individual open-source project with a tiny install base, so realistic exposure depends on finding an internet-reachable instance running vulnerable code (up to commit 9ef91ed6). No official patch exists, so any live deployment is exploitable.

This is a genuine but moderate-priority issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remotely reachable, low-complexity, unauthenticated SQL injection, which normally warrants urgency; however, the impact metrics are all rated Low (VC:L/VI:L/VA:L) and scope is unchanged, yielding only a 5.5 (Medium) score - the assessor evidently judged that the injection yields partial rather than full database compromise. The E:P (Proof-of-Concept) exploit maturity aligns with the stated public exploit availability, but there is NO CISA KEV listing and no EPSS score was provided, so there is no evidence of active or widespread exploitation. SSVC-style signals are mixed: exploitation is proof-of-concept (not active), the flaw is likely automatable given it is an unauthenticated GET-parameter SQLi, but technical impact is partial. The low CVSS impact rating is in tension with the nature of SQL injection, which frequently enables full data exfiltration or authentication bypass - verify the real blast radius against the actual code, as the Low/Low/Low impact rating may understate risk for a hospital data application handling PHI. Net: real and exploitable, but constrained by the product's negligible real-world footprint rather than by technical difficulty.

A remote, unauthenticated attacker sends a crafted HTTP request to edit_accounts.php, tampering with one of the id parameters (e.g. user_id, patient_id) to inject SQL into the backend query. A public proof-of-concept exists (referenced via the project's GitHub issue tracker), lowering the skill needed to reproduce the attack and read or manipulate database records such as patient and account data.