The Daily Byte
Breaking
Welcome to The Daily Byte — real stories from across Pakistan.
Monday, 9 November 2026 · Pakistan

The Daily Byte

Stories from Pakistan that deserve to be heard

OpenEMR CVE-2026-124488 Lets Staff Read Patient Records

By The Daily Byte ·08 Nov 2026 ·2 min read
A doctor in a white coat with a stethoscope working at a computer in a hospital, holding patient notes

OpenEMR, the open-source electronic health records system used by clinics worldwide, has a flaw that lets a logged-in staff member read and change patient records they are supposed to be locked out of. The vulnerability, tracked as CVE-2026-124488, was published on 8 November 2026 and carries a CVSS score of 8.1 (High), or 8.6 under CVSS version 4.0.

The problem sits in how OpenEMR guards encounters marked high sensitivity. The normal encounter page correctly blocks a clinician who lacks the sensitivities|high permission, showing "Not authorized to view this encounter". But the direct form loader, load_form.php, does not run the same check. A clinician with ordinary form access can request the Clinical Notes or Care Plan loader directly and receive the restricted contents, along with a valid security token, and then submit the normal save handlers to alter those records.

The issue was validated by researchers in a local lab running OpenEMR version 8.0.0.3 in Docker, using synthetic patient records. No public OpenEMR deployments were tested, and no exploitation in the wild has been reported. The flaw is not listed in CISA's Known Exploited Vulnerabilities catalogue. It affects OpenEMR versions before 8.3.0, according to the project's security advisory.

Two related access-control flaws in the patient portal were published the same day: CVE-2026-124485, which lets an authenticated patient read other patients' documents, and CVE-2026-124489, a broken access control in the portal payment page. Both are rated High and also affect versions before 8.3.0.

Clinics running OpenEMR should upgrade to version 8.3.0 or later, which contains the fixes, and review which staff accounts hold the high-sensitivity permission until the upgrade is done. Because the flaw needs a valid staff login, limiting backend accounts and watching for unusual access to high-sensitivity encounters reduces the risk in the meantime.