Alcls01111

Existe uma recursão descontrolada na função `formDataToJSON` ao processar nomes de campos `FormData` com segmentos de colchetes profundamente aninhados. Um invasor pode fornecer `FormData` com nomes de campos contendo milhares de colchetes aninhados para esgotar a pilha de chamadas do JavaScript, disparando um `RangeError`. Isso leva à falha da requisição ou ao encerramento do processo em aplicações que não tratam a exceção, resultando em negação de serviço. Este problema afeta a API `axios.formToJSON(formData)`, a importação `formToJSON`, o arquivo `lib/helpers/formDataToJSON.js` e o `transformRequest` padrão quando o `FormData` é enviado com o tipo de conteúdo `application/json`. A vulnerabilidade é disparada através da função `buildPath()`, que processa recursivamente segmentos de caminho sem impor uma profundidade máxima.

Quando a função `fetch()` é chamada, o runtime valida o nome do host de destino em relação às regras `--deny-net`, mas não re-verifica os endereços IP para os quais esse nome de host é resolvido. Isso permite que um script controlado por um invasor use um nome de domínio especialmente criado que passe na verificação inicial do nome do host, mas que seja resolvido para um IP negado, ignorando efetivamente as regras de isolamento de rede. Isso pode levar ao acesso não autorizado a hosts bloqueados, como `localhost` ou serviços internos, particularmente ao executar código não confiável ou de terceiros.

Ao abrir uma conexão WebSocket, o runtime valida o nome do host de destino em relação às regras `--deny-net`, mas não re-verifica os endereços IP para os quais o nome do host é resolvido. Isso permite que um script controlado por um invasor use um nome de domínio especialmente criado que passe na verificação do nome do host, mas seja resolvido para um IP negado, ignorando as regras de isolamento de rede. Isso pode levar a conexões não autorizadas a hosts que o usuário pretendia bloquear, como `localhost` ou serviços internos, potencialmente por meio de uma dependência maliciosa ou comprometida.

Um problema de cross-site scripting existe no componente NoScript, que escreve o conteúdo do slot no innerHTML sem a devida filtragem. Isso permite que atacantes injetem scripts maliciosos por meio de dados não confiáveis nos slots do NoScript, como parâmetros `route.query`. Esses scripts são executados no contexto do documento quando a tag noscript é implicitamente fechada por tags de script.

A função `reloadNuxtApp()` aceita caminhos relativos ao protocolo, como //evil.com. Esses caminhos ignoram a verificação de protocolo de script e são resolvidos como uma URL de origem cruzada com base no protocolo da página atual. Isso permite que invasores injetem caminhos que redirecionam os usuários para hosts controlados por invasores, o que pode ser usado para phishing e roubo de códigos de autorização OAuth.

O Nuxt falha ao validar URLs capazes de executar scripts na opção open do `navigateTo`, o que permite a execução de scripts no lado do cliente. Quando a entrada controlada pelo usuário é passada para o `navigateTo`, invasores podem fornecer URLs `javascript:` através do parâmetro `open` para executar scripts arbitrários na origem da aplicação.

Ao executar o servidor de desenvolvimento no Linux, o servidor IPC (Inter-Process Communication) do vite-node vincula-se a um socket Unix de namespace abstrato sem restrições de permissão. Isso permite que usuários locais enumerem e se conectem ao socket. Usuários co-residentes sem privilégios podem explorar o manipulador de requisição de módulo desprotegido para ler arquivos arbitrários, como `.env` e chaves SSH, através do pipeline de plugin SSR (Server-Side Rendering). Versões de produção não são afetadas, pois o servidor IPC funciona apenas em desenvolvimento.

O Nuxt contém três problemas de segurança relacionados ao manuseio de URLs de navegação do cliente através das funções `navigateTo()` e `reloadNuxtApp()`. Primeiro, existe um redirecionamento aberto no lado do servidor em `navigateTo()`, onde bypasses de normalização de caminho, como o uso de `/..//evil.com` ou `/.//evil.com`, permitem que atacantes contornem as verificações de host externo. Isso faz com que o navegador resolva o redirecionamento para um host controlado pelo atacante via cabeçalho Location ou meta-refresh, potencialmente permitindo phishing e roubo de códigos de autorização OAuth. Segundo, existe um problema de execução de script no lado do cliente em `navigateTo()` quando a opção `open` é utilizada. O manipulador falha ao aplicar verificações de protocolo de script, permitindo que alvos como `javascript:...` sejam executados na origem da aplicação, levando ao Cross-Site Scripting (XSS) refletido, que é a execução de scripts maliciosos no navegador da vítima. Terceiro, existe um redirecionamento aberto em `reloadNuxtApp()` através da variável `path`. Caminhos relativos ao protocolo, como `//evil.com`, ignoram as verificações de protocolo e são atribuídos ao `window.location.href`, causando um redirecionamento cross-origin.

Um usuário autenticado pode executar comandos arbitrários do sistema operacional no host por meio da funcionalidade de upload de arquivos do Docker. O problema ocorre porque o parâmetro `destinationPath` não é devidamente sanitizado e é interpolado diretamente em uma string de comando do shell. Ao utilizar metacaracteres de shell, como ; ou ", um invasor pode escapar do comando `docker cp` pretendido.