Matte1782

A falha na validação da reivindicação de audiência de JWTs (JSON Web Tokens) de identidade de instância do GCE no endpoint 'POST /api/v2/workspaceagents/google-instance-identity' permite que um invasor reutilize um token de identidade `format=full` não expirado emitido para outra parte confiante. Isso pode resultar na obtenção não autorizada de um token de sessão do agente do workspace, que permanece válido até a próxima compilação do workspace.

Existe um problema onde o sistema pesquisa execuções utilizando apenas o `friendlyId` no endpoint 'api.v1.runs.$runParam.replay' sem restringir a busca ao ambiente de execução do chamador. Isso permite que um invasor com uma chave de API válida de qualquer locatário que conheça o `friendlyId` de uma vítima execute novamente essa operação em seu próprio ambiente e acesse a carga útil da tarefa da vítima.

Os middlewares BasicAuth, DigestAuth e ForwardAuth do Traefik não consideram nomes de cabeçalhos com variantes de sublinhado (underscore) ao remover cabeçalhos de identidade falsificados. Embora os cabeçalhos com formatação canônica sejam removidos antes que o Traefik escreva seus próprios valores, as variantes com sublinhado podem ser ignoradas. Como muitos backends normalizam cabeçalhos com sublinhado de forma idêntica às formas com hífen, um invasor pode injetar tais cabeçalhos para evitar a remoção. Isso permite a injeção de contexto de identidade ou autorização não autorizado que atinge o backend, potencialmente através do caminho `authResponseHeaders` no ForwardAuth.

Ao operar no modo HTTP com o `--lockdown-mode` ativado, o `RepoAccessCache` é implementado como um singleton global do processo. Este singleton é inicializado usando o cliente GraphQL do primeiro usuário autenticado, e solicitações subsequentes de diferentes usuários continuam a usar a mesma instância. Consequentemente, as consultas GraphQL relacionadas ao lockdown são executadas usando as credenciais do primeiro usuário, em vez do token do solicitante atual. Este problema afeta a função `GetInstance()` em `pkg/lockdown/lockdown.go`, que não atualiza o cliente interno quando chamada por diferentes usuários. Isso leva a resultados incorretos na função `IsSafeContent()`, que depende de `queryRepoAccessInfo` para determinar se o conteúdo de contribuidores externos deve ser confiado ou sanitizado. Os impactos potenciais incluem verificações de visibilidade de repositório incorretas, acesso não autorizado a dados em cache com base nas permissões do primeiro usuário e a falha total da proteção de lockdown se o token do primeiro usuário expirar.

Existe um problema onde a função ` process picture url()` em `backend/open webui/utils/oauth.py` realiza a validação da URL apenas na URL inicial. Posteriormente, ela utiliza `aiohttp.ClientSession.get()` sem definir `allow redirects=False` ou utilizar a constante de ambiente `AIOHTTP CLIENT ALLOW REDIRECTS`. Como o comportamento padrão do aiohttp permite até 10 redirecionamentos, um invasor com uma identidade válida de Provedor de Identidade OAuth pode fornecer uma URL pública que redireciona para um endereço interno. Isso permite que o invasor leia o corpo da resposta interna através do seu próprio campo `profile image url`, levando ao Server-Side Request Forgery (SSRF), uma condição em que um servidor é enganado para fazer requisições não pretendidas a recursos internos ou externos.

Um problema de cross-site scripting armazenado existe no fluxo de autenticação OAuth. O sistema infere o tipo MIME da URL de reivindicação de imagem a partir da extensão do arquivo em vez do cabeçalho Content-Type, o que permite que arquivos SVG ignorem o validador de imagem de perfil e sejam armazenados como URIs de dados. Quando usuários autenticados acessam o endpoint de imagem de perfil, eles recebem conteúdo SVG controlado por um invasor. Devido à ausência de cabeçalhos de segurança padrão e ao uso de disposição inline, scripts podem ser executados na mesma origem, levando potencialmente ao roubo de tokens de autenticação e à invasão de contas.

O endpoint de API 'subscriptions.create' em 'server/routes/api/subscriptions/subscriptions.ts' apresenta um padrão de autorização interrompido. Quando tanto o `collectionId` quanto o `documentId` são fornecidos em uma requisição, o sistema valida a autorização apenas para o ramo da coleção. No entanto, a função `subscriptionCreator()` em 'server/commands/subscriptionCreator.ts' cria a assinatura utilizando o `documentId`, que não foi validado. Como o esquema em 'server/routes/api/subscriptions/schema.ts' permite que ambos os parâmetros sejam enviados simultaneamente, um invasor pode criar uma assinatura para um documento ao qual não possui acesso de leitura em qualquer equipe da instância.

O MCP Registry contém um problema de Server-Side Request Forgery (SSRF) em seu processo de verificação de namespace baseado em HTTP. O sistema utiliza uma função chamada `safeDialContext` para evitar conexões com endereços privados ou internos ao buscar arquivos de chave pública de domínios fornecidos por publicadores. No entanto, a lista de bloqueio utilizada pela função `isBlockedIP()` não abrange várias famílias de prefixos IPv6, incluindo IPv6 6to4 (`2002::/16`), NAT64 (`64:ff9b::/96` e `64:ff9b:1::/48`) e endereços site-local obsoletos (`fec0::/10`). Esses prefixos podem codificar endereços IPv4 arbitrários, permitindo que eles tunelem para serviços internos RFC1918 ou serviços de metadados de nuvem em hosts com dual-stack ou NAT64 habilitado. Este problema afeta os endpoints não autenticados "/v0/auth/http" e "/v0.1/auth/http". Um invasor pode disparar a vulnerabilidade fornecendo um domínio malicioso através do parâmetro `domain` no corpo da requisição. Como a conexão ocorre antes da verificação da assinatura, não são necessárias credenciais para explorar esta falha. Isso pode permitir que um invasor não autenticado acesse serviços internos, como serviços de metadados de nuvem, servidores de API do Kubernetes ou painéis de administração internos, e utilize o servidor como um oráculo de blind-SSRF para sondar serviços internos.