Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A fragmented TLS ClientHello whose handshake header spans multiple records makes Netty silently fall back to the default SslContext; where per-SNI selection is the sole mTLS gate, an unauthenticated attacker can bypass the route's mTLS requirement. Details In io.netty.handler.ssl.SslClientHelloHandler#decode the guard that should wait for the 4-byte handshake header checks the wrong offset - it ignores the 5-byte record header that precedes it - and therefore never fires: When the first record's payload is < 4 bytes, handshakeLength = in.getUnsignedMedium(readerIndex + SslUtils.SSLRECORDHEADERLENGTH + 1); leads to IndexOutOfBoundsException . That is caught by the generic catch (Exception) block, which calls select(ctx, null) - this is the default SslContext. Fallback to default on parse failure is a problem when per-SNI selection is the sole mTLS gate. Impact SNI routing bypass. Escalates to an unauthenticated mTLS bypass only when: - mTLS is enforced solely via per-SNI…
Recommended action: Upgrade to 4.2.17.Final or 4.1.137.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netty's default SNI entrypoint reparses and recopies previously received ClientHello fragments on every additional TLS handshake record. A remote peer can send a small first record that advertises a large ClientHello length and then drip the body in many tiny records, causing superlinear (quadratic) CPU work before the handshake completes. With 4095 one-byte fragments, the handler recopies 8,386,560 bytes from only 24,579 bytes on the wire — a 341× amplification ratio. Affected Entrypoints - io.netty.handler.ssl.SniHandler — default constructors - io.netty.handler.ssl.SslClientHelloHandler — pre-handshake ClientHello aggregation path Vulnerable Code Locations - handler/src/main/java/io/netty/handler/ssl/SniHandler.java:85 - handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:75 (decode entry) - handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:165 (handshakeBuffer.clear) -…
Recommended action: Upgrade to 4.2.17.Final or 4.1.137.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all.
Recommended action: Upgrade to 4.2.15.Final or 4.1.135.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates ctx.alloc().buffer(handshakeLength) (line 161). The guard at line 140 is handshakeLength maxClientHelloLength && maxClientHelloLength != 0, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes.
Recommended action: Upgrade to 4.2.15.Final or 4.1.135.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can bypass IPv6 subnet rules due to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid public IP addresses can bypass the restrictions. Details io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress) method performs a bitwise AND between the incoming IP address and the configured networkAddress, instead of the subnetMask. Impact Access Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.
Recommended action: Upgrade to 4.2.15.Final or 4.1.135.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. Workarounds As workaround its possible to either disable the usage of the native SSLEngine or changing the code from: to:
Recommended action: Upgrade to 4.1.118.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SniHandler can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the SniHandler to allocate 16MB of heap. Details The SniHandler class is a handler that waits for the TLS handshake to configure a SslHandler according to the indicated server name by the ClientHello record. For this matter it allocates 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 not checks done here and the way the code is written, it is possible to craft a packet that makes the SslClientHelloHandler 1/ allocate a 16MB ByteBuf 2/ not fail decode method in buffer 3/ get out of the loop without an exception The combination of this without the use of a timeout makes easy to connect to a TCP server and allocate 16MB of heap memory per connection. Impact If the user has no idle…
Recommended action: Upgrade to 4.1.94.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
handler/ssl/OpenSslEngine.java in Netty 4.0.x before 4.0.37.Final and 4.1.x before 4.1.1.Final allows remote attackers to cause a denial of service (infinite loop).
Recommended action: Upgrade to 4.1.1.Final or 4.0.37.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SslHandler in Netty before 3.9.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted SSLv2Hello message.
Recommended action: Upgrade to 3.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ZlibDecoders in Netty 4.1.x before 4.1.46 allow for unbounded memory allocation while decoding a ZlibEncoded byte stream. An attacker could send a large ZlibEncoded byte stream to the Netty server, forcing the server to allocate all of its free memory to a single decoder.
Recommended action: Upgrade to 4.1.46 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netty 4.1.43.Final allows HTTP Request Smuggling because it mishandles Transfer-Encoding whitespace (such as a [space]Transfer-Encoding:chunked line) and a later Content-Length header. This issue exists because of an incomplete fix for CVE-2019-16869.
Recommended action: Upgrade to 4.1.45 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.