5Ud0Er

The profile form exposes the `only assigned tickets` permission to non-administrator owners. The `UsersController::profileSave()` function allows the addition or removal of `User::PERM ONLY ASSIGNED TICKETS` without verifying if the editor has administrator privileges. Consequently, a restricted agent can remove administrator-imposed restrictions by unchecking the option or submitting a profile save that omits it, enabling them to read and modify conversations assigned to other agents within any mailbox they are members of.

A low-privileged authenticated user can exploit the `createOrUpdateUserIntegration` GraphQL mutation in `crates/services/user/src/integration operations.rs` by providing another user's `integrationId` to the `create or update user integration()` function. Due to a missing ownership check, SeaORM uses the provided primary key as an update target, assigning the caller's `user id` and replacing the `provider specifics` and other configurations of the targeted integration. This allows an attacker to transfer ownership, overwrite configurations, or disable a victim's integration, provided they have obtained the victim's non-brute-forceable integration ID. The operation does not disclose existing stored credential values.

An authenticated non-admin agent who is a member of at least one mailbox can exploit a search-by-number shortcut in the `search()` function of `ConversationsController`. By requesting the '/search' endpoint with a hash-prefixed ticket number, the system resolves the user-controlled ticket number without applying the required mailbox filter or view policy. This allows the agent to use the 302 Location header to confirm the existence of a conversation in a mailbox they cannot access and discover its internal conversation and folder identifiers. This issue does not disclose message content, attachments, or customer data.

An issue exists in the otpauth image-fetch path where a hostname is validated using `ValidatesUrls::isExternalHost()` and subsequently resolved again by `IconService::storeRemoteImage()` for the HTTP request. If external otpauth image fetching is enabled, an authenticated user with control over low-TTL authoritative DNS can provide a public address during the validation phase and an internal address during the connection phase. This allows the user to bypass the private-address deny list and access loopback, private-network, link-local, or cloud metadata endpoints.

An issue exists where specific endpoints accept the `scan ports` variable from any authenticated session, including non-administrator users, or without authentication if login is disabled. The endpoints 'scripts/lua/rest/v2/add/host/to scan.lua' and 'scripts/lua/rest/v2/exec/host/schedule vulnerability scan.lua' use a validation function `validateSingleWord()` that permits shell metacharacters. This value is later concatenated into an nmap command via the `nmap scan host()` function and executed through `ntop.execCmd()` or `ntop.execCmdAsync()` using popen. For the tcp portscan and cve modules, a preliminary nmap -sn probe must report the target as up. If nmap is installed, this allows for command injection, enabling arbitrary operating-system commands to execute as the ntopng service account without further user interaction.

The GET '/api/support/v1/manage course team/' endpoint in CourseTeamManageAPIView lacks a global support-role authorization check, requiring only that a user be authenticated. This allows any authenticated learner to provide an email, username, or `user id` to determine if an account is active based on the difference between 200 and 404 responses. Furthermore, users with course-level or organization-level instructor roles can retrieve the staff or instructor assignments of a target user within their specific scope.

Authenticated tenants can escape their object key prefix due to an unsanitized filename splat segment. By supplying `../` sequences to the 'api/v1/packets' and 'api/v2/packets' endpoints, an attacker with a valid API key can obtain presigned GET or PUT URLs to read or overwrite run payloads and outputs belonging to other tenants.

Insufficient access control in the project management tool allows unauthorized retrieval of file assets. The endpoints 'WorkspaceFileAssetEndpoint.get' and 'WorkspaceAssetDownloadEndpoint.get' resolve `FileAsset` records without verifying if the workspace member belongs to the asset's project, enabling the download of assets from private projects if the asset UUID is known. Additionally, the 'EntityAssetEndpoint.get' public-anchor endpoint grants `AllowAny` access and limits lookups to the workspace level rather than the specific published entity or project. This allows unauthenticated users with a valid anchor and asset UUID to retrieve issue-description or comment-description assets from private or unpublished projects within that workspace.

An issue exists where the `get-page` RPC (Remote Procedure Call) accepts a share-link permission object providing broad read access but fails to verify if the requested `page-id` is among the pages authorized by the link. An authenticated attacker possessing a valid share link can retrieve the full shape and design data of other pages within the same file if the page identifier is known. Additionally, the `get-file-fragment` RPC allows share-link access without properly mapping fragments to authorized pages.

Missing access level validation in mutation resolvers allows members with read-only project access to perform unauthorized actions. This issue affects 26 of 29 mutating procedures, enabling users to modify, delete, and publish project data. Specifically, attackers can delete reports and dashboards, schedule entire projects for deletion, publish private analytics to public share links, and modify alerting rules.

Share lookup procedures fail to validate access controls, allowing unauthenticated callers to retrieve protected report definitions and argon2id password hashes. Attackers possessing a share link can obtain full report configurations, including filters, event names, and breakdown dimensions, which may lead to business intelligence theft and offline password cracking.

The data importer fails to use the project's SSRF guard, instead utilizing a plain fetch mechanism to retrieve caller-supplied URLs. In the `parseRemoteFile()` function within `packages/importer/src/providers/umami.ts`, the `config.fileUrl` variable is validated only as a URL string, allowing requests to internal addresses such as `http://127.0.0.1:9911/` or `http://169.254.169.254/latest/meta-data/`. An authenticated organization member can exploit this to force the server to connect to any reachable address. The server then returns the HTTP status and status text via `import.get`, creating a scanning oracle for internal hosts, ports, and paths. Additionally, if an internal response is formatted as a Umami CSV, the data is ingested as events and becomes visible in the attacker's analytics views. SSRF (Server-Side Request Forgery) is a flaw where an attacker forces a server to make requests to an unintended location.

The public share-search endpoint does not enforce `shareCredentials` and `shareHiddenFromTree` controls. The endpoint authorizes only the ancestor note provided in the request and performs a full-text search across the published subtree, returning the title, share identifier, and hierarchical path of matching notes without verifying if the individual note requires a password or is hidden. An unauthenticated visitor can use this endpoint as a boolean oracle—a system that provides a yes/no answer to a query—to confirm arbitrary substrings and recover the full content of protected shared notes.

An authenticated user with project access can retrieve the change history of restricted components through nested API change endpoints. This occurs because these nested endpoints fail to apply the component-level access checks required for direct component views, allowing the enumeration of changes for hidden components. Exposed data may include the identity of the restricted component, translation and unit links, and change payload fields such as source or translated string content within the `target`, `old`, and `details` values.

Authenticated users can perform server-side request forgery (SSRF) by submitting crafted URLs. This issue occurs within the `fetch url()` function of the `ScenarioImport` class, allowing attackers to make arbitrary HTTP requests. This can be used to probe internal network services, enumerate ports through error signatures, and access cloud metadata endpoints to retrieve sensitive credentials.

Astro SSR applications using prerendered error pages, such as '/404' or '/500' with `export const prerender = true`, fetch these pages over HTTP at runtime during an error. The fetch URL is derived from `request.url`, which obtains its origin from the incoming `Host` header. If the `Host` header is not validated against `allowedDomains`, an attacker can manipulate the header to point the fetch toward an arbitrary host and read the response. This occurs specifically in SSR deployments using `createRequestFromNodeRequest` from `astro/app/node` with `app.render()` without overriding `prerenderedErrorPageFetch`.