CVE-2026-33305
Authorization Bypass in OpenEMR FaxSMS Module Exposes PHI
Publication date: 2026-03-19
Last updated on: 2026-03-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| open-emr | openemr | to 8.0.0.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-696 | The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways that may produce resultant weaknesses. |
| CWE-862 | The product does not perform an authorization check when an actor attempts to access a resource or perform an action. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33305 is an authorization bypass vulnerability in the optional FaxSMS module of OpenEMR versions prior to 8.0.0.2.
The issue occurs because the AppDispatch constructor in the FaxSMS module immediately dispatches user-controlled actions without enforcing Access Control List (ACL) checks first.
This means any authenticated OpenEMR user can invoke sensitive controller methods, such as getNotificationLog(), which returns patient appointment data containing Protected Health Information (PHI), regardless of their permissions.
The vulnerability arises because the constructor calls dispatchActions(), then render(), and exits the process before any ACL checks can be enforced by the calling code.
The issue was fixed in version 8.0.0.2 by adding an ACL verification call early in the constructor to deny unauthorized access before any actions are dispatched.
How can this vulnerability impact me? :
This vulnerability allows any authenticated OpenEMR user to bypass authorization controls in the FaxSMS module.
An attacker can invoke sensitive methods like getNotificationLog() to access patient Protected Health Information (PHI), including patient IDs, appointment timestamps, patient names, and notification messages.
Additionally, methods like saveSetup() can be exploited to overwrite module API credentials, potentially compromising module integrity.
The impact is a moderate severity authorization bypass and privilege escalation with a CVSS v3 base score of 5.4.
The attack requires only low privileges (any authenticated user), low complexity, no user interaction, and is network-based.
This can lead to unauthorized disclosure of sensitive patient data and unauthorized modification of module credentials.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': "This vulnerability can be detected by checking if the OpenEMR FaxSMS module is enabled and if the system is running a version prior to 8.0.0.2. Specifically, an authenticated user without proper ACL permissions can send a direct GET request with the parameter _ACTION_COMMAND=getNotificationLog to the FaxSMS module's controller endpoint. If the system returns patient appointment notification data (PHI) despite insufficient privileges, the vulnerability is present."}, {'type': 'paragraph', 'content': 'A suggested command to test this would be to authenticate as a normal OpenEMR user and then send a GET request like the following to the FaxSMS module controller URL:'}, {'type': 'list_item', 'content': "curl -b cookies.txt 'https://<openemr-server>/interface/modules/custom_modules/oe-module-faxsms/src/Controller/AppDispatch.php?_ACTION_COMMAND=getNotificationLog'"}, {'type': 'paragraph', 'content': 'If the response contains patient appointment data or other sensitive information without proper authorization, the system is vulnerable.'}] [2]
What immediate steps should I take to mitigate this vulnerability?
[{'type': 'paragraph', 'content': "The immediate mitigation step is to update OpenEMR to version 8.0.0.2 or later, where the FaxSMS module's AppDispatch constructor enforces Access Control List (ACL) verification before dispatching any user-controlled actions."}, {'type': 'paragraph', 'content': 'If updating immediately is not possible, restrict access to the FaxSMS module by disabling it or limiting authenticated user permissions to prevent unauthorized invocation of controller methods.'}, {'type': 'paragraph', 'content': 'Additionally, monitor and audit access logs for any suspicious requests to the FaxSMS module endpoints, especially those containing the _ACTION_COMMAND parameter.'}] [2, 1]