Kodareef5

Ocorre a falsificação de solicitação do lado do servidor (SSRF) nos nós de carregamento de documentos Cheerio, Playwright e Puppeteer, permitindo a evasão da proteção SSRF. Isso possibilita que atacantes forneçam URLs arbitrárias para recuperar metadados de nuvem, serviços internos e recursos de rede privada, com o conteúdo da resposta retornado como texto do documento.

O Envoy falha ao processar endereços IPv6 com escopo ao utilizar `Utility::copyInternetAddressAndPort` e caminhos de endereço de cliente QUIC. O processo reconstrói esses endereços via `addressAsString` e `Ipv6Instance`, resultando em uma string que contém um identificador de escopo de porcentagem que o `inet pton` não consegue analisar. Isso causa uma exceção ou a interrupção do processo. O problema pode ser desencadeado por destinos IPv6 com escopo fornecidos pelo kernel em implantações de proxy transparente ORIGINAL DST ou através de caminhos de conexão QUIC afetados.

Os endpoints da API de configuração de SSO estão expostos no mesmo limite de roteamento público que os endpoints de login e callback de SSO, permitindo que operações de gerenciamento de SSO, OIDC e SAML sejam acessadas sem autorização de administrador. Isso permite que usuários não autorizados ou com baixos privilégios inspecionem ou modifiquem a configuração de autenticação, o que, sob certas condições, pode levar ao sequestro de contas ou escalonamento de privilégios. Adicionalmente, a função de teste de conectividade de SSO pode ser abusada como uma primitiva de server-side request forgery (SSRF)—uma técnica onde um invasor induz o servidor a fazer requisições para um local não pretendido. Além disso, a API de lista de usuários retorna objetos de usuário sem limpar consistentemente os campos relacionados à autenticação.

Um cliente MQTT autenticado pode se inscrever na família de assuntos interna `$MQTT.deliver.pubrel`. Esta ação permite que o cliente ignore as permissões de inscrição configuradas e exponha metadados do protocolo MQTT QoS2 para sessões na conta. QoS2 (Quality of Service nível 2) é um mecanismo de protocolo que garante que uma mensagem seja entregue exatamente uma vez.

As verificações de destino de rastreamento de mensagens não são aplicadas consistentemente a mensagens que chegam por meio de conexões de leafnode. Isso permite que um operador de leafnode envie eventos de rastreamento para assuntos que normalmente seriam restritos e utilize o comportamento de rastreamento exclusivo para bloquear a entrega ou o armazenamento padrão de mensagens afetadas.

Um peer não autenticado com acesso de rede a um listener de leafnode com compressão habilitada pode causar a falha do servidor. Isso ocorre durante o handshake de leafnode pré-autenticação quando mensagens repetidas do protocolo leafnode INFO são enviadas antes que os processos de autenticação e configuração de conta sejam concluídos.

Coolify é uma ferramenta de código aberto e auto-hospedável para gerenciamento de servidores, aplicações e bancos de dados. Um usuário autenticado pode executar comandos em servidores gerenciados quando um recurso é excluído, pois o campo `LocalPersistentVolume.name` é interpolado diretamente em comandos de shell de volume do docker sem a devida filtragem de argumentos de shell. Isso permite a injeção de metacaracteres de shell no nome do armazenamento.

O processador de resposta da fonte SAML `ResponseProcessor.parse()` não valida o elemento Conditions em asserções. Especificamente, `NotBefore`, `NotOnOrAfter` e `AudienceRestriction` são ignorados, o que permite a repetição de asserções expiradas e a aceitação de asserções destinadas a outros provedores de serviço.

Na implementação `ngclient`, a função `DelegatedRole. is target in pathpattern()` em `tuf/api/ payload.py` utiliza `fnmatch.fnmatch` para verificar se um caminho de destino é autorizado por um padrão glob de delegação. No Windows, o `fnmatch.fnmatch` aplica `os.path.normcase`, que converte as strings para letras minúsculas, tornando a autorização de caminho insensível a maiúsculas e minúsculas. Este comportamento diverge da especificação TUF e difere do Linux e macOS. Se um repositório contiver delegações baseadas em caminho que diferem apenas por maiúsculas/minúsculas e uma função controlada por um invasor for processada antes da função legítima, um cliente Windows poderá aceitar um destino não autorizado fornecido pelo invasor para um caminho solicitado.

Um problema de traversal de caminho existe devido à validação inadequada de nomes de submódulos e a uma falha de herança de confiança. A função `name()` em `gix-validate` verifica apenas a primeira ocorrência de `..`, permitindo que nomes manipulados como `a..b/../../../.git/` ignorem a verificação. Além disso, essa validação não é invocada em caminhos de código de produção. Em `Submodule::open()`, o `git dir trust` do repositório pai (definido como `Trust::Full`) é clonado, o que faz com que o sistema ignore a verificação de propriedade. Um invasor pode explorar isso criando um arquivo `.gitmodules` malicioso, levando uma ferramenta construída com gitoxide a ler configurações arbitrárias de repositórios git, incluindo credenciais incorporadas, ignorando as proteções de diretório seguro.

O problema envolve a indexação de array não verificada durante a aplicação de delta e a alocação de memória sem limite disparada por cabeçalhos de tamanho controlados por atacantes no módulo `gix-pack`. Um atacante pode enviar dados de pacote especialmente manipulados durante operações de clone ou fetch para causar o pânico do processo ou a interrupção do mesmo por falta de memória.

Quando executada em implantações com criptografia WireGuard habilitada, a saída da ferramenta de depuração `cilium-bugtool` pode conter dados sensíveis. Especificamente, a chave privada WireGuard `cilium wg0.key`, utilizada para comunicação criptografada entre nós, pode ser exposta. Esta ferramenta é normalmente invocada manualmente ou durante a coleta de sysdumps através do comando `cilium sysdump`.

Um problema de canal lateral de tempo existe no middleware BasicAuth. Uma variável destinada a fornecer um segredo de fallback de tempo constante resolve-se consistentemente para uma string vazia, o que faz com que a comparação de tempo constante seja interrompida rapidamente em vez de realizar uma avaliação bcrypt completa. Isso cria um oráculo de tempo, permitindo que um invasor enumere nomes de usuário válidos medindo as diferenças nos tempos de resposta de autenticação.

O recurso de Cookie Rewriting está suscetível à injeção de código Lua. Um invasor com permissões de RBAC para criar ou modificar recursos HTTPProxy pode fornecer valores maliciosos nas variáveis `spec.routes[].cookieRewritePolicies[].pathRewrite.value` ou `spec.routes[].services[].cookieRewritePolicies[].pathRewrite.value`, resultando na execução de código arbitrário no proxy Envoy. Isso ocorre porque valores controlados pelo usuário são interpolados no código-fonte Lua usando Go text/template sem a sanitização suficiente. Embora o código injetado seja executado apenas na própria rota do invasor, ele pode ser usado para ler credenciais de cliente xDS do Envoy no sistema de arquivos — expondo potencialmente certificados TLS e chaves privadas de outros locatários — ou causar a negação de serviço para outros locatários que compartilham a instância do Envoy.

Uma falha de validação na restrição de caminho do VolumeMount permite a montagem de volumes em caminhos internos restritos '/tekton/' usando componentes de travessia de caminho '..'. A verificação de restrição utiliza a função `strings.HasPrefix` sem aplicar o `filepath.Clean`, o que significa que um caminho como '/tekton/home/../results' passa na validação, mas é resolvido como '/tekton/results' em tempo de execução. Isso ocorre porque '/tekton/home' é um prefixo permitido, permitindo que a travessia ignore a verificação. Este problema existe nos arquivos `container validation.go` e `task validation.go`. Um usuário autenticado com permissões de criação de Task ou TaskRun pode explorar isso para gravar resultados de tarefas falsos, ler ou modificar scripts de etapa antes da execução ou interferir no estado de coordenação do ponto de entrada.

O resolvedor git não valida o parâmetro `revision`, que é passado diretamente como um argumento posicional para o comando `git fetch`. Isso permite que um invasor injete flags arbitrárias, como `--upload-pack=<binary>`. Além disso, a função `validateRepoURL` permite URLs que começam com `/`, possibilitando o uso de caminhos do sistema de arquivos local. Um locatário capaz de enviar objetos `ResolutionRequest` pode combinar esses comportamentos para executar binários arbitrários no pod do resolvedor. Como a ServiceAccount `tekton-pipelines-resolvers` possui permissões de `get`, `list` e `watch` em todos os Secrets em nível de cluster, isso pode levar à exfiltração total de segredos de todo o cluster.

A manipulação de parâmetros de consulta em endpoints do Painel de Controle e da API REST, ou argumentos em consultas GraphQL, pode resultar na perda de conteúdo, ativos e contas de usuário. A exploração via Painel de Controle requer autenticação com permissões mínimas, como a permissão "view entries" para excluir entradas ou a permissão "view users" para excluir usuários. As explorações direcionadas às APIs REST e GraphQL não requerem permissões, porém essas APIs não são habilitadas por padrão; elas precisariam ser explicitamente habilitadas sem autenticação configurada e com os recursos específicos habilitados para serem exploradas.

Existe um bypass de autorização na opção de imposição `email domain`. Um invasor pode se autenticar usando um claim de e-mail malformado, como `attacker@evil.com@company.com`, para satisfazer uma verificação de domínio permitido para `company.com`. Este problema afeta especificamente implementações que dependem de restrições de `email domain` e que aceitam valores de claim de e-mail de provedores de identidade ou mapeamentos de claim que não impõem rigorosamente a sintaxe normal de e-mail. O risco está presente principalmente em ambientes OIDC auto-hospedados ou personalizados e configurações federadas onde valores de claim inesperados podem chegar ao proxy.

Existe um problema no webhook do filtro de condições em `libs/application-generic/src/usecases/conditions-filter/conditions-filter.usecase.ts` onde o `child.webhookUrl` configurado pelo usuário é passado diretamente para o `axios.post()` sem passar pela validação de SSRF através da função `validateUrlSsrf()`. Isso permite que um invasor dispare uma requisição POST para serviços privados ou de link-local, como o AWS IMDSv1, durante a avaliação de condições de fluxo de trabalho. Os dados de resposta resultantes são armazenados nos detalhes de execução e podem ser recuperados através do endpoint 'GET /execution-details', potencialmente expondo dados de serviços internos ou credenciais de serviços de metadados que aceitam POST. SSRF (Server-Side Request Forgery) é uma vulnerabilidade onde um servidor é enganado para fazer requisições a um local não pretendido.

O mecanismo de template v2 em `runtime/template/v2/template.go` remove `env` e `expandenv` do `TxtFuncMap()`, mas deixa a função `getHostByName()` acessível para templates controlados pelo usuário. Como o controlador executa templates dentro de seu próprio processo, um invasor capaz de criar ou atualizar recursos ExternalSecret com templates pode disparar consultas DNS no lado do controlador usando valores derivados de segredos. Isso cria um primitivo de exfiltração de DNS, permitindo que materiais de segredos recuperados sejam vazados via consultas DNS sem exigir acesso direto à rede externa a partir da carga de trabalho do invasor. Isso resulta em um problema de confidencialidade em ambientes onde usuários de menor confiança podem criar esses recursos e o controlador possui capacidade de resolução de DNS.