Hi,

The following vulnerabilities were published for netty.

CVE-2026-59902[0]:
| Netty is an asynchronous, event-driven network application
| framework. Prior to 4.1.137.Final and 4.2.17.Final,
| io.netty.handler.codec.sctp.SctpMessageCompletionHandler limits
| incomplete messages and fragment counts but not maxBufferedBytes,
| allowing unauthenticated peers to exhaust memory with large SCTP
| fragments. This issue is fixed in versions 4.1.137.Final and
| 4.2.17.Final.


CVE-2026-59903[1]:
| Netty is an asynchronous, event-driven network application
| framework. Prior to 4.1.137.Final and 4.2.17.Final,
| io.netty.handler.codec.http.cors.CorsHandler setVaryHeader replaces
| application Vary headers such as Authorization or Cookie with
| Origin, allowing a caching proxy or CDN to reuse authenticated
| responses across users and disclose sensitive information. This
| issue is fixed in versions 4.1.137.Final and 4.2.17.Final.


CVE-2026-75595[2]:
| Netty is an asynchronous, event-driven network application
| framework. Prior to 4.1.137.Fina and 4.2.17.Final,
| io.netty.handler.ssl.SslClientHelloHandler#decode checks the wrong
| offset before reading the four-byte TLS handshake header, so a
| ClientHello whose handshake header spans records can cause an
| IndexOutOfBoundsException and invoke select(ctx, null). This selects
| the default SslContext instead of the SNI-specific context. In
| deployments where per-SNI clientAuth=REQUIRE is the sole mutual TLS
| gate, the default SslContext uses clientAuth=NONE or
| clientAuth=OPTIONAL, and no application-layer certificate
| verification exists, an unauthenticated remote attacker can bypass
| the protected route's mutual TLS requirement. This issue is fixed in
| versions 4.1.137.Final and 4.2.17.Final.


CVE-2026-75596[3]:
| Netty is an asynchronous, event-driven network application
| framework. Prior to 4.1.137.Final and 4.2.17.Final, the default
| io.netty.handler.ssl.SniHandler constructors use the pre-handshake
| ClientHello aggregation path in handler/src/main/java/io/netty/handl
| er/ssl/SslClientHelloHandler.java at
| io.netty.handler.ssl.SslClientHelloHandler#decode, where
| handshakeBuffer.clear() and writeBytes() recopy all previously
| received body bytes for every additional TLS record. An
| unauthenticated remote peer can advertise a large ClientHello and
| deliver its body in thousands of tiny records, causing quadratic CPU
| work on the event loop before the TLS handshake completes and
| degrading TLS handling for other clients. This issue is fixed in
| versions 4.1.137.Final and 4.2.17.Final.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2026-59902
https://www.cve.org/CVERecord?id=CVE-2026-59902
[1] https://security-tracker.debian.org/tracker/CVE-2026-59903
https://www.cve.org/CVERecord?id=CVE-2026-59903
[2] https://security-tracker.debian.org/tracker/CVE-2026-75595
https://www.cve.org/CVERecord?id=CVE-2026-75595
[3] https://security-tracker.debian.org/tracker/CVE-2026-75596
https://www.cve.org/CVERecord?id=CVE-2026-75596

Regards,
Salvatore