Vietj

**Nome do software vulnerável e versões afetadas** Versões do Netty anteriores à 4.1.108.Final **Descrição** O problema está relacionado ao `HttpPostRequestDecoder` no Netty, que pode ser induzido a acumular dados sem limites. Isso pode ser feito enviando uma solicitação POST fragmentada composta por muitos campos pequenos que serão acumulados na lista `bodyListHttpData`, ou acumulando bytes no buffer `undecodedChunk` até que um campo possa ser decodificado. A vulnerabilidade pode ser explorada para causar uma negação de serviço. **Recomendações** Para versões do Netty anteriores à 4.1.108.Final, atualize para a versão 4.1.108.Final ou posterior para resolver o problema. Como solução temporária, considere restringir o número de campos que podem ser acumulados na lista `bodyListHttpData` ou limitar o tamanho do buffer `undecodedChunk` para evitar o acúmulo excessivo de dados.

**Nome do software vulnerável e versões afetadas** Versões do Eclipse Vert.x anteriores à 4.4.7 Versões do Eclipse Vert.x anteriores à 4.5.2 **Descrição** Ocorre um vazamento de memória no kit de ferramentas Eclipse Vert.x devido ao uso de estruturas de dados Netty FastThreadLocal. Esse problema é desencadeado quando o cliente HTTP do Vert.x estabelece conexões com diferentes hosts. Um invasor pode explorar essa vulnerabilidade acelerando o vazamento de memória, especialmente se um servidor aceitar endereços de internet arbitrários e se conectar a esses endereços. **Recomendações** Para versões do Eclipse Vert.x anteriores à 4.4.7, atualize para a versão 4.4.7 para resolver o problema. Para versões do Eclipse Vert.x anteriores à 4.5.2, atualize para a versão 4.5.2 para resolver o problema.

**Name of the Vulnerable Software and Affected Versions** Netty versions prior to 4.1.94.Final **Description** The issue is related to the `SniHandler` class in Netty, which can allocate up to 16MB of heap for each channel during the TLS handshake. This can be exploited to cause a denial of service, potentially leading to an OutOfMemoryError. The `SniHandler` waits for the TLS handshake to configure a `SslHandler` according to the indicated server name by the `ClientHello` record, allocating a `ByteBuf` using the value defined in the `ClientHello` record. Normally, the value of the packet should be smaller than the handshake packet, but there are no checks done here, and it is possible to craft a packet that makes the `SslClientHelloHandler` allocate a large amount of memory. **Recommendations** For versions prior to 4.1.94.Final, update to version 4.1.94.Final to fix the issue. As a temporary workaround, consider configuring an idle timeout handler to prevent excessive memory allocation. Restrict access to the `SniHandler` to minimize the risk of exploitation. Avoid using the `SniHandler` without proper configuration and monitoring to prevent potential denial of service attacks.

**Name of the Vulnerable Software and Affected Versions** Vert.x-Web (affected versions not specified) **Description** The issue affects Vert.x-Web applications that serve files using `StaticHandler` on Windows Operating Systems and Windows File Systems. When the mount point is a wildcard (`*`), an attacker can exfiltrate any class path resource. The problem arises from the `Utils.java` code, which returns user input without validation as the segment to lookup, allowing an attacker to build a valid path within the classpath by exploiting improper handling of ``. This issue only affects users deploying in Windows environments. **Recommendations** As a temporary workaround, consider disabling the `StaticHandler` function until a patch is available. Restrict access to the `StaticHandler` module to minimize the risk of exploitation. Avoid using the `StaticHandler` with wildcard mount points until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Eclipse Vert.x versions 3.0.0 through 3.5.3 **Description** The WebSocket HTTP upgrade implementation in Eclipse Vert.x buffers the full HTTP request before doing the handshake, holding the entire request body in memory. It is recommended to have a reasonable limit, above which the WebSocket gets an HTTP response with the 413 status code and the connection gets closed. The suggested limit is 8192 bytes. **Recommendations** For Eclipse Vert.x versions 3.0.0 through 3.5.3, consider implementing a limit on the HTTP request body size to prevent excessive memory usage, and return an HTTP response with the 413 status code when this limit is exceeded.