Mufeedvh

Em implantações multi-tenant usando WebAuthn com um pool de usuários compartilhado, o servidor falha ao restringir as pesquisas ao tenant solicitado e não verifica a associação ao tenant durante o login. Isso permite que um usuário com uma chave de acesso (passkey) válida em um tenant se autentique em outro tenant dentro do mesmo aplicativo, mesmo sem ter associação ao tenant de destino. O problema envolve as funções `loadOptionsById Transaction()` e `getUserInfoByCredentialId Transaction()`, bem como o método `WebAuthN.signIn`.

Existe uma condição de corrida onde a função `createNewSession()` pode resolver um usuário primário antes que a função `unlinkAccounts()` desvincule um método de login. A sessão é então inserida após o processo de desvinculação ter enumerado e revogado as sessões existentes. Um invasor que controle o método de login vinculado pode explorar isso para manter uma sessão assinada, baseada em banco de dados e renovável como a antiga identidade primária após o método ser desvinculado. Esta sessão permanece ativa até expirar ou ser explicitamente revogada.

Existe uma falha de autorização na função `checkPermissionsForCreateOrUpdate()` dentro da classe `Multitenancy`. Em implantações multi-tenant licenciadas onde várias aplicações compartilham um domínio de URI de conexão não padrão e utilizam `api keys` separadas, um invasor com uma chave de API válida para uma aplicação pode atualizar o domínio de URI de conexão pai. Isso ocorre porque o sistema não exige que a aplicação e o tenant de origem sejam públicos ao verificar o domínio durante operações de criação ou atualização. Consequentemente, um invasor pode substituir a chave pai e as chaves de aplicações irmãs, modificar usuários irmãos, sequestrar sessões e estabelecer persistência via usuários de painéis irmãos. Além disso, a omissão do identificador opcional nos manipuladores de criação ou atualização v2 permite que um invasor direcione o tenant base, ignorando verificações de permissão e travas de recursos empresariais para modificar `firstFactors`, fatores secundários obrigatórios e sinalizadores de receitas habilitadas, comprometendo a integridade e disponibilidade do login.

Existe um problema no parser HTTP/1.1 que permite o processamento de requisições contendo os cabeçalhos `Content-Length` e `Transfer-Encoding: chunked` simultaneamente. Isso pode ser explorado por atacantes remotos não autenticados através de um intermediário de front-end para dessincronizar requisições de backend, permitindo o contrabando (smuggling) de requisições HTTP maliciosas para o serviço Actix. HTTP request smuggling é uma técnica utilizada para interferir na maneira como um site processa sequências de requisições HTTP.

The software does not properly validate file target paths for Advanced Logging. This allows system administrators to potentially read arbitrary host files through a malicious AdvancedLoggingJSON configuration when generating support packets.

Uma vulnerabilidade no modelo de permissões permite que conexões Unix Domain Socket (UDS) contornem restrições de rede quando `--permission` está ativado. Mesmo sem `--allow-net`, entradas controladas por atacantes, como URLs ou opções de socketPath, podem se conectar a soquetes locais arbitrários por meio de net, tls ou undici/fetch. Isso viola a fronteira de segurança pretendida pelo modelo de permissões e permite acesso a serviços locais privilegiados, potencialmente levando a elevação de privilégios, exposição de dados ou execução de código local. As permissões de rede (`--allow-net`) estão atualmente na fase experimental.

O plugin de multi-sessão contém uma falha no after-hook do endpoint `/sign-out`. O sistema confia em cookies de multi-sessão brutos e encaminha os valores extraídos para a função `deleteSessions()` dentro do `internalAdapter` sem verificar a assinatura do cookie, como através do `getSignedCookie()`. Isso permite que um invasor forneça um cookie ` multi-*` forjado para disparar a exclusão de tokens de sessão arbitrários.

O @hoppscotch/cli é uma interface de linha de comando (CLI) para executar scripts de teste do Hoppscotch em ambientes de integração contínua (CI). Antes da versão 0.8.0, o pacote @hoppscotch/js-sandbox fornece uma sandbox de Javascript que utiliza o módulo vm do Node.js. No entanto, o módulo vm não é seguro para isolar código Javascript não confiável, pois o código dentro do contexto vm pode escapar se conseguir obter qualquer referência a um objeto criado fora do vm. No caso do @hoppscotch/js-sandbox, várias referências a objetos externos são passadas para o contexto vm para permitir que scripts pré-solicitação interajam com variáveis de ambiente e outros elementos. Mas isso também permite que o script pré-solicitação escape da sandbox.