Ayushparkara

Existe uma falha de bypass de validação no manipulador de instalação de pacotes da comunidade para implantações em modo de fila (queue mode). Atacantes com acesso de escrita ao Redis podem ignorar a validação de nome, verificações de permissão, verificação de checksum e verificações de segurança do npm. Isso permite a instalação de pacotes npm arbitrários em todas as instâncias do cluster sem autenticação.

Ocorre cross-site scripting (XSS) armazenado quando nomes de famílias de fontes personalizadas são interpolados em uma regra CSS `@font-face` e injetados na página como HTML sem sanitização. O backend aceita uma string de família de fonte arbitrária e o frontend grava o estilo resultante usando `innerHTML`. Um nome malicioso contendo marcação, como uma tag de fechamento de estilo seguida por um script, pode romper o elemento de estilo para executar JavaScript na origem do Penpot. Este ataque passivo dispara a execução do script quando um membro da equipe abre um arquivo que referencia a fonte maliciosa, podendo levar ao roubo de cookies de sessão, ações realizadas em nome da vítima e acesso não autorizado a arquivos e projetos.

Ocorre cross-site scripting armazenado quando os comentários de arquivos são armazenados como texto bruto e renderizados na página usando `innerHTML` sem sanitização. O backend realiza apenas uma verificação de comprimento, permitindo que um membro da equipe incorpore HTML ou scripts em um comentário. Quando outros colaboradores abrem o painel de comentários, o script é executado na origem do Penpot, o que pode levar ao roubo de cookies de sessão, ações não autorizadas realizadas em nome da vítima e acesso não autorizado a arquivos e projetos.

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.

O provedor WS-Federation neste provedor de identidade de código aberto valida o parâmetro `wreply` fornecido pelo usuário usando uma verificação de prefixo de string bruta em vez de uma análise de URL adequada. Um invasor pode criar um link de login com um valor `wreply` de uma origem diferente que ignore essa verificação, levando o navegador da vítima a enviar (POST) a resposta de login WS-Federation assinada para a infraestrutura controlada pelo invasor.

Um problema de validação de caminho permite que dados de repositório manipulados afetem arquivos fora do alvo de checkout pretendido, incluindo o diretório `.git` do repositório. Isso ocorre porque o software divergiu das verificações de validação implementadas no Git upstream. Alguns vetores de ataque são específicos de plataforma, afetando apenas usuários de Windows ou macOS, enquanto outros se aplicam a todas as plataformas suportadas. O isolamento pode ser fornecido se instâncias de sistema de arquivos `go-billy` não descendentes ou tipos de sistemas de arquivos diferentes forem usados para o `Storer` e `Worktree`, como o uso de `memfs` para o diretório `.git` e `osfs` para a worktree. No entanto, esse isolamento pode não se aplicar a repositórios que contenham submódulos, pois os diretórios dotgit de submódulos ainda podem ser materializados no contexto da worktree.

Gotenberg é uma API stateless alimentada por Docker para arquivos PDF. O endpoint de conversão de URL para PDF do Chromium '/forms/chromium/convert/url' não possui proteção padrão contra Server-Side Request Forgery (SSRF) para requisições HTTP e HTTPS, pois a lista de negação padrão bloqueia apenas URIs `file://`. Isso permite que um invasor não autenticado direcione o Chromium para endereços IP internos, incluindo loopback, intervalos RFC 1918 e endpoints de metadados de nuvem, recebendo a resposta renderizada como um PDF. Além disso, os endpoints `downloadFrom` e `webhook` também são afetados por um bypass baseado em redirecionamento. Mesmo quando uma lista de negação personalizada é configurada, a instância do Chromium e outros endpoints seguem redirecionamentos HTTP 302 de URLs externas controladas por invasores para alvos internos sem revalidar o destino na lista de negação.

O cookie `budibase:auth`, que contém o token de sessão JWT, está configurado com `httpOnly: false` no arquivo `packages/backend-core/src/utils/utils.ts`. Isso permite que o JavaScript acesse o cookie via `document.cookie`, possibilitando que um invasor roube o JWT e realize a invasão total da conta caso exista uma falha de Cross-Site Scripting (XSS). Além disso, o cookie não possui a flag `secure: true`, o que significa que pode ser enviado via HTTP em texto simples, e carece do atributo `sameSite`, tornando-o suscetível ao anexo de requisições entre sites.

Durante operações de clone e fetch smart-HTTP, a biblioteca pode vazar credenciais de autenticação HTTP ao seguir redirecionamentos. Se um repositório remoto responder à solicitação inicial '/info/refs' com um redirecionamento para um host diferente, o endpoint da sessão é atualizado para o local redirecionado e a autenticação original, como cabeçalhos de Autorização, é reutilizada para solicitações subsequentes. Isso permite que um invasor que controle o destino do redirecionamento capture as credenciais e potencialmente acesse os repositórios da vítima ou outros recursos. Este problema ocorre ao interagir com servidores Git não confiáveis ou mal configurados ou ao usar conexões HTTP não seguras.

O middleware de autenticação utiliza expressões regulares não ancoradas para corresponder padrões de endpoints públicos à variável `ctx.request.url`. Como o `ctx.request.url` no Koa inclui a string de consulta (query string), um invasor pode ignorar a autenticação e acessar endpoints protegidos ao anexar um caminho de endpoint público como um parâmetro de consulta. Por exemplo, usar o endpoint '/api/global/users/search' com um parâmetro de consulta como `x=/api/system/status` permite o acesso não autorizado porque a expressão regular corresponde à parte da string de consulta da URL.

O Portainer inclui uma configuração de segurança para desativar montagens de bind (bind mounts) para não administradores, destinada a impedir que usuários comuns vinculem caminhos do host em contêineres via API do Docker mediada pelo Portainer. No entanto, o mecanismo de imposição inspecionava apenas a array `HostConfig.Binds` e ignorava a array equivalente `HostConfig.Mounts`. Como ambos os campos são intercambiáveis no daemon do Docker, um usuário autenticado com direitos de criação de contêineres pode burlar essa restrição enviando uma entrada do tipo `bind` em `HostConfig.Mounts` no endpoint 'POST /containers/create'. Isso permite que o usuário monte qualquer caminho do host em seu contêiner, potencialmente obtendo acesso de leitura ou gravação ao sistema de arquivos do host como o usuário do daemon do Docker (geralmente `root`). Isso pode levar à exposição de arquivos sensíveis, comprometimento de outros contêineres no mesmo host ou acesso total à API do Docker se o socket do Docker for montado.