CVE-2026-124483: OpenEMR before 8.4.0 Improper Authorization via Prescription REST API

Published Nov 8, 2026

Updated

OpenEMR before 8.4.0 contains an incorrect authorization vulnerability because the prescription REST API routes check the patients.med ACL instead of patients.rx and request no specific permission bit, so read-only Medical/History access passes the check. Authenticated staff users can reuse the UI-exposed APICSRFTOKEN to enumerate prescription UUIDs, forge prescriptions for arbitrary patients, and deactivate existing prescriptions tenant-wide.

Event History

Nov 8, 2026

CVE Published

via MITRE·01:16 PM

Data Sourced

via MITRE·01:16 PM

DescriptionSeverityWeakness

Data Sourced

via NVD·02:18 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which users are realistically able to exploit this issue?

Authenticated staff users with read-only Medical/History access can pass the affected authorization check. They can use an APICSRFTOKEN exposed by the UI to access the prescription REST API.

What access and information does an attacker need?

The attacker needs an authenticated staff account with the affected read-only Medical/History access and a UI-exposed APICSRFTOKEN. They also need to enumerate prescription UUIDs to target prescription records.

What could an attacker do after exploiting the issue?

An attacker can forge prescriptions for arbitrary patients and deactivate existing prescriptions across the tenant. They can also enumerate prescription UUIDs.

How can an organization determine whether it is affected?

OpenEMR versions before 8.4.0 are affected. Exposure exists where staff accounts have read-only Medical/History access and can obtain the UI-exposed APICSRFTOKEN.

CVE-2026-124483: OpenEMR before 8.4.0 Improper Authorization via Prescription REST API

Event History

Frequently Asked Questions

Which users are realistically able to exploit this issue?

What access and information does an attacker need?

What could an attacker do after exploiting the issue?

How can an organization determine whether it is affected?

Company

Resources

Contact

Frequently Asked Questions

Which users are realistically able to exploit this issue?

What access and information does an attacker need?

What could an attacker do after exploiting the issue?

How can an organization determine whether it is affected?