Vnth4Nhnt

A função `nvm ls` utiliza um programa sed para filtrar versões instaladas, incorporando o padrão de versão solicitado em um endereço `#...#`. Como as barras invertidas não são escapadas, uma string de versão contendo `#` ou `#` pode fechar o endereço prematuramente, fazendo com que o restante da string seja interpretado como comandos sed. Em sistemas com GNU sed, o comando `e` pode executar comandos de shell como o usuário, enquanto o BSD sed permite a leitura e gravação de arquivos através dos comandos `r` e `w`. Este problema ocorre quando uma string de versão influenciada por um invasor é passada para `nvm use`, `nvm which`, `nvm ls`, `nvm version`, `nvm run`, `nvm exec`, ou para `nvm-exec` via a variável `NODE VERSION`. Além disso, usuários que utilizam o hook bash `cdnvm` ou o hook zsh `load-nvmrc` estão suscetíveis à execução de comandos apenas ao entrar em um diretório que contenha um arquivo `.nvmrc` malicioso, pois esses hooks passam o conteúdo do arquivo diretamente para `nvm ls` e `nvm version`.

Certos endpoints de criação de documentos não verificam se o usuário do portal autenticado que faz a requisição pertence à parte alvo. Essa falta de autorização permite que usuários autenticados do portal criem documentos em nome de outras partes.

A falta de validação de entrada em alguns endpoints permite que atacantes autenticados realizem injeção de SQL. Ao enviar requisições especialmente elaboradas, um atacante pode manipular consultas ao banco de dados para extrair informações sensíveis.

A falta de validação de entrada em alguns endpoints permite que atacantes autenticados com baixos privilégios realizem SQL injection, que é uma técnica usada para manipular consultas ao banco de dados. Ao enviar requisições especialmente elaboradas, um atacante pode extrair informações sensíveis do banco de dados.

Certos endpoints relacionados a projetos não aplicam verificações de permissão. Isso permite que usuários autenticados com baixos privilégios chamem esses endpoints diretamente para ler dados de projetos além do que a função atribuída a eles permite.

A falta de validação de entrada em alguns endpoints permite que atacantes autenticados realizem injeção de SQL. Ao enviar requisições especialmente elaboradas, um atacante pode injetar SQL em consultas ao banco de dados para extrair informações sensíveis do banco de dados subjacente.

Ocorre a injeção de template no lado do servidor porque os campos de mensagem controlados pelo usuário não são validados antes da renderização do template, permitindo que expressões sejam executadas em um contexto irrestrito. Atacantes autenticados com uma função operacional comum podem injetar expressões de template para ler e gravar dados arbitrários no banco de dados, excluir documentos, enviar solicitações externas do servidor e enviar e-mails do site.

Certos endpoints falham ao aplicar verificações de autorização baseadas em função adequadas. Isso permite que usuários autenticados com baixos privilégios enviem solicitações a esses endpoints para modificar registros de inventário além de sua função permitida.

Certos endpoints falham ao aplicar verificações de autorização adequadas nos dados mestres de itens. Isso permite que atacantes autenticados com contas de baixos privilégios acessem e leiam dados mestres de itens que excedem as permissões atribuídas ao seu cargo.

Certos endpoints falham ao aplicar verificações de permissão adequadas. Isso permite que usuários autenticados acessem e leiam dados financeiros que excedem as permissões concedidas ao seu cargo atribuído.

Certos endpoints não aplicam verificações de permissão adequadas, permitindo que usuários autenticados com baixos privilégios desativem registros mestre e modifiquem dados além das permissões de seu papel atribuído.

Existe um problema em um endpoint de criação de registros que aceita o tipo de registro da requisição e insere o registro com as verificações de permissão desativadas. Isso permite que qualquer usuário autenticado, independentemente de sua função operacional, especifique um tipo de registro privilegiado para criar contas privilegiadas e assumir o controle total do site.

Certos endpoints que lidam com registros de terceiros (party records) carecem de autorização adequada. Isso permite que usuários autenticados com contas de baixos privilégios enviem solicitações a esses endpoints e modifiquem dados além de sua função permitida, resultando em alterações não autorizadas nos registros de terceiros.

Certos endpoints falham ao aplicar verificações de autorização adequadas durante alterações de status de registros. Isso permite que usuários autenticados com baixos privilégios modifiquem dados além de sua função permitida, ignorando as restrições de acesso baseadas em função.

Existe uma falha de bypass de autorização em um endpoint que aceita uma flag fornecida pelo chamador para desativar a aplicação de permissões. Atacantes autenticados podem definir essa flag ao chamar o endpoint para ignorar as verificações de permissão e ler registros de terceiros além de sua função permitida.

A função `nvm alias()` não realiza uma verificação de contenção ao concatenar o nome de uma versão ou alias solicitado ao diretório `$NVM DIR/alias`. Isso permite que um nome contendo componentes `..` escape do diretório de alias e acesse arquivos arbitrários legíveis pelo usuário, como `../../.npmrc`. A função `nvm print alias file()` então exibe linhas não vazias e que não sejam comentários do arquivo acessado. Isso pode ser acionado por meio de um arquivo `.nvmrc` não confiável quando um desenvolvedor executa `nvm use`, `nvm install` ou `nvm which` dentro de um repositório malicioso, revelando a primeira linha que não seja um comentário em uma mensagem de erro. Além disso, o uso de `nvm alias <traversing-name>` pode revelar todas as linhas que não sejam comentários do arquivo alvo.

O backend local falha ao mascarar bits de permissão especiais ao aplicar metadados de modo fornecidos pela fonte. Isso permite que um invasor defina bits setuid ou setgid em arquivos sob seu controle. Ao copiar arquivos com preservação de metadados de uma fonte remota não confiável, um invasor pode implantar um binário setuid para escalar privilégios para root, caso o processo seja executado como root, ou para o usuário da conta de serviço associada.

Existe um problema de Cross Site Scripting (XSS) não autenticado, que permite a um invasor executar scripts maliciosos no navegador de um usuário sem a necessidade de autenticação prévia.

A política padrão `security.http.urls` falha ao bloquear adequadamente requisições para literais IPv4 de loopback, internos e de metadados de nuvem, pois a regra de negação corresponde apenas à notação decimal pontuada. Consequentemente, codificações IPv4 alternativas, como inteiro, hexadecimal ou octal, ignoram a política. Quando um template fornece uma URL não confiável ou derivada de dados para a função `resources.GetRemote()` e a plataforma host utiliza o resolvedor de sistema cgo, essas codificações resolvem para endereços bloqueados. Isso permite requisições do lado do servidor durante a compilação para serviços de loopback e internos, incluindo endpoints de metadados de nuvem em compilações hospedadas ou de CI. Esta falha também se aplica a cada salto de redirecionamento, pois a mesma verificação é reutilizada.

Uma referência de volume de sandbox `volumeId` (que também pode ser um nome de volume) era encaminhada para o executor e utilizada para construir o caminho de origem do bind-mount do host sem confinamento. Uma referência contendo sequências de path-traversal—caracteres utilizados para acessar arquivos e diretórios fora do diretório de trabalho atual—poderia, em princípio, resolver a origem da montagem fora do diretório base pretendido por volume. Se acessível, um usuário autenticado poderia fazer com que o executor realizasse o bind-mount de um caminho de host não pretendido em sua sandbox, permitindo potencialmente acesso de leitura e escrita aos dados de volume de outros locatários.