Philipphil

An SQL injection issue exists in the `base-user.cte.utils.ts` file. The software concatenates email addresses of base members directly into the SQL text of queries used to resolve user, created-by, or last-modified-by fields. A registered user can exploit this by setting an email address with a quoted local part containing a single quote, allowing the execution of arbitrary SQL. This can lead to the exposure of user records, API tokens, and data-source credentials.

A stored cross-site scripting issue exists where portal patients can execute JavaScript within staff sessions. This occurs by injecting `javascript:` URLs into `template data`. An attacker can submit an `encounterForm` value that is rendered without sanitization into an iframe `src` by the `DocumentTemplateRender()` function. This allows the script to access Protected Health Information (PHI) and CSRF tokens, and to make calls to staff or admin endpoints.

An authorization flaw exists in the 'diagnosis full.php' endpoint. Authenticated users can manipulate the `id` parameter to delete or clear billing records belonging to other patients, leading to the deactivation of charges and corruption of financial data.

Lack of rate limiting or lockout mechanisms during Time-based One-Time Password (TOTP) submission allows an attacker who possesses a valid password to brute-force the 6-digit multi-factor authentication (MFA) code. This can be achieved by scripting repeated POST requests to the 'main screen.php' endpoint or through the OAuth2 authorization flow by re-submitting hidden credentials to bypass two-factor authentication.

The Carecoordination module contains an insecure direct object reference (IDOR) issue. This allows authenticated users with `send to hie` permission to access CCDA, CCR, or QRDA documents of any patient. By providing arbitrary document or patient IDs, an attacker can download, transmit, or export patient health records, inject falsified clinical data, and delete audit records.

Authenticated report users can manipulate database queries by providing a specially crafted value to the `form facility` variable at the 'interface/reports/ippf statistics.php' endpoint. This allows attackers to bypass the string literal in the `facility id` WHERE clause and employ boolean or time-based payloads to extract sensitive information from the database.

An authorization bypass exists in the `allowFrom` feature, which binds to mutable display names. This allows attackers with lower-trust access to perform actions that require stronger authorization by exploiting the way the feature handles these mutable names.