CVE-2026-102940
9.6 CRITICALpublic exploit availablePublished 2026-11-05 · Updated 2026-11-05
AI risk analysis
- Summary
- OpenEMR's document controller lacks authorization checks before allowing low-privilege users to reassign documents to patients or categories they shouldn't access, enabling data exfiltration via unauthorized document movement followed by legitimate read access.
- Exploitability
- Exploitation requires only a low-privilege authenticated user account and knowledge of valid document IDs; no special tools or conditions beyond standard web access are needed.
- Blast radius
- An attacker could reassign sensitive medical documents to accessible patients/categories, then read them through normal endpoints, leading to unauthorized disclosure of protected health information across patient boundaries.
- Detection
- Monitor for unexpected changes in document ownership (e.g., via audit logs tracking Document::change_patient calls) where the actor lacks permissions on both source and destination patients/categories; no reliable network or host-based indicator is derivable beyond such log anomalies.
- Prioritized remediation
- Upgrade to OpenEMR version 8.4.0 or later, which includes the fix that adds proper authorization verification before document reassignment.
Analysis generated locally by garnet-coder (no data left the box). AI-assisted — verify against primary sources before acting.
NVD description
OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.4.0, controllers/C_Document.class.php write actions, including move_action_process(), do not verify the caller's access to the source document, current patient and category, or destination patient and category before Document::change_patient() performs the mutation. A low-privilege authenticated user can reassign an arbitrary document to a patient or category the user can access and then retrieve it through the normally protected read path. The reassignment occurs before a later list rendering check, so a final HTTP 403 response does not mean the unauthorized write was blocked. This issue is fixed in version 8.4.0.
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Weaknesses
CWE-639
Public exploit & PoC references
- https://github.com/openemr/openemr/commit/312b5d042f7fa49cc78ebed041155fba339a991c
- https://github.com/openemr/openemr/pull/13353
- https://github.com/openemr/openemr/releases/tag/v8_3_0
- https://github.com/openemr/openemr/security/advisories/GHSA-92rh-g949-4mvv
- https://github.com/openemr/openemr/security/advisories/GHSA-92rh-g949-4mvv
All references
- https://github.com/openemr/openemr/commit/312b5d042f7fa49cc78ebed041155fba339a991c
- https://github.com/openemr/openemr/pull/13353
- https://github.com/openemr/openemr/releases/tag/v8_3_0
- https://github.com/openemr/openemr/security/advisories/GHSA-92rh-g949-4mvv
- https://github.com/openemr/openemr/security/advisories/GHSA-92rh-g949-4mvv
Source data: NVD (nvd.nist.gov), public domain. Exploit-DB.ai adds local AI analysis for defensive use only.
Related CVEs
- HIGHCVE-2026-61726PoC
- HIGHCVE-2026-112242
- HIGHCVE-2026-112351
- HIGHCVE-2026-116199PoC
- HIGHCVE-2026-116682PoC
- HIGHCVE-2026-121429PoC
- CRITICALCVE-2026-61707PoC
- HIGHCVE-2026-77690
Related by shared AI tags and CWE weakness class. Browse the full archive.