Vietj

**Name of the Vulnerable Software and Affected Versions** Netty versions prior to 4.1.108.Final **Description** The issue is related to the `HttpPostRequestDecoder` in Netty, which can be tricked to accumulate data without limits. This can be achieved by sending a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list, or by cumulating bytes in the `undecodedChunk` buffer until a field can be decoded. The vulnerability can be exploited to cause a denial of service. **Recommendations** For Netty versions prior to 4.1.108.Final, update to version 4.1.108.Final or later to resolve the issue. As a temporary workaround, consider restricting the number of fields that can be accumulated in the `bodyListHttpData` list or limiting the size of the `undecodedChunk` buffer to prevent excessive data accumulation.

**Name of the Vulnerable Software and Affected Versions** Eclipse Vert.x versions prior to 4.4.7 Eclipse Vert.x versions prior to 4.5.2 **Description** A memory leak occurs in the Eclipse Vert.x toolkit due to the use of Netty FastThreadLocal data structures. This issue is triggered when the Vert.x HTTP client establishes connections to different hosts. An attacker can exploit this vulnerability by accelerating the memory leak, particularly if a server accepts arbitrary internet addresses and connects to these addresses. **Recommendations** For Eclipse Vert.x versions prior to 4.4.7, update to version 4.4.7 to resolve the issue. For Eclipse Vert.x versions prior to 4.5.2, update to version 4.5.2 to resolve the issue.

**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.