5Ud0Er

OpenPanel fails to enforce read-only project access level on 26 of 29 mutating procedures, allowing read-level members to modify, delete, and publish project data. Attackers with explicit read-only access can delete reports and dashboards, schedule entire projects for deletion, publish private analytics to public share links, and modify alerting rules by exploiting missing access level validation in mutation resolvers.

OpenPanel is an analytics platform. In all versions (no patched release available at time of publication), the data importer fetches a caller-supplied URL with plain fetch instead of the project's existing SSRF guard (apps/api/src/utils/safe-fetch.ts). In packages/importer/src/providers/umami.ts, parseRemoteFile calls fetch() on config.fileUrl, which is validated only by z.string().url(), so values such as http://127.0.0.1:9911/ or http://169.254.169.254/latest/meta-data/ are accepted; the shared createFileImportConfig factory gives the plausible provider the same field. An authenticated organization member — including a default 'member' with no project access rows, for whom the intended access-level check is skipped because getProjectAccess returns boolean true rather than a level object — can therefore make the server connect to any address reachable from it. The resulting HTTP status and status text are persisted as Import.errorMessage and returned by import.get to the same user, providing a scanning oracle for internal hosts, ports and paths; if an internal response parses as Umami CSV, its rows are ingested as events and become readable in the attacker's analytics views.

OpenPanel share lookup procedures fail to validate access controls and return password hashes and protected report definitions to unauthenticated callers. Attackers with a share link can retrieve argon2id password hashes and full report configurations including event names, filters, and breakdown dimensions for offline password cracking and business intelligence theft.

**Name of the Vulnerable Software and Affected Versions** Trilium versions prior to 0.104.0 **Description** 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. **Recommendations** Update to version 0.104.0.

**Name of the Vulnerable Software and Affected Versions** Weblate versions prior to 2026.7 **Description** 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. **Recommendations** Update to version 2026.7.

**Name of the Vulnerable Software and Affected Versions** Astro versions prior to 6.4.6 **Description** 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`. **Recommendations** Update to version 6.4.6 or later.