Description

A flaw has been found in onetwothreeneth HospitalManagementSystem up to 9ef91ed6007314b6473110ed699dff76d158f61d. This affects the function update_subaccount of the file php/controller.php of the component Account Administration. This manipulation of the argument user_id causes improper authorization. Remote exploitation of the attack is possible. The exploit has been published and may be used. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The project was informed of the problem early through an issue report but has not responded yet.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-10-05T17:17:14.147Z",
  "pubdate": "2026-10-05T17:17:14.147Z",
  "executiveSummary": "A critical improper authorization vulnerability exists within the HospitalManagementSystem component of the onetwothreeneth repository, specifically affecting the update_subaccount function.\nThe vulnerability arises from insufficient validation of the user_id argument within php/controller.php, allowing unauthorized users to manipulate subaccount data.\nThis security flaw facilitates remote exploitation, potentially enabling attackers to perform unauthorized administrative or account-level actions without requiring legitimate authorization.\nGiven that the project uses a rolling release model and lacks a responsive maintenance cycle, the system remains in a high-risk state as public exploit code is currently available.\nThe vulnerability poses significant confidentiality and integrity risks to hospital management data, as attackers can gain unauthorized control over subaccount configurations.\nRemediation is currently hindered by the project's lack of response to vulnerability disclosures, necessitating immediate manual intervention by system administrators to secure the affected codebase.",
  "technicalDetails": "The vulnerability is localized to the update_subaccount function residing in php/controller.php. The root cause of this flaw is a failure to perform server-side verification of the user's session credentials against the requested user_id parameter during the subaccount update process.\nIn the vulnerable implementation, the controller processes the user_id provided in the HTTP request without enforcing a rigorous authorization check to ensure the requester possesses the necessary permissions to modify the targeted account. This is a classic Broken Access Control (BAC) vulnerability where the application trusts user-supplied input to determine the scope of the operation.\nThe attack flow begins with an attacker identifying a target subaccount identifier (user_id). By crafting a malicious HTTP request directed at php/controller.php, the attacker supplies the target user_id as a parameter to the update_subaccount function. Because the function lacks robust authorization logic, it performs the requested modification—such as altering account permissions, credentials, or personal information—despite the attacker lacking legitimate administrative rights for that specific account.\nExploitation is feasible remotely and requires no advanced authentication if the controller endpoint is publicly accessible. The public availability of exploit code simplifies the attack vector, allowing even low-skilled actors to execute this manipulation. The impact is significant: an attacker could escalate privileges by modifying administrative subaccounts, exfiltrate sensitive data associated with these accounts, or disrupt hospital management operations by sabotaging subaccount access.\nThe vulnerable code maintains a lack of secure session binding, meaning the application fails to reconcile the current authenticated user's privileges with the identity of the user_id submitted in the POST or GET request. This lack of indirect object reference validation or ownership verification allows for horizontal or vertical privilege escalation depending on the attacker's target.\nAs the system operates on a rolling release cycle and the specific commit hash 9ef91ed6007314b6473110ed699dff76d158f61d is currently identified as vulnerable, all implementations prior to any potential subsequent patches remain susceptible. The absence of a vendor response indicates that the vulnerability is not undergoing active remediation in the main branch."
}