CVE-2026-124447 in OpenEMR
Summary
by MITRE • 11/08/2026
OpenEMR before 8.3.0 contains an insecure direct object reference vulnerability in OnsitePortalActivityController::Update() that checks the request's patientId instead of the stored record's owner. Authenticated portal patients can send PUT requests to the onsiteportalactivity API with another patient's activity id and their own patientId to disclose tableArgs and checksum data, overwrite narratives and status, and take ownership of the record.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/08/2026
The vulnerability identified in OpenEMR versions prior to 8.3.0 represents a critical failure in access control mechanisms within the OnsitePortalActivityController component. Specifically, the Update method relies on an insecure direct object reference pattern where authorization decisions are based solely on the patientId parameter provided by the client request rather than verifying that this identifier matches the actual owner of the resource being modified. This architectural flaw allows authenticated users to bypass intended security boundaries and interact with data belonging to other patients within the system.
From a technical perspective, the core issue lies in the server-side logic which accepts a PUT request containing a target activity ID alongside a patientId parameter. The application validates that the provided patientId corresponds to an authenticated user but fails to cross-reference this identifier against the ownership metadata stored in the database record for the specified activity. Consequently, if an attacker knows or can guess another patient's activity identifiers, they can submit requests with their own valid session credentials and the target victim's data identifiers. This lack of object-level authorization check effectively neutralizes the authentication layer, as any authenticated user is treated as having full administrative rights over any resource whose identifier they supply in the request payload.
The operational impact of this vulnerability is severe due to the sensitive nature of electronic health records. An attacker can exploit this flaw to disclose confidential table arguments and checksum data associated with other patients' medical activities. Beyond mere information disclosure, the ability to overwrite narratives and status fields allows for significant integrity violations. Malicious actors could alter clinical notes, change appointment statuses, or manipulate treatment plans, leading to potential misdiagnosis, inappropriate treatments, or disruption of care continuity. Furthermore, taking ownership of these records grants the attacker persistent control over sensitive medical data, facilitating long-term espionage or sabotage within the healthcare environment.
This vulnerability aligns with CWE-284, which describes Improper Access Control where a user can access resources they are not authorized to view or modify. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1078, specifically Valid Accounts and potentially T1530 for Data from Cloud Storage if the backend utilizes cloud-based storage solutions. The exploitation path involves authenticated users leveraging insecure direct object references to escalate their privileges over specific data objects without requiring additional authentication factors or privilege escalation exploits against the underlying operating system.
Mitigation strategies must prioritize immediate patching of OpenEMR to version 8.3.0 or later, where this logic error has been addressed by implementing strict ownership verification during update operations. For systems that cannot be immediately patched, administrators should implement a web application firewall rule set designed to detect and block PUT requests that attempt to modify resources with identifiers inconsistent with the authenticated user's profile ID. Additionally, enforcing server-side validation that strictly compares the requesting user's identity against the resource owner field before processing any write operations is essential. Regular security audits focusing on object-level access controls across all API endpoints are recommended to prevent similar flaws in other modules of the application.