EUVD-2026-89557
GHSA-7h83-xvfx-px88
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to HospitalManagement web app
-
DeliveryRequest laporan_data_pasien.php detail endpoint
-
ExploitTamper id_param with other patient's ID
-
ExecutionServer skips authorization check
-
ImpactRead unauthorized patient report data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires an authenticated session to the HospitalManagement admin application; the attacker then manipulates the id_param argument of the 'detail' function in application/modules/admin/controllers/laporan_data_pasien.php to access patient-report records belonging to other users. Exploitation is remote and needs no user interaction, but is limited by the authentication requirement and by impact scope (read-only disclosure of patient report data - no write/integrity or availability effect). No non-default configuration is required; the flaw is a missing per-record authorization check. |
| Impact | This is a low-to-moderate real-world risk that the CVSS 4.0 base score of 5.1 (Medium) reasonably captures. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N/VC:L) indicates a network-reachable, low-complexity flaw that nonetheless requires privileges (PR:H) and yields only low confidentiality impact (VC:L) with no integrity or availability effect - consistent with a CWE-639 authorization bypass (IDOR) exposing individual patient-report records. The 'E:P' temporal metric aligns with the reported public exploit (POC=YES via GitHub issue #10). No EPSS score and no CISA KEV listing are present in the input, and there is no evidence of active exploitation. Signals therefore point to a genuine but bounded issue: publicly available exploit code exists, but impact is limited to authorized-user horizontal data access rather than takeover. One conflict worth flagging: VulDB rates PR:H, yet a classic id_param IDOR typically needs only a low-privilege authenticated session, so PR:L may be more accurate - verify the exact privilege needed to reach laporan_data_pasien.php. Overall this is a low-priority-to-medium-priority issue driven more by exploit availability and the sensitivity of health data than by raw severity. |
| Exploit ScenarioDerived | An authenticated user of the HospitalManagement application sends a request to the laporan_data_pasien.php 'detail' endpoint and substitutes another patient's identifier into the id_param argument, causing the application to return report data for a record the user is not authorized to view. Public exploit code demonstrating this manipulation is available (GitHub issue #10). Because the application performs no per-record ownership/authorization check, iterating id_param values enumerates other patients' data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 30, 2026
Authorization bypass (CWE-639, IDOR) in gedelumbung HospitalManagement lets an authenticated user of the admin application read patient-report records belonging to other users by tampering with the id_param argument passed to the detail function in application/modules/admin/controllers/laporan_data_pasien.php. The flaw is remote and needs no user interaction, but the attacker must first hold a valid admin session, and impact is limited to read-only disclosure of patient report data (no integrity or availability effect); our independent assessment rates this CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, broadly consistent with the published CVSS 4.0 base score of 5.1 (Medium). Publicly available exploit code exists (the vendor GitHub issue thread serves as the proof of concept), but there is no confirmed active exploitation (CISA KEV). The project is unversioned, the vendor was notified via an issue report and has not responded, so no fixed release is identified at time of analysis.
RemediationAI
No vendor-released patch was identified at time of analysis: the issue was reported to the project early via https://github.com/gedelumbung/HospitalManagement/issues/10 and the maintainers have not responded, and because the project is unversioned there is no fixed release to upgrade to, so remediation must be applied in code or through compensating controls. The correct code-level fix is to add an explicit per-record authorization check inside the detail action of application/modules/admin/controllers/laporan_data_pasien.php, validating that the record resolved from id_param belongs to the authenticated session's user/tenant before rendering it - and more generally to never trust client-supplied identifiers for access-control decisions. Until such a change is applied, actionable mitigations are: restrict the admin application (or at minimum the laporan_data_pasien controller) to trusted networks or VPN and enforce strong authentication and MFA there, accepting reduced operational flexibility for remote staff; disable or remove the vulnerable detail endpoint if patient-report detail views are not operationally required, at the cost of losing that reporting functionality; and deploy a reverse-proxy or WAF rule that flags or blocks requests to the admin laporan_data_pasien path where id_param falls outside the caller's authorized record set, understanding that such rules are signature-based and brittle against parameter-encoding evasion. Additionally, enable and retain detailed application access logs for the admin controller so that anomalous enumeration of id_param values can be detected and investigated, and treat any records already exposed as a privacy incident requiring notification review under applicable healthcare data regulations.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is a PHP web application (gedelumbung HospitalManagement), and the vulnerable code path sits in the admin controller application/modules/admin/controllers/laporan_data_pasien.php, specifically the 'detail' action. The root cause is CWE-639, Authorization Bypass Through User-Controlled Key: the detail function takes a client-supplied identifier (id_param) and uses it to look up a record without verifying that the requesting session is entitled to that particular patient report. This is a classic insecure direct object reference in which the access-control decision is delegated implicitly to the caller's choice of key rather than being enforced server-side per record. Because the request is made directly against the web application over HTTP (AV:N) and requires only that the caller already possess a valid administrative session (PR:H in the published CVSS 4.0 vector, PR:L in our assessment), the practical precondition is authenticated access to the admin module. The CPE entry cpe:2.3:a:gedelumbung:hospitalmanagement:*:*:*:*:*:*:*:* records the product as unversioned, meaning the whole codebase stream - including the referenced commit c2d45543789a3887067d3915f69d44cfc2cf76a8 - is in scope and no clean version boundary can be drawn. Impact is confined to confidentiality: the manipulation leaks records, with no demonstrated write, integrity, or availability consequence.
Know when Hospitalmanagement gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
Network IDOR requiring only a low-privilege authenticated session (PR:L, not PR:H); read-only disclosure of individual patient records gives C:L with no integrity or availability impact.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
Lifecycle Timeline
3DescriptionCVE.org
A weakness has been identified in gedelumbung HospitalManagement up to c2d45543789a3887067d3915f69d44cfc2cf76a8. This vulnerability affects the function detail of the file application/modules/admin/controllers/laporan_data_pasien.php. Executing a manipulation of the argument id_param can lead to authorization bypass. The attack can be launched remotely. The exploit has been made available to the public and could be used for attacks. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The project was informed of the problem early through an issue report but has not responded yet.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Related Vulnerabilities in gedelumbung HospitalManagement Multiple Vulnerabilities
View all 6More in Hospitalmanagement
View allImproper authentication in the password-change handler of gedelumbung HospitalManagement allows an authenticated low-pri
Cross-site request forgery in HospitalManagement allows remote attackers to trick an authenticated user's browser into s
SQL injection in the gedelumbung HospitalManagement application (PHP/CodeIgniter-style MVC codebase) allows an attacker
Exploit-DB