Jason Lee

**Nome do software vulnerável e versões afetadas** Versões do Undertow anteriores à 2.2.19.Final Versões do Undertow anteriores à 2.3.0.Alpha2 **Descrição** Quando uma solicitação POST chega pelo AJP e a solicitação excede o limite de tamanho máximo (maxEntitySize), a implementação AjpServerRequestConduit do Undertow fecha a conexão sem enviar nenhuma resposta ao cliente/proxy. Esse comportamento faz com que um proxy front-end marque o worker back-end (servidor de aplicativos) como estando em estado de erro e não encaminhe solicitações para o worker por um tempo. No mod cluster, isso continua até que a próxima solicitação STATUS (em intervalos de 10 segundos) do servidor de aplicativos atualize o estado do servidor. Assim, na pior das hipóteses, isso pode resultar em “Todos os workers estão em estado de erro” e o mod cluster responde “503 Serviço indisponível” por um tempo (até 10 segundos). No mod proxy balancer, ele não encaminha solicitações para o worker até que o tempo limite de “retry” expire. No entanto, felizmente, o mod proxy balancer possui a configuração “forcerecovery” (ativada por padrão; esse parâmetro pode forçar a recuperação imediata de todos os workers sem considerar o parâmetro de retry dos workers se todos os workers de um balanceador estiverem em estado de erro). Um invasor poderia usar esse comportamento para enviar uma solicitação maliciosa e provocar erros no servidor, resultando em DoS (negação de serviço). **Recomendações** Para versões do Undertow anteriores à 2.2.19.Final, atualize para o Undertow 2.2.19.Final ou posterior. Para versões do Undertow anteriores à 2.3.0.Alpha2, atualize para o Undertow 2.3.0.Alpha

**Name of the Vulnerable Software and Affected Versions** curl version 7.65.2 **Description** The issue is related to an integer overflow vulnerability in the `tool operate.c` file of curl, which can occur when a large value is specified as the retry delay. This may cause a denial of service to associated systems or networks if the `--retry-delay` is misinterpreted as a value much smaller than intended. However, many parties report that this has no direct security impact on the curl user. The vulnerability may be exploited to cause a denial of service, but this is not especially plausible as it only happens if the user was trying to specify that curl should wait weeks or longer before trying to recover from a transient error. **Recommendations** For curl version 7.65.2, consider updating to a newer version to mitigate the risk of exploitation, although the security impact of this issue is disputed. As a temporary workaround, consider avoiding the use of large values for the `--retry-delay` option to minimize the risk of denial of service.