Matte1782

Failure to validate the audience claim of GCE instance-identity JWTs (JSON Web Tokens) at the 'POST /api/v2/workspaceagents/google-instance-identity' endpoint allows an attacker to replay an unexpired `format=full` identity token minted for a different relying party. This can lead to the unauthorized acquisition of a workspace agent session token, which remains valid until the next build of the workspace.

An issue exists where the system looks up runs using only the `friendlyId` in the 'api.v1.runs.$runParam.replay' endpoint without restricting the search to the caller's runtime environment. This allows an attacker with a valid API key from any tenant who knows a victim's `friendlyId` to replay that run into their own environment and access the victim's task payload.

Traefik's BasicAuth, DigestAuth, and ForwardAuth middlewares fail to account for underscore-variant header names when stripping spoofed identity headers. While canonical-cased headers are removed before Traefik writes its own values, underscore variants may be ignored. Because many backends normalize underscore-variant headers identically to dashed forms, an attacker can inject such headers to bypass stripping. This allows the injection of unauthorized identity or authorization context that reaches the backend, potentially via the `authResponseHeaders` path in ForwardAuth.

When operating in HTTP mode with `--lockdown-mode` enabled, the `RepoAccessCache` is implemented as a process-global singleton. This singleton is initialized using the GraphQL client of the first authenticated user, and subsequent requests from different users continue to use this same instance. Consequently, lockdown-related GraphQL queries are executed using the credentials of the first user rather than the current requester's token. This issue affects the `GetInstance()` function in `pkg/lockdown/lockdown.go`, which fails to update the internal client when called by different users. This leads to incorrect results in the `IsSafeContent()` function, which relies on `queryRepoAccessInfo` to determine if content from external contributors should be trusted or sanitized. Potential impacts include incorrect repository visibility checks, unauthorized access to cached data based on the first user's permissions, and a total failure of lockdown protection if the first user's token expires.

An issue exists where the ` process picture url()` function in `backend/open webui/utils/oauth.py` performs URL validation only on the initial URL. Subsequently, it uses `aiohttp.ClientSession.get()` without setting `allow redirects=False` or utilizing the `AIOHTTP CLIENT ALLOW REDIRECTS` environment constant. Because the default behavior of aiohttp allows up to 10 redirects, an attacker with a valid OAuth Identity Provider identity can provide a public URL that redirects to an internal address. This allows the attacker to read the internal response body through their own `profile image url` field, leading to Server-Side Request Forgery (SSRF), a condition where a server is tricked into making unintended requests to internal or external resources.

A stored cross-site scripting issue exists in the OAuth authentication flow. The system infers the MIME type of the picture claim URL from the file extension instead of the Content-Type header, which allows SVG files to bypass the profile image validator and be stored as data URIs. When authenticated users access the profile image endpoint, they receive attacker-controlled SVG content. Due to the lack of default security headers and the use of inline disposition, scripts can be executed within the same origin, potentially leading to the theft of authentication tokens and account takeover.

The 'subscriptions.create' API endpoint in 'server/routes/api/subscriptions/subscriptions.ts' contains a broken authorization pattern. When both `collectionId` and `documentId` are provided in a request, the system only validates authorization for the collection branch. However, the `subscriptionCreator()` function in 'server/commands/subscriptionCreator.ts' creates the subscription using the `documentId`, which remains unvalidated. Because the schema in 'server/routes/api/subscriptions/schema.ts' allows both parameters to be sent simultaneously, an attacker can create a subscription to a document they do not have read access to on any team within the instance.

The MCP Registry contains a Server-Side Request Forgery (SSRF) issue in its HTTP-based namespace verification process. The system uses a function called `safeDialContext` to prevent connections to private or internal addresses when fetching public-key files from domains provided by publishers. However, the blocklist used by the `isBlockedIP()` function fails to cover several IPv6 prefix families, including IPv6 6to4 (`2002::/16`), NAT64 (`64:ff9b::/96` and `64:ff9b:1::/48`), and deprecated site-local (`fec0::/10`) addresses. These prefixes can encode arbitrary IPv4 addresses, allowing them to tunnel to internal RFC1918 or cloud-metadata services on dual-stack or NAT64-enabled hosts. This issue affects the unauthenticated endpoints "/v0/auth/http" and "/v0.1/auth/http". An attacker can trigger the vulnerability by providing a malicious domain via the `domain` parameter in the request body. Because the dial occurs before signature verification, no credentials are required to exploit this flaw. This can allow an unauthenticated attacker to reach internal services, such as cloud metadata services, Kubernetes API servers, or internal admin panels, and use the server as a blind-SSRF oracle to probe for internal services.