Serguey Asael Shinder: Netty 4.2.20 and 4.1.140 fix ten advisories, including an mTLS bypass via session resumption
The Netty project released 4.2.20.Final and 4.1.140.Final on 2 November, both opening their notes with a Security Fixes section. The 4.2 release lists ten GitHub security advisories, the 4.1 release eight of the same ones. (https://github.com/netty/netty/releases/tag/netty-4.2.20.Final, https://github.com/netty/netty/releases/tag/netty-4.1.140.Final)
The one with the widest consequence is described as an mTLS authentication bypass via session resumption, in netty-handler and, on 4.2, also in netty-codec-quic (GHSA-6xv6-9mgg-mfvc). The others, as the release notes label them: three out-of-bounds reads in netty-buffer (GHSA-m77g-r4c7-3w77, GHSA-rx4g-qxm6-238r, GHSA-qhw9-p586-v948); insufficient entropy in netty-resolver-dns (GHSA-cqmg-wc9g-fpj8); unbounded memory usage in netty-codec-http2 (GHSA-hc9x-r52h-gh4x) and in netty-codec-mqtt (GHSA-84gx-4cj4-rm7q); and insufficient control character neutralisation in netty-codec-http (GHSA-42mp-m8rq-6rgj). Two apply only to 4.2: inefficient CPU computation in netty-codec-http3 (GHSA-v2v6-vch9-4pcg) and a use-after-free in netty-codec-classes-quic (GHSA-w53r-xhgx-8582).
The change lists add hardening around the same areas, among them no longer spinning in SslHandler.wrapMultiple(...) when the engine consumes nothing, validating the padding of HTTP/2 HEADERS frames without priority, rejecting Redis lines that start with LF, and choosing TLS 1.3 server key types from the client's signature algorithms.
The practical point is the same as a month ago, when 4.2.19 and 4.1.139 shipped sixteen advisories: almost nobody depends on Netty directly. It arrives through gRPC, Reactor Netty, Vert.x, Spring WebFlux, the AWS SDK and many drivers, so the version that counts is the one your build actually resolves. mvn dependency:tree -Dincludes=io.netty or gradle dependencyInsight --dependency netty-handler shows it; if the framework pins an older Netty, overriding it in dependency management is usually safe within a minor line, and the 4.1 branch got its own release for exactly that case. Services that rely on client certificates and allow TLS session resumption have the strongest reason not to wait for the next framework release.