CVE-2026-124485 in OpenEMR
Summary
by MITRE • 11/08/2026
OpenEMR before 8.3.0 contains an authorization bypass vulnerability in the patient portal onsitedocuments API that allows authenticated patients to read other patients' documents by overriding query criteria. Attackers can send empty pid_Equals and denialReason_IsNotLike parameters to remove patient scoping and locked filters, exposing consent bodies, signatures, file paths, and template data.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/08/2026
The vulnerability identified in OpenEMR versions prior to 8.3.0 represents a critical authorization bypass within the onsitedocuments API of the patient portal component. This flaw stems from improper implementation of access controls when processing query parameters that dictate how document retrieval requests are filtered and scoped. Specifically, the application fails to enforce strict validation on input fields related to patient identification and consent status filtering. By manipulating these inputs, an authenticated user can effectively neutralize server-side security checks designed to restrict data visibility to only their own records. This type of flaw is classically categorized under CWE-284 Improper Access Control, as it allows a principal to access resources belonging to another principal without proper authorization verification.
The technical mechanism behind this exploitation involves the injection or omission of specific query parameters that influence the database retrieval logic. When an attacker sends empty values for pid_Equals and denialReason_IsNotLike, they are essentially stripping away the conditional clauses that limit results to a single patient's context. The pid_equals parameter typically serves as the primary key filter ensuring data isolation between patients, while denial_reason filters often manage consent-based visibility rules. By removing these constraints through empty payloads, the backend query expands its scope to encompass all documents in the system rather than just those associated with the authenticated user’s medical record ID. This behavior indicates a failure in input validation and logic integrity checks at the API layer, where trusted assumptions about parameter presence are exploited to bypass security boundaries.
The operational impact of this vulnerability is severe due to the sensitive nature of electronic health records. Successful exploitation allows an attacker to read confidential patient documents belonging to other individuals. The exposed data includes consent bodies which detail privacy preferences and permissions, digital signatures that may be used for legal or administrative verification, file paths that could reveal internal system structures or storage locations, and template data containing potentially identifiable information. This constitutes a significant breach of confidentiality and violates core principles of healthcare data protection such as HIPAA in the United States or GDPR in Europe. The ability to access this breadth of sensitive personal health information undermines patient trust and exposes organizations to substantial legal liability and regulatory penalties.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Collection via Local Network Sharing or API Abuse, specifically falling under T1005 Data from Local System if the attacker is already inside a network perimeter, or more accurately T1199 Trusted Relationship Exploitation since it leverages legitimate authentication credentials. The attack vector requires initial access through valid patient portal login credentials, which classifies it as an authenticated insider threat scenario rather than an unauthenticated remote code execution. This distinction highlights the importance of implementing defense-in-depth strategies where even authorized users are subject to strict resource-level permissions regardless of their session validity.
Mitigation for this vulnerability involves immediate patching to version 8.3.0 or later, which addresses these input validation flaws and enforces stricter scoping rules on API endpoints. In addition to upgrading, organizations should implement robust input validation mechanisms that reject empty or malformed parameters in critical query fields. Implementing strict server-side authorization checks for every data retrieval operation is essential to ensure that the requesting user’s identity matches the resource owner regardless of client-supplied filters. Furthermore, adopting principle of least privilege principles and conducting regular security code reviews focused on API logic can prevent similar access control bypasses. Monitoring logs for unusual query patterns involving empty critical parameters may also aid in early detection of exploitation attempts before significant data exfiltration occurs.