Pavelkohout396

A SQL injection issue exists in the Mautic administration interface at the '/s/ajax' endpoint. The problem occurs because a request parameter used to select the contact field for searching is not properly validated before being included in a database query. Any authenticated user, regardless of their assigned role or permissions, can exploit this using blind techniques—such as boolean-based or time-based methods—to execute arbitrary SQL queries. This allows the attacker to read sensitive information from the database, including user accounts, email addresses, password hashes, contact data, and campaign content.

An SQL Injection issue exists in the dashboard widget data API endpoint '/api/data/{type}'. This occurs because chart filter parameters provided by the client are not properly validated before being used in database queries that generate dashboard chart data. An authenticated user with API access can use blind SQL injection—a technique used to retrieve data from a database by asking true/false questions—to read arbitrary information from the database, including contact details, marketing data, and user account password hashes. Additionally, the injected SQL can be used to slow down queries, potentially impacting availability. Data modification is not possible, and exploitation requires the Mautic API to be enabled.

A path traversal issue exists in the Mautic Asset API. An authenticated API user with permissions to create assets can specify a file path that is not restricted to the asset upload directory. This allows the registration of any file readable by the web server process as a Mautic asset. Once published, the public download URL serves the file contents without authentication, enabling the retrieval of arbitrary server files, such as system files and configuration files containing secret keys, database passwords, and SMTP credentials.

An issue exists in the public Shop API where queries for products, collections, and facets combine mandatory visibility guards with caller-supplied filters using a caller-controlled `filterOperator`. When the `filterOperator` is set to OR, the visibility guards for `Product.enabled`, `Collection.isPrivate`, and `Facet.isPrivate` can be bypassed. This allows an unauthenticated caller to retrieve disabled products and private collections or facets by providing a predicate that matches those hidden entities.

An authorization bypass exists in the Livewire importer component (`AppLivewireImporter`), mounted at the `imports.index` route. The component verifies the general `import` permission only during the mount phase, while the `files()` and `activeFile()` computed properties query the imports table without restricting results by owner or company. Consequently, any authenticated non-superuser with import permissions can view all import records on the instance, including original filenames, file paths, file sizes, import types, and creation timestamps. Additionally, an attacker can use the `selectFile($id)` Livewire action with an auto-incrementing Import ID to access another user's record, exposing preview data such as the `header row` and `first row` of the CSV. This can lead to the disclosure of sensitive information, such as personal data, asset serial numbers, and license keys, and can cross company or tenant boundaries in Full Multiple Companies Support (FMCS) deployments. The impact is limited to preview data and does not affect superusers.

Insufficient access control allows authenticated users with `assets.edit`, `assets.checkin`, `assets.checkout`, or `assets.audit` permissions to read plaintext encrypted custom field values. This occurs when opening asset forms for listbox, textarea, markdown-textarea, and date/datetime picker elements, effectively bypassing the `assets.view.encrypted custom fields` permission check.

Authenticated users with only `licenses.view` permission can access product keys because the software fails to properly enforce the `viewKeys` authorization gate. This allows attackers to download all license keys in bulk via CSV export or validate candidate keys through API response discrepancies. The issue affects the CSV export and API index endpoints.

An authorization failure exists in the 'POST /hardware/history' endpoint, which allows any authenticated user to reassign arbitrary assets and modify audit logs. By submitting a CSV file, an attacker can reassign assets across different companies and inject fraudulent audit trail entries, compromising inventory integrity and accountability.

A stored cross-site scripting issue exists where the `convertOldInternalLinks()` function in `FaqHelper` calls `html entity decode()` on sanitized FAQ content. This process reverses the entity-encoding protection, allowing authenticated users with FAQ editing privileges to inject JavaScript payloads. These payloads execute in the browsers of all users who view the affected FAQ pages.

An authorization bypass exists in the question creation process. The `isAddingQuestionsAllowed()` function grants access to all users when the `main.enableAskQuestions` setting is active, failing to respect the `records.allowQuestionsForGuests` configuration. This allows unauthenticated users to submit questions through the 'question/create' API endpoint, bypassing guest restrictions to inject spam into the administrative moderation queue.

An authentication bypass exists in the `AuthLdap::create()` function. When LDAP authentication is enabled, a successful LDAP bind triggers the `User::setStatus('active')` function unconditionally. This action overwrites the `account status` column of an existing local account, changing it from 'blocked' to 'active'. Consequently, users with administratively blocked local accounts can restore access and log in via LDAP. This state transition is not recorded in logs, preventing administrators from detecting the override.

A two-factor authentication (2FA) bypass exists because remember-me tokens are issued before the 2FA verification process is completed. An attacker possessing valid credentials can obtain a remember-me cookie to skip the 2FA challenge and replay that cookie to gain full authenticated access to the system without providing the second-factor verification.

A stored Cross-Site Scripting (XSS) issue exists in the project selector component. The application fails to sanitize project names returned via AJAX before injecting them into the Document Object Model (DOM) as option fields. An authenticated user with project creation permissions can store a malicious script payload in a project name. When an administrative user opens an entity editor containing the project selector, the script executes in their browser session, potentially leading to session hijacking, unauthorized state coordination, or unauthorized access to organizational data.

An authorization bypass exists in the API v2 endpoints (utilizing API Platform). Roles configured with owner-scope restrictions, such as `viewown` or `editown`, are not properly enforced. This allows authenticated API users with low privileges to bypass ownership-logic controls to access or modify resources belonging to other users, including reports, contacts, and companies, thereby bypassing structural tenant and privilege boundaries.

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.

OpenEMR is an electronic health records and medical practice management application. A DOM-based stored cross-site scripting issue exists in the jQuery SearchHighlight plugin (`library/js/SearchHighlight.js`). An authenticated user with encounter form write access can inject arbitrary JavaScript that executes in another clinician's browser session when using the search/find feature on the Custom Report page. The plugin reverses server-side HTML entity encoding by reading decoded text from DOM text nodes, concatenating it into a raw HTML string, and passing it to jQuery's `$()` constructor for HTML parsing.

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`.

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).

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.

OpenEMR is an electronic health records and medical practice management application. Prior to version 8.0.0.1, sensitivity checks for group encounters were not functioning correctly. The code was only checking the `form encounter` table for sensitivity information, while group encounters actually store this information in the `form groups encounter` table. This resulted in sensitivity restrictions not being applied to group encounters, potentially allowing unauthorized users to view sensitive information, such as mental health records.