Source: netty Version: 1:4.1.48-16 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
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
