Dizconnectz

When the `limit user customer visibility` setting is enabled, the `load customer info` AJAX action performs a global lookup using a customer email provided by the user and only verifies if the agent has access to a specified mailbox. This allows a non-admin agent to retrieve the rendered profile of an unrelated customer by specifying a mailbox they can access, bypassing the `CustomerPolicy::view()` check. The exposed data may include names, email addresses, phone numbers, company and job details, postal addresses, social profiles, websites, and confidential internal agent notes.

The login endpoint 'POST /api/token' reads the `email` field from the request body without type validation and passes it directly into a MongoDB storage query. If the `email` field is provided as a non-string type, such as a JSON object, the `parseWhere()` function in the MongoDB storage adapter drops the field, resulting in an empty filter that matches all users. The system then validates the provided password against the first user returned, which is typically the site administrator. This leads to a partial authentication bypass where the email identifier is removed for the administrator account, enabling user enumeration and credential-stuffing amplification, as an attacker can test passwords against the administrator account without knowing their email.

The anonymous `POST /forms/{formId}/submissions` endpoint stores attacker-controlled `JsonData` after verifying only that the JSON is well formed. A file object containing `name`, `type`, and `content` fields can include an HTTP or HTTPS URL. When a staff member with `submissions.view` permission calls the `POST /forms/{formId}/submissions/{submissionId}/files` endpoint, the `GetFilesHandler` passes the stored data to the `SubmissionFileExtractor` function, which uses `HttpClient.GetAsync` without validating the destination URL, host, or resolved IP addresses against internal address ranges. This allows stored, second-order server-side GET requests to internal services, cloud metadata, loopback, and link-local addresses. For this to occur, the form must have `IsPublic` and `IsEnabled` set, and anonymous submissions must pass reCAPTCHA v3 if configured. The response is included in a ZIP file for the staff viewer rather than being returned to the attacker, making disclosure blind or indirect.

Authenticated tenants can exploit a blind server-side request forgery (SSRF) by configuring an unvalidated webhook alert channel URL. The webapp server fails to validate the `url` variable against a host allowlist or private-IP blocklist, allowing the server to send POST requests to internal hosts, cloud metadata addresses, or reach IMDSv1 via redirects. This occurs when the `alertsWorker` uses the `DeliverAlertService` to send HMAC-signed alert payloads via the `fetch()` function. The issue is rooted in the `ApiAlertChannelPresenter.server.ts` file where the URL is accepted without syntax or host validation, and is subsequently processed in `deliverAlert.server.ts` and `deliverErrorGroupAlert.server.ts`.

An issue exists where webhook destinations are validated only during registration and not during use. The `NoInternalUrlRule` function in `backend/app/Validators/Rules/NoInternalUrlRule.php` uses `gethostbyname()` to reject private and reserved IP ranges, but public hostnames are permitted. During dispatch, the `WebhookDispatchService` utilizes the stored URL via `spatie/laravel-webhook-server` without re-validating the destination. Because `backend/config/webhook-server.php` does not configure Guzzle options, redirect following is enabled by default. This allows a destination to redirect the server to a loopback, private, or cloud metadata address, or allows an attacker to change a DNS record after registration to achieve the same result. The `WebhookResponseHandlerService` stores the response body in the webhook log, which is then exposed via the `WebhookLogResource` endpoint, allowing the requester to read responses from internal services. This affects both event and organizer webhooks.

A SQL injection issue exists in the Oracle datasource connector during the post-write row lookup process. The system fails to properly escape table names used in identifiers. An attacker with write permissions on a table containing a double-quote in its name can inject SQL commands. These commands execute with the privileges of the datasource database user, allowing the attacker to read or modify arbitrary data.

The quick setup view, used after the initial creation of an event, fails to properly verify if a user has the necessary permissions to modify the configuration of a specific event. This authorization flaw allows an attacker to send a well-timed request to perform unauthorized actions on events they do not have access to, such as creating products and quotas, configuring bank transfers, or connecting a Stripe account.