HospitalManagementSystem EUVD-2026-92479

The attacker must reach a network-exposed HospitalManagementSystem instance and invoke the update_subaccount function of php/controller.php (Account Administration component), supplying an attacker-chosen user_id to act on another user's subaccount. In practice this is an IDOR in an account-management action, so a session/account on the application is almost certainly needed despite the supplied PR:N rating - verify auth requirement with the code. Limiting factors: the defect only affects data reachable through subaccount administration, impact is Low across C/I/A (no RCE, no scope change), and the product's tiny deployment footprint sharply limits realistic targets.

This is a moderate, low-priority issue despite being remotely reachable. The input CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N) rates it 5.5 with only Low impact to confidentiality, integrity, and availability (VC:L/VI:L/VA:L) and no scope change - consistent with an improper-authorization/IDOR defect (CWE-285) rather than full account takeover or RCE. Exploitation signals are mixed: a public exploit exists (POC=YES, VulDB, published as GitHub issue #7), and the CVSS 4.0 exploit-maturity metric is E:P (Proof-of-Concept), but this is NOT in CISA KEV and no EPSS score was provided, so there is no evidence of active or widespread exploitation. Note a tension worth verifying: the supplied vector states PR:N (unauthenticated), yet an 'improper authorization' flaw in a subaccount-administration function typically presupposes an existing authenticated session being abused to act on another user_id - the real-world prerequisite is likely a low-privileged account, which would make this an authenticated IDOR. The product itself is an obscure open-source hobby project with negligible production deployment, which far outweighs the exploit availability: real-world risk is low. Treat as a routine patch-when-available item, not an emergency.

An attacker with (or who can register) a low-privileged account on an exposed HospitalManagementSystem instance sends a crafted request to the update_subaccount handler in php/controller.php, tampering with the user_id argument to modify a subaccount belonging to another user. Because the authorization check is missing or broken, the manipulation succeeds and the attacker alters account data they should not control. A proof-of-concept is publicly available (referenced via the project's GitHub issue tracker), lowering the skill needed to reproduce it.