| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The WP Remote Users Sync WordPress plugin before 2.2.1 does not have authorisation and CSRF checks in one of its AJAX actions, allowing any authenticated user, such as a subscriber, to delete the WP Remote Users Sync WordPress plugin before 2.2.1's entire activity log. |
| The Advance Guest Post WordPress plugin through 1.9 does not perform any authorization or ownership check when deleting media attachments, relying only on a nonce exposed to every site visitor, allowing unauthenticated users to permanently delete arbitrary Media Library attachments and their files. |
| A missing authorization vulnerability in the ACL API in Synology DiskStation Manager (DSM) before 7.3.2-86009-5 and 7.4.1-90080-1 allows remote authenticated users to read or write specific files. |
| A missing authorization vulnerability in the Promotion API in Synology DiskStation Manager (DSM) before 7.3.2-86009-5 and 7.4.1-90080-1 allows remote authenticated users to write specific files. |
| OpenEMR before 8.5.0 contains a missing authorization vulnerability that allows any authenticated core user to modify arbitrary Patient Flow Board trackers without the patients/appt permission. Attackers can submit a victim tracker_id to patient_tracker_status.php or drug_screen_completed.php to falsify check-in status, rooms, drug-screen completion, and tracker history. |
| Frappe HRMS 16.0.0 before 16.50.0 lacks authorization checks on certain HR workflow endpoints, letting authenticated users access records they are not permitted to view. Any logged-in user, including one with only the Employee role, can read candidate record details and employee email addresses, and cause emails to be sent to employees. |
| OpenEMR before 8.5.0 contains a missing authorization vulnerability in dynamic_finder_ajax.php that allows authenticated users without patients/demo permission to query patient demographics. Attackers can supply arbitrary patient_data columns via the sColumns parameter to enumerate names, dates of birth, contact details, and Social Security numbers across the practice. |
| OpenEMR before 8.5.0 contains a missing authorization vulnerability in ccdaservice/ccda_gateway.php that fails to enforce the patients/pat_rep permission, accepting any authenticated core session. Authenticated users without patient-report permission can request the report_ccd_view action to retrieve the selected patient's C-CDA clinical summary, including diagnoses, medications, laboratory results, and identifiers. |
| OpenEMR before 8.5.0 contains an authorization bypass vulnerability that allows OAuth2 clients to use unregistered grant types because oauth_clients.grant_types is never enforced. Attackers can request tokens with grant_type=password to bypass the user consent screen, and disabled clients can redeem authorization codes using JWT client assertions. |
| In JetBrains Datalore before 2026.2.4 unauthenticated users could execute code via published interactive reports |
| In JetBrains Datalore before 2026.4 code execution was possible in a notebook's computation by view-only collaborators |
| In JetBrains Datalore before 2026.4 improper authorisation on workspace moves allowed view-only collaborators to modify shared content |
| OpenEMR before 8.5.0 contains an improper authorization vulnerability in interface/orders/list_reports.php that allows read-only users to transmit lab orders because the patients/med check ignores write permission. Authenticated attackers can submit form_xmit with arbitrary procedure order IDs to send HL7 orders containing SSNs, insurance, and diagnoses to laboratories and mark them transmitted. |
| OpenEMR before 8.5.0 contains a missing authorization vulnerability in library/ajax/lists_touch.php that allows restricted authenticated users to mark another patient's clinical lists as reviewed. Attackers can submit arbitrary patient_id and type values to falsely record "None known" allergy, medication, or problem lists, misleading clinicians and skewing quality-measure calculations. |
| OpenEMR before 8.5.0 contains a missing authorization vulnerability in the FaxSMS module's utility.php that allows read-only demographics users to create patient charts. Attackers can submit the form_create request with chosen identity fields to create fictitious or duplicate patients with employer, history, and insurance records. |
| OpenEMR before 8.5.0 contains a missing authorization vulnerability in the esign_form_submit handler of library/ESign/Form/Controller.php that verifies only the caller's password, not access to the patient, encounter, or form type. Authenticated core users can supply arbitrary formId, formDir, and encounterId values to sign and lock any patient's clinical form, creating unauthorized approval records and blocking normal editing. |
| OpenEMR before 8.5.0 contains a missing authorization vulnerability in the Patient Validation module that allows any authenticated user to retrieve patient demographic records. Attackers can send direct requests with wildcard mf_lname or empty mf_ parameters to the patientvalidation endpoint to enumerate the entire patient_data table. |
| Frappe HRMS 15.0.0 before 15.64.2 and 16.0.0 before 16.20.0 contains a missing authorization vulnerability in certain record update endpoints that lack an ownership check. Authenticated users with the Employee role can call these endpoints to modify records belonging to other employees, beyond their permitted role. |
| Frappe HRMS 15.x before 15.64.1 and 16.x before 16.19.0 contains a missing authorization vulnerability in an endpoint that returns file information, allowing authenticated users to read details of files attached to records they cannot access. Any logged-in user, including one with only the Employee role, can query it to view attachment details on any document type and confirm record existence. |
| Frappe HRMS 15.0.0 before 15.64.1 and 16.0.0 before 16.19.0 lacks a write permission check on a bulk record processing action, allowing users with only read access to the related setup record to modify data. Authenticated users with the default Employee role can run the action to create and submit records for every covered employee. |
