Luuhung1217

An authorization flaw exists in the 'library/ajax/upload.php' endpoint. This issue allows any authenticated user to read and overwrite document data by providing an arbitrary `doc id`. Low-privilege users can utilize the fetch and save actions to enumerate `doc id` values, leading to the disclosure of patient health information and the unauthorized modification of medical records for all patients.

An insecure direct object reference exists in the `OnsiteDocumentController::Query()` function. Authenticated portal patients can bypass the authorization guard by providing a capitalized `Pid` parameter. By sending a request to the 'api/onsitedocuments' endpoint with the `Pid` variable set to another patient's identifier, an attacker can overwrite session-pinned criteria to access and read onsite documents containing Protected Health Information (PHI) belonging to other patients.

An issue exists in the 'library/ajax/payment ajax.php' endpoint where the system validates a CSRF token but fails to perform an AclMain authorization check before executing a wildcard search of patient data. This allows any authenticated user, including those with non-clinical roles, to enumerate patient identifiers, full names, and dates of birth through the `set patient` branch.

The `search persons` action in the endpoint 'library/ajax/person search ajax.php' fails to perform an AclMain authorization check, although it validates CSRF (Cross-Site Request Forgery, a type of attack that forces an authenticated user to execute unwanted actions). This allows a low-privilege authenticated user to iterate name prefixes and retrieve sensitive patient information, including first and last names, dates of birth, gender, phone numbers, and email addresses, via JSON responses.

Authenticated back-office staff with content-upload permissions can store executable media on the administrator's origin. In the 2.x implementation, permissions such as `edit products` or `add brands` allow the upload of `image/svg+xml` via `packages/admin/config/media.php`. Additionally, the product files collection in `packages/admin/src/Livewire/Components/Products/Form/Files.php` lacks MIME restrictions and accepts `text/html`. Because media is served inline from the `/storage/` directory without a `Content-Security-Policy` or `Content-Disposition: attachment`, opening these files executes stored scripts in the administrator's session. In 2.x, this can be used to call the `store()` function within `packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php`, which trusts the client-supplied `role id` to create a new administrator account with a chosen password. This allows an attacker to gain full access to customer data, orders, settings, and user management. In 3.x prereleases, while SVG is excluded, executable product files are still permitted.