Phillip9587

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.

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.

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.