CVE-2026-34055: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-34055 is an Insecure Direct Object Reference (IDOR) vulnerability in OpenEMR's patient notes web UI that allows authenticated low-privileged users to read, modify, or delete patient notes belonging to any patient in the system. The flaw exists in all OpenEMR versions prior to 8.0.0.3 and was disclosed on March 25–26, 2026. It is classified as the same vulnerability class as CVE-2026-25745, which affected the REST API, but this instance targets web UI code paths. The CVSS v3.1 base score is 8.1 (High) per the GitHub Security Advisory, reflecting high confidentiality and integrity impact (GitHub Advisory, Feedly).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): functions in library/pnotes.inc.php — including updatePnote(), updatePnoteMessageStatus(), disappearPnote(), reappearPnote(), deletePnote(), and authorizePnote() — execute SQL WHERE id = ? queries using attacker-supplied note IDs without verifying that the note belongs to a patient the authenticated user is authorized to access. Multiple web UI callers in interface/patient_file/summary/pnotes_full.php, pnotes_full_add.php, pnotes_fragment.php, and interface/main/messages/messages.php pass user-controlled note IDs (from POST/GET parameters) directly to these functions. For example, pnotes_fragment.php passes $_GET['docUpdateId'] directly to disappearPnote(), and messages.php omits the checkPnotesNoteId() call for save, savePatient, and delete tasks that other tasks correctly implement (GitHub Advisory, Patch Commit).

An authenticated attacker with patients/notes ACL permission can read, modify, or delete patient notes belonging to any patient in the OpenEMR system — not just those they are authorized to access. This results in unauthorized disclosure of sensitive protected health information (PHI), unauthorized modification or deletion of medical records, and the ability to mark notes as done/inactive for arbitrary patients. Given that OpenEMR is used by healthcare providers managing sensitive medical data, exploitation could have serious regulatory (HIPAA) and patient safety implications (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time. The vulnerability requires a valid authenticated session with low-level privileges (patients/notes ACL), but no user interaction or elevated permissions beyond that. The EPSS score is approximately 0.027%, indicating a low current probability of exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Feedly, GitHub Advisory).

1. Reconnaissance: Identify an internet-facing or network-accessible OpenEMR instance running a version prior to 8.0.0.3. Confirm the version via the login page or /admin.php.
2. Obtain low-privilege credentials: Authenticate to OpenEMR with any account that has patients/notes ACL permission (e.g., a standard clinical staff account).
3. Enumerate note IDs: Access the patient notes UI for a patient you are authorized to view. Observe the note IDs (integers) used in form submissions or GET parameters (e.g., noteid, docUpdateId, delete_id[]).
4. Craft malicious request: Modify the note ID parameter to reference a note belonging to a different patient. For example, send a GET request to interface/patient_file/summary/pnotes_fragment.php?docUpdateId=<target_note_id> to mark another patient's note as inactive, or submit a POST to pnotes_full.php with a manipulated noteid to read or update the note content.
5. Achieve unauthorized access: The server processes the request without verifying patient ownership, allowing the attacker to read, modify, delete, or change the status of notes belonging to any patient in the system (GitHub Advisory, Patch Commit).

• Network: HTTP GET requests to interface/patient_file/summary/pnotes_fragment.php with docUpdateId values that do not correspond to notes for the currently active patient context; POST requests to pnotes_full.php or pnotes_full_add.php with noteid values inconsistent with the patient being viewed.
• Logs: OpenEMR access logs showing a single authenticated user accessing or modifying notes across many different patient IDs in a short time window; repeated requests to note-related endpoints with sequentially or randomly varying note ID values.
• Application Behavior: Patient notes being unexpectedly marked as done/inactive, modified, or deleted without corresponding clinical activity; audit log entries in OpenEMR showing delete events (pnotes: id <X>) for notes not associated with the user's assigned patients.
• Database: Unexpected UPDATE or soft-delete activity in the pnotes table (activity=0, message_status='Done') for records belonging to patients not in the user's care team (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0.3 or later, which patches this vulnerability by adding patient ownership checks ($pid parameter) to all affected functions in library/pnotes.inc.php and adding checkPnotesNoteId() calls in messages.php for save, savePatient, and delete operations (GitHub Release, Patch Commit). Until patching is complete, implement strict network access controls to limit who can authenticate to OpenEMR, and monitor access logs for suspicious cross-patient note access patterns. There is no known configuration-only workaround that fully mitigates the vulnerability without applying the patch (Feedly).

The vulnerability was reported by researcher "simecek" and published via GitHub's security advisory program on March 25, 2026. A blog post on Aisle's website noted the discovery of 38 critical security vulnerabilities in healthcare software used by 100,000 providers, which appears to include this and related OpenEMR issues (Aisle Blog). The vulnerability was also noted on Mastodon by The Hacker Wire shortly after disclosure. Community reaction has focused on the sensitivity of the affected data (PHI in healthcare records) and the ease of exploitation given only low-level credentials are required.