Bjohansebas

Quando uma entrada de proxy é configurada para encaminhar WebSockets, o servidor encaminha solicitações de upgrade de WebSocket não-HMR (Hot Module Replacement) para o alvo do proxy sem validar os cabeçalhos Host ou Origin. Isso ignora a proteção allowedHosts. Consequentemente, uma página web maliciosa visitada por um desenvolvedor pode estabelecer uma conexão WebSocket de origem cruzada através do servidor de desenvolvimento para ler e gravar no backend proximado, mesmo que o servidor esteja vinculado ao endereço de loopback.

O endpoint 'open-editor' não autenticado valida o cabeçalho Host usando uma expressão regular projetada para esquemas de Origem de navegador. Um valor de Host começando com `file:` ou um esquema de extensão pode ignorar as verificações de hostname e `allowedHosts`. Um peer de rede pode enviar uma requisição com um Host malformado que passa na validação, fazendo com que a construção da URL do endpoint falhe. No modo padrão de não produção, o servidor retorna uma resposta HTTP 500 contendo o rastreamento completo da exceção (stack trace), o que revela caminhos absolutos do sistema de arquivos, locais de módulos instalados e números de linhas internas do código-fonte.

Existe uma condição de corrida no analisador multipart quando configurado com uma função `fileFilter()` assíncrona. Se uma requisição for abortada enquanto um `fileFilter()` assíncrono ainda estiver pendente, o callback pode retomar um fluxo de análise que já foi encerrado. Isso faz com que o analisador subjacente emita um erro em um fluxo que não possui mais um ouvinte de erro, resultando em um evento de erro não tratado que interrompe o processo do Node.js, levando a uma Negação de Serviço. Este problema afeta qualquer aplicação que utilize um `fileFilter()` assíncrono, independentemente do mecanismo de armazenamento utilizado.

Existe um problema onde uma única requisição pode travar qualquer aplicação que utilize as opções padrão. Quando uma requisição utiliza um Content-Encoding como gzip, o software a direciona para um fluxo de descompressão, mas não anexa um ouvinte de erro após a leitura do corpo. Se a carga útil contiver um quadro comprimido válido seguido de bytes residuais, a aplicação responde normalmente ao quadro válido, mas os bytes residuais acionam um erro no decodificador finalizado. Esse erro é relançado como uma exceção não capturada, encerrando o processo. Como a análise do corpo ocorre antes do roteamento, qualquer endpoint que analise um corpo é afetado.

o multer é um middleware de Node.js para lidar com uploads de multipart/form-data. Quando uma requisição que utiliza armazenamento em disco é abortada durante o processo de upload, as gravações de arquivos que são concluídas após a execução da limpeza de aborto não são removidas. Isso resulta em arquivos órfãos permanecendo no disco. Um atacante remoto não autenticado pode explorar isso iniciando e abortando uploads repetidamente para esgotar o espaço em disco, causando a negação de serviço.

Este middleware de compressão para Node.js e Express contém um vazamento de memória. Quando um cliente aborta uma conexão enquanto uma resposta comprimida está sendo transmitida, o fluxo zlib usado para a compressão não é destruído. Um invasor remoto não autenticado pode explorar isso iniciando repetidamente requisições e desconectando-se prematuramente, levando ao esgotamento da memória nativa do zlib e causando a falha do servidor. Isso resulta em uma Negação de Serviço (DoS), uma condição onde um serviço fica indisponível para seus usuários pretendidos.

Existe um problema no wrapper do mecanismo de visualização Express para Handlebars onde o processo Node.js pode travar durante a filtragem de saída. Isso ocorre quando um helper assíncrono, registrado via `registerAsyncHelper()`, resolve para um objeto com uma propriedade `toHTML` que é verdadeira (truthy), mas não chamável. A função `escapeExpression()` tenta chamar `toHTML` como um método, resultando em um TypeError. Como a substituição assíncrona é executada em um tick posterior, fora do bloco try/catch da função de renderização, o erro torna-se uma exceção não capturada que encerra o processo sem enviar uma resposta. Isso pode ser acionado remotamente se um helper assíncrono resolver para um objeto influenciado externamente, como um JSON analisado.

Existe um problema no auxiliar interno utilizado para escapar valores de tokens de log. O software não neutraliza os caracteres de separação de linha Unicode U+0085 (Next Line), U+2028 (Line Separator) e U+2029 (Paragraph Separator). Um cliente remoto não autenticado pode injetar esses caracteres em um token de log controlado pelo invasor, como um nome de usuário de autenticação Basic processado através do token `remote-user`. Isso permite a falsificação de logs (log forging), onde sistemas de processamento de logs subsequentes compatíveis com Unicode dividem um único log de requisição em múltiplos registros lógicos.

Ao utilizar o mecanismo de armazenamento em disco para processar multipart/form-data, o software não fecha o descritor de arquivo de gravação subjacente se um upload for abortado ou truncado antes da conclusão do fluxo de gravação. Embora o arquivo visível seja removido, o descritor aberto permanece, causando um vazamento de descritores de arquivo e blocos de disco. Um invasor remoto pode explorar isso enviando uploads multipart abortados ou malformados repetidamente para uma rota de upload, potencialmente esgotando os recursos do sistema e levando a uma negação de serviço.

Existe uma condição de corrida (race condition) no tratamento do fluxo de arquivos quando uma aplicação utiliza um `fileFilter` assíncrono em conjunto com o limite de `fileSize`. Isso permite que arquivos que excedam o limite de tamanho configurado ignorem a rejeição do limite. O impacto é limitado, pois o analisador multipart subjacente ainda trunca o fluxo no limite de tamanho, significando que o problema é uma evasão do mecanismo de rejeição e não um consumo descontrolado de recursos.

A API `registerAsyncHelper` no mecanismo de visualização hbs para Express ignora a codificação automática de HTML do Handlebars. Durante a primeira passagem de renderização, um helper assíncrono retorna um marcador opaco que é codificado; no entanto, o hbs subsequentemente substitui esse marcador pelo valor de retorno bruto do callback sem codificá-lo. Isso ocorre nos caminhos de renderização em cache, sem cache e de layout. Se uma aplicação passar dados influenciados por um invasor, como conteúdo fornecido pelo usuário em um banco de dados, para um callback de helper assíncrono, isso pode resultar em cross-site scripting (XSS) armazenado ou refletido, onde HTML e JavaScript arbitrários são injetados na página renderizada pelo servidor.

Quando o parser é configurado com um valor de opção `limit` inválido, como uma string não analisável ou NaN (Not-a-Number), a verificação do tamanho do corpo da requisição é silenciosamente ignorada. Isso ocorre porque o mecanismo de análise interno retorna nulo, fazendo com que aplicações que dependem do parâmetro `limit` como sua principal salvaguarda aceitem cargas úteis arbitrariamente grandes. Isso pode levar ao consumo excessivo de memória e CPU, resultando em uma negação de serviço.

Um peer não autenticado pode causar a terminação do processo Node.js, resultando em uma negação de serviço. Isso ocorre quando o servidor recebe uma requisição HTTP normal com um cabeçalho Host malformado ou uma requisição de upgrade de WebSocket para o endpoint `/ws` com um cabeçalho Origin malformado. Os valores malformados disparam uma exceção não capturada no caminho de validação do host, derrubando o servidor de desenvolvimento. O impacto limita-se à disponibilidade do servidor, sem risco de execução de código ou divulgação de dados.

Os endpoints internos de desenvolvedor '/webpack-dev-server/open-editor' e '/webpack-dev-server/invalidate' executam ações de alteração de estado em requisições GET sem verificar a origem da requisição. Isso permite que qualquer site visitado por um desenvolvedor acione esses endpoints de forma cross-origin. Um invasor pode abrir arquivos locais arbitrários no editor do desenvolvedor, incluindo arquivos fora da raiz do projeto. Além disso, requisições repetidas podem gerar múltiplos processos do editor e forçar recompilações, resultando na degradação do desempenho da máquina do desenvolvedor.

Um problema de Negação de Serviço ocorre ao utilizar diskStorage. Uploads multipart abortados ou malformados deixam arquivos parciais órfãos no disco porque a chamada `Readable.pipe()` não propaga o sinal de destruição do fluxo para o `fs.WriteStream` subjacente. Isso permite que um invasor esgote o espaço em disco disparando inúmeros uploads abortados.

Um proxy configurado pelo usuário com um contexto amplo (ex: '/') e `ws: true` intercepta o WebSocket de Hot Module Replacement (HMR) do próprio servidor de desenvolvimento e o encaminha para o alvo do proxy. Isso resulta no vazamento de cookies do navegador e do cabeçalho Origin para o backend, além de ignorar a validação de Host/Origin do servidor de desenvolvimento. Adicionalmente, isso causa a corrupção do socket HMR, pois tanto o HMR quanto o proxy tentam escrever no mesmo socket.