CVE-2026-27943: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-27943 is an Insecure Direct Object Reference (IDOR) / authorization bypass vulnerability in OpenEMR's eye exam (eye_mag) module that allows authenticated users to access or edit any patient's eye exam records by manipulating the form_id parameter. It affects OpenEMR versions up to and including 8.0.0. The vulnerability was published on February 26, 2026, with a fix available on the main branch of the OpenEMR GitHub repository. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the file interface/forms/eye_mag/view.php reads $id directly from $_REQUEST['id'] (lines 28–29) and queries the database using only forms.form_id = ? in the WHERE clause, with no check that the form belongs to the current user's patient or encounter context. Because pid is also accepted from the request ($_REQUEST['pid']), an attacker can supply an arbitrary form_id to retrieve any patient's Protected Health Information (PHI). In some code flows, the session's active patient (pid) is overwritten with the value from the loaded form, enabling broader cross-patient context switching. The companion report.php path does enforce encounter/pid restrictions, but the view.php path does not (GitHub Advisory, Patch Commit).

A low-privileged authenticated attacker can read or edit eye exam records (PHI) belonging to any patient in the OpenEMR database, constituting a significant patient privacy breach with potential HIPAA implications. In some flows, the attacker's session context may be silently switched to the victim patient, enabling further unauthorized actions across that patient's full encounter history. Availability is not directly impacted, but clinical data integrity is at risk if an attacker edits records. The scope is limited to deployments using the eye_mag form module (GitHub Advisory).

A proof-of-concept is publicly documented in the GitHub Security Advisory, demonstrating exploitation via a simple crafted GET request requiring only a valid authenticated session and knowledge (or enumeration) of a target form_id. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.028% (very low probability of near-term exploitation). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. No threat actor attribution has been reported (GitHub Advisory).

1. Reconnaissance: Identify an OpenEMR instance running version 8.0.0 or earlier with the eye_mag form module enabled. Confirm the target is reachable and that the attacker has a valid low-privilege account (e.g., clinician role with eye exam access).
2. Authentication: Log in to the OpenEMR instance with the attacker-controlled account to obtain a valid session cookie.
3. Enumerate form IDs: Identify or enumerate valid form_id values for eye exam records belonging to other patients. Since IDs are typically sequential integers, an attacker can iterate values (e.g., id=1, id=2, ..., id=555).
4. Send crafted request: Issue a GET request to the vulnerable endpoint with a target form ID:

   GET /interface/forms/eye_mag/view.php?id=555 HTTP/1.1
   Host: target-openemr.com
   Cookie: <valid_session_cookie>

5. Access victim PHI: If the server returns the eye exam data for the specified form_id without a 403 error, the IDOR is confirmed and the attacker can read the victim patient's eye exam PHI.
6. Session hijack (optional): In vulnerable flows, the session's active patient may be switched to the victim patient, enabling the attacker to perform further actions (e.g., viewing other encounter data) under that patient's context (GitHub Advisory).

• Network: Repeated or sequential GET requests to /interface/forms/eye_mag/view.php with varying id parameter values from a single source IP, especially across a short time window.
• Logs: OpenEMR access logs showing requests to view.php?id=<N> where <N> does not correspond to the authenticated user's assigned patients; requests originating from accounts that do not normally access eye exam forms.
• Logs: Unexpected session patient context changes (pid switches) in application logs following access to view.php with an external id parameter.
• Application Behavior: Eye exam records for patients not associated with the logged-in user appearing in audit trails or modification logs.

The fix is available on the main branch of the OpenEMR GitHub repository (commit c87489bf63f2701b634d948279e104f2ed3df1c0); administrators should upgrade to a patched release above 8.0.0 as soon as one is published. The patch adds an IDOR guard in view.php that compares the stored encounter against the session encounter and returns HTTP 404 if they do not match, and ensures pid and encounter are passed explicitly in form URLs rather than relying on session state. As an interim workaround, restrict access to the eye_mag module to only authorized personnel, implement network-level access controls to limit who can reach the OpenEMR interface, and monitor access logs for suspicious sequential form_id enumeration (GitHub Advisory, Patch Commit).

The vulnerability was reported by security researchers simecek (reporter) and analysts pavelkohout396 and stanislavfortaisle, with remediation development credited to kojiromike, as noted in the GitHub Security Advisory. A blog post from Aisle (the reporting organization) highlighted this as one of 38 critical security vulnerabilities discovered in healthcare software used by 100,000 providers, drawing attention to systemic security issues in OpenEMR (GitHub Advisory). The vulnerability was also tracked by Red Hat's CVE database and the ENISA European Vulnerability Database (EUVD-2026-8812), indicating broad awareness in the security community.