CVE-2026-124473
Summary
by MITRE • 11/08/2026
OpenEMR before 8.3.0 contains a broken object-level authorization vulnerability in the SOAP note update API, which does not verify that the supplied SOAP note ID (sid) belongs to the supplied patient and encounter. Authenticated users with encounters/notes permission can send PUT requests to /api/patient/:pid/encounter/:eid/soap_note/:sid with another patient's sid to overwrite that clinical note and reassign its pid.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
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, specifically classified as Broken Object Level Authorization or Insecure Direct Object Reference within the Common Weakness Enumeration framework. This flaw resides within the SOAP note update API endpoint, which is designed to allow authenticated users with specific permissions to modify clinical documentation associated with patient encounters. The core technical deficiency lies in the server-side validation logic during PUT requests directed at /api/patient/:pid/encounter/:eid/soap_note/:sid. While the application correctly verifies that the user has permission to access or edit notes, it fails to perform a secondary authorization check to ensure that the supplied SOAP note identifier (sid) actually belongs to the patient and encounter identifiers provided in the URL path. This lack of cross-referencing allows an attacker to manipulate object references by substituting the sid parameter with one belonging to a different patient's record.
From an operational perspective, this vulnerability enables authenticated users who possess encounters or notes permissions to overwrite clinical data belonging to other patients. By sending a PUT request with a valid pid and eid for their own encounter but injecting a sid from another patient’s note, the attacker can effectively hijack that external SOAP note. The system processes the update as if it were legitimate, resulting in the modification of sensitive medical information without proper authorization. This action not only compromises the integrity of clinical records by allowing unauthorized edits to data outside the user's assigned scope but also facilitates a reassignment of the patient identifier (pid) associated with that specific note. Such manipulation can lead to significant confusion in electronic health record systems, potentially affecting diagnosis tracking, treatment history, and legal compliance regarding patient privacy.
The impact extends beyond simple data corruption; it undermines the fundamental trust required for medical software integrity. Clinicians rely on these records for critical decision-making, and unauthorized alterations could introduce false information into a patient's file or erase legitimate historical data. Furthermore, this vulnerability aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it exploits existing credentials to perform actions outside their intended scope, specifically relating to lateral movement within the application’s logical boundaries rather than network traversal. It also reflects CWE-639, Authorization Bypass Through User-Controlled Key, where the attacker controls a key (the sid) that is used for authorization decisions without sufficient verification against other contextual parameters like pid and eid.
Mitigation strategies must focus on implementing robust server-side validation checks before processing any update requests. Developers should ensure that every API endpoint performing write operations verifies that all provided identifiers correspond to resources owned by or explicitly accessible to the authenticated user session. This involves querying the database to confirm that the soap_note with the given sid is indeed linked to the specified pid and eid in the request path. Additionally, implementing strict input validation and utilizing parameterized queries can help prevent related injection issues. Upgrading to OpenEMR version 8.3.0 or later resolves this issue as it includes patches for these authorization checks. Until an upgrade is performed, administrators should restrict API access through network-level controls such as firewalls or reverse proxies that limit exposure of the SOAP endpoint to trusted internal networks only, thereby reducing the attack surface available to potential adversaries.