Oskar-Zeinomahmalat-Sonarsource

Os nomes de arquivo construídos dentro do file selector não possuem verificações de sanitização, deixando-os vulneráveis a provedores de documentos maliciosos. Isso pode resultar em casos em que um usuário com um provedor de documentos malicioso instalado pode selecionar um arquivo de documento desse provedor enquanto usa seu aplicativo e potencialmente sobrescrever arquivos internos no cache do aplicativo.

Os nomes de arquivos construídos no image picker não possuem verificações de sanitização, deixando-os vulneráveis a provedores de documentos maliciosos. Isso pode resultar em casos em que um usuário com um provedor de documentos malicioso instalado possa selecionar um arquivo de imagem desse provedor enquanto utiliza o aplicativo e potencialmente sobrescrever arquivos internos no cache do aplicativo.

Nome do software vulnerável e versões afetadas: Versões do SnappyMail anteriores à 2.38.0 Descrição: O SnappyMail é um cliente de e-mail baseado na web de código aberto que utiliza a função `cleanHtml()` para limpar HTML e CSS em e-mails. Pesquisas descobriram que a função possui bugs que causam uma exploração mXSS, permitindo que um invasor motivado injete JavaScript. No entanto, devido à Política de Segurança de Conteúdo padrão, o impacto da exploração é mínimo. Seria possível criar um ataque que vazasse alguns dados ao carregar imagens através do proxy ou ao carregar um anexo JavaScript do e-mail. Recomendações: Para versões anteriores à 2.38.0, recomenda-se que os usuários atualizem para a versão 2.38.0 ou posterior. Para versões mais antigas, uma extensão chamada “Security mXSS” pode ser instalada como medida de mitigação, disponível na área de administração em `/?admin#/packages`. Como solução temporária, considere desativar a função `cleanHtml()` até que um patch esteja disponível. Restrinja o acesso à função `cleanHtml()` vulnerável para minimizar o risco de exploração. Evite usar a função `cleanHtml()` no endpoint da API afetado até que o problema seja resolvido.

Nome do software vulnerável e versões afetadas: Versões do JumpServer anteriores à 3.10.12 Versões do JumpServer anteriores à 4.0.0 Descrição: O JumpServer é uma ferramenta de código aberto de Gerenciamento de Acesso Privilegiado (PAM) que fornece às equipes de DevOps e TI acesso sob demanda e seguro a endpoints SSH, RDP, Kubernetes, bancos de dados e RemoteApp por meio de um navegador da web. Um invasor pode explorar o playbook do Ansible para ler arquivos arbitrários no contêiner do Celery, levando à divulgação de informações confidenciais. O contêiner Celery é executado como root e tem acesso ao banco de dados, permitindo que o invasor roube todos os segredos dos hosts, crie uma nova conta no JumpServer com privilégios de administrador ou manipule o banco de dados de outras maneiras. Recomendações: Para versões do JumpServer anteriores à 3.10.12, atualize para a versão 3.10.12 ou posterior. Para versões do JumpServer anteriores à 4.0.0, atualize para a versão 4.0.0 ou posterior. Como solução alternativa temporária, considere restringir o acesso ao contêiner Celery para minimizar o risco de exploração.

Nome do software vulnerável e versões afetadas: Versões do JumpServer anteriores à 3.10.12 Versões do JumpServer anteriores à 4.0.0 Descrição: O problema está relacionado à ferramenta JumpServer Privileged Access Management (PAM), que fornece acesso seguro a vários terminais por meio de um navegador da web. Um invasor pode explorar o playbook do Ansible para gravar arquivos arbitrários, levando à execução remota de código (RCE) no contêiner Celery. O contêiner Celery é executado como root e tem acesso ao banco de dados, permitindo que um invasor roube todos os segredos dos hosts, crie uma nova conta no JumpServer com privilégios de administrador ou manipule o banco de dados de outras maneiras. Recomendações: Para versões do JumpServer anteriores à 3.10.12, atualize para a versão 3.10.12 ou posterior. Para versões do JumpServer anteriores à 4.0.0, atualize para a versão 4.0.0 ou posterior.

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.

O JumpServer é um bastion host de código aberto e um sistema de auditoria de segurança para operações e manutenção. Os invasores podem explorar uma vulnerabilidade de injeção de modelo Jinja2 no Ansible do JumpServer para executar código arbitrário dentro do contêiner Celery. Como o contêiner Celery é executado com privilégios de root e tem acesso ao banco de dados, os invasores poderiam roubar informações confidenciais de todos os hosts ou manipular o banco de dados.

O problema está relacionado à validação insuficiente de entradas no Ansible do JumpServer, permitindo que invasores remotos contornem o mecanismo de validação de entradas e executem código arbitrário dentro do contêiner Celery. Como o contêiner Celery é executado com privilégios de root e tem acesso ao banco de dados, os invasores poderiam roubar informações confidenciais de todos os hosts ou manipular o banco de dados.

A flaw in the Core API of jumpserver allows attackers to bypass password brute-force protections by spoofing arbitrary IP addresses. This enables attackers to make unlimited password attempts by altering their apparent IP address for each request.

The verification code for resetting a user's password in JumpServer is vulnerable to brute-force attacks due to the absence of rate limiting. This allows for up to 1,000,000 validation attempts within a 1-minute window. The issue is related to the 6-digit verification code sent to users to facilitate password reset.

The issue concerns the authentication procedure in JumpServer, an open source bastion host. An unauthenticated user can authenticate to the core API using a username and an SSH public key without needing a password or the corresponding SSH private key. This is possible because the API for the KoKo component to validate user private key logins does not verify the source of requests and will generate a personal authentication token. Given that public keys can be easily leaked, an attacker can exploit the leaked public key and username to authenticate, subsequently gaining access to the current user's information and authorized actions.

An authenticated user can exploit a vulnerability in MongoDB sessions to execute arbitrary commands, leading to remote code execution. This vulnerability may further be leveraged to gain root privileges on the system. Through the WEB CLI interface provided by the koko component, a user logs into the authorized mongoDB database and exploits the MongoDB session to execute arbitrary commands.