Simecek

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0.2 **Description** OpenEMR is an electronic health records and medical practice management application. The encounter vitals API endpoint, `/encounter/vitals`, accepts an `id` parameter in the request body. Prior to version 8.0.0.2, the application does not verify if the vital sign data associated with the provided `id` belongs to the current patient or encounter. This allows an authenticated user with encounters/notes permission to potentially overwrite any patient's vitals by supplying another patient's vital `id`, leading to medical record tampering. **Recommendations** Update to version 8.0.0.2 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0.2 **Description** OpenEMR is a free and open source electronic health records and medical practice management application. A stored cross-site scripting (XSS) issue exists in the patient portal payment flow. This allows a patient portal user to inject arbitrary JavaScript code that will be executed in the browser of a staff member reviewing the payment submission. The malicious payload is stored in `portal/lib/paylib.php` and rendered without proper sanitization in `portal/portal payment.php`. **Recommendations** Update OpenEMR to version 8.0.0.2 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0.2 **Description** OpenEMR is an electronic health records and medical practice management application. A flaw exists where an authorization bypass in the optional FaxSMS module (`oe-module-faxsms`) allows authenticated users to invoke controller methods, including `getNotificationLog()`, without proper access control checks. The `AppDispatch` constructor bypasses ACL enforcement, potentially exposing patient appointment data (PHI). **Recommendations** Update to OpenEMR version 8.0.0.2 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0.2 **Description** OpenEMR is an electronic health records and medical practice management application. A flaw exists where an authenticated, non-administrator user can view reminder messages belonging to other users. This is achieved by manipulating the `sentTo[]` or `sentBy[]` parameters in a GET request to the dated reminders log. The issue allows access to patient names and the content of free-text messages. **Recommendations** Update to OpenEMR version 8.0.0.2 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0.2 **Description** OpenEMR is a free and open source electronic health records and medical practice management application. The application is susceptible to a stored cross-site scripting (XSS) issue. This occurs due to unescaped `portal login username` within the portal credential print view. A patient portal user can inject an XSS payload as their login username, which then executes in a clinic staff member's browser when the "Create Portal Login" page is accessed for that patient. This allows for a transition from the patient session context to the staff/admin session context. **Recommendations** Versions prior to 8.0.0.2 should be updated to version 8.0.0.2 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0.2 **Description** OpenEMR is an electronic health records and medical practice management application. A flaw exists in the module Access Control List (ACL) function `AclMain::zhAclCheck()`. The function only verifies the existence of "allow" permissions for users or groups, neglecting to check for explicit "deny" permissions. This allows administrators to be unable to revoke access by setting a user or group to "deny"; if the user is in a group that has "allow," access is granted regardless of explicit denies. **Recommendations** Update to version 8.0.0.2 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0.2 **Description** OpenEMR is an electronic health records and medical practice management application. The DICOM zip/export feature does not properly sanitize user-supplied paths when creating zip files. This allows an attacker with DICOM upload/export permission to write files outside the intended directory, potentially including the web root. Successful exploitation could lead to arbitrary file write and potentially remote code execution if PHP or other executable files are written. The issue involves the use of a user-supplied destination or path component without sanitizing path traversal sequences, such as `../`. **Recommendations** Update to OpenEMR version 8.0.0.2 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions up to and including 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. In versions up to and including 8.0.0, the message/note update endpoint does not verify that the message belongs to the current patient or that the user is authorized to edit the patient’s notes. An authenticated user with notes permission can modify any patient’s messages by providing another message ID. The vulnerable endpoint is a PUT or POST request to the message/note update endpoint. The vulnerable parameter is the message/note ID. Commit 92a2ff9eaaa80674b3a934a6556e35e7aded5a41 contains a fix for the issue. **Recommendations** Update to a version later than 8.0.0.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. A flaw in the MedEx callback endpoint allows unauthenticated access to the practice's MedEx API tokens. This can lead to compromise of third-party services, unauthorized access to Protected Health Information (PHI), and potential HIPAA violations. The issue occurs because the endpoint bypasses authentication and performs a MedEx login when `$ POST['callback key']` is provided, returning a JSON response that includes sensitive API tokens. The vulnerable endpoint is '/MedEx/callback'. The vulnerable parameter is `callback key`. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. Prior to version 8.0.0, the patient ID used in `portal/portal payment.php` is obtained from the request (`$pid = $ REQUEST['pid'] ?? $pid` and `$pid = ($ REQUEST['hidden patient code'] ?? null) > 0 ? $ REQUEST['hidden patient code'] : $pid`) instead of being fixed to the authenticated portal user. This allows a portal user to view and interact with another patient's demographics, invoices, and payment history, resulting in horizontal privilege escalation and IDOR (Insecure Direct Object Reference). The vulnerable parameter is `pid` and `hidden patient code`. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions up to and including 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. A flaw in the fax sending functionality allows any authenticated user to read and transmit any file on the server to a phone number controlled by an attacker. This is possible because the endpoint accepts arbitrary file paths from user input and streams them to the fax gateway without proper restrictions or authorization. The vulnerable endpoint is the fax sending endpoint. The issue allows access to files such as database credentials, patient documents, system files, and source code. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions up to and including 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. Versions up to 8.0.0 do not verify that a form belongs to the current user’s patient or encounter context when loading data via the `form id` parameter in the eye exam (eye mag) view. This allows an authenticated user to access or edit any patient’s eye exam by providing another form ID, and potentially switch the session’s active patient in some flows. **Recommendations** Update to a version with the fix available on the `main` branch of the OpenEMR GitHub repository.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. A flaw exists where patient-scoped FHIR tokens can access care team data for all patients instead of being limited to the authenticated patient’s data. This is due to the `FhirCareTeamService` not implementing the `IPatientCompartmentResourceService` interface and failing to pass the patient binding parameter, bypassing patient compartment filtering. This could result in unauthorized disclosure of Protected Health Information (PHI), including patient-provider relationships and care team structures. The vulnerable endpoint is the FHIR CareTeam resource endpoint. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. Versions prior to 8.0.0 do not properly verify user authorization when accessing Layout-Based Form (LBF) printable views. Specifically, the application accepts `formid` and `visitid` (or `patientid`) from requests without confirming the form belongs to the currently authenticated user’s authorized patient or encounter. This allows an authenticated user with LBF access to enumerate form IDs and potentially view or print encounter forms for any patient. The application uses the `formid` and `visitid` (or `patientid`) parameters in the request to access the forms. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. Before version 8.0.0, the `patient picture` context in the document controller did not verify user authorization when serving patient photos by document ID or patient ID. This allowed an authenticated user with document access control to retrieve photos of other patients by supplying their ID. The vulnerable component is the document controller’s `patient picture` context. The affected parameter is the patient ID. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. Versions prior to 8.0.0 have an issue where the DICOM viewer state API does not verify if a document belongs to the current user’s authorized patient or encounter when accepting a document ID (`doc id`). This allows an authenticated user to read or modify DICOM viewer state, such as annotations and view settings, for any document by enumerating document IDs. The API endpoints affected include those for uploading or saving/loading DICOM viewer state. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. A flaw exists in the Immunization module where user-supplied `patient id` values are directly incorporated into SQL queries without proper sanitization. This allows any authenticated user to execute arbitrary SQL queries, potentially leading to database compromise, unauthorized access to protected health information (PHI), credential theft, and remote code execution. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. Prior to version 8.0.0, the session expiration check within the `library/auth.inc.php` file could be bypassed. Specifically, when the `skip timeout reset` parameter is set to '1' in a request, the session expiration check, including the call to the `SessionTracker::isSessionExpired()` function, is skipped. This allows expired sessions to remain active, potentially enabling an attacker with a stolen session cookie to maintain access indefinitely by continuously including the `skip timeout reset=1` parameter in their requests. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. Prior to version 8.0.0, the Message Center does not verify administrator privileges when handling the `show all=yes` URL parameter passed to the `getPnotesByUser()` function. This allows any authenticated user to view all internal messages by requesting the `/messages.php?show all=yes` API endpoint. The "Show All" link is visible to non-administrator users, enabling unauthorized access to internal messages. **Recommendations** Update to version 8.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEMR versions prior to 8.0.0 **Description** OpenEMR is an electronic health records and medical practice management application. Prior to version 8.0.0, the REST API route table in `apis/routes/ rest routes standard.inc.php` does not call `RestConfig::request authorization check()` for document and insurance routes. This allows any valid API bearer token to access or modify patient documents and insurance data, regardless of assigned permissions, potentially exposing Protected Health Information (PHI). The vulnerable routes do not perform appropriate access control verification. The `RestConfig::request authorization check()` function is not invoked for specific API endpoints. **Recommendations** Versions prior to 8.0.0 should be updated to version 8.0.0 or later.