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. This is the next batch of CVEs, fixed in 4.1.136.Final. CVE-2026-56821[0]: | Netty is an asynchronous, event-driven network application | framework. Prior to versions 4.1.136.Final and 4.2.16.Final, the | OcspServerCertificateValidator flags an out-of-date OCSP response | but does not stop processing it, so an expired GOOD response is | still reported as VALID, letting an on-path attacker replay a stale | GOOD response to bypass revocation of a since-revoked certificate. | Exploitation can lead to certificate revocation bypass via replay of | an expired OCSP response. Any application using | OcspServerCertificateValidator is affected; a revoked certificate | can be accepted. This issue has been fixed in versions 4.1.136.Final | and 4.2.16.Final. CVE-2026-56822[1]: | Netty is an asynchronous, event-driven network application | framework. Prior to versions 4.1.136.Final and 4.2.16.Final, the | OcspServerCertificateValidator forwards the | SslHandshakeCompletionEvent before the asynchronous OCSP validation | completes. This allows the client's downstream handlers to send | sensitive application data (e.g., HTTP requests) to a revoked server | before the channel is closed by the OCSP check. n io.netty.handler.s | sl.ocsp.OcspServerCertificateValidator#userEventTriggered, when an | SslHandshakeCompletionEvent is received, the validator immediately | calls ctx.fireUserEventTriggered(evt). It then initiates an | asynchronous OCSP query using OcspClient.query. Because the | handshake completion event is forwarded immediately, downstream | handlers in the client's pipeline are notified that the TLS | handshake is successful. They may then begin reading and processing | incoming application data or sending outgoing data. If the OCSP | response later indicates the server's certificate is REVOKED, the | validator closes the channel, but by this time, the client may have | already leaked sensitive data to a revoked server or processed | malicious responses from it. This issue has been fixed in versions | 4.1.136.Final and 4.2.16.Final. CVE-2026-59898[2]: | Netty is an asynchronous, event-driven network application | framework. Prior to versions 4.1.136.Final and 4.2.16.Final, ab | attacker can force WebSocket upgrade via the lax V07 (or V08) | handshaker by sending `Sec-WebSocket-Version: 7` and omitting | `Connection: Upgrade` / `Upgrade: websocket` headers, completing a | protocol switch that a proxy would not recognize as an Upgrade | request and enabling HTTP request smuggling / protocol-confusion | attacks. This issue has been fixed in versions 4.1.136.Final and | 4.2.16.Final. CVE-2026-59899[3]: | Netty is an asynchronous, event-driven network application | framework. Prior to versions 4.1.136.Final and 4.2.16.Final, | `HttpContentEncoder` (the superclass of the production handler | `HttpContentCompressor`) maintains a per-channel | `ArrayDeque<CharSequence>` named `acceptEncodingQueue` that | accumulates attacker-controlled data without any size limit. The | queue is filled on the I/O thread for every inbound HTTP request and | drained only when the application later writes a non-1xx response. | This creates a resource exhaustion vulnerability when an attacker | exploits HTTP/1.1 pipelining to flood the connection with requests | faster than the application produces responses. This issue has been | fixed in versions 4.1.136.Final and 4.2.16.Final. CVE-2026-59900[4]: | Netty is an asynchronous, event-driven network application | framework. Prior to versions 4.1.136.Final and 4.2.16.Final, Netty's | HTTP/2-to-HTTP/1.x translation layer | (`Http2StreamFrameToHttpObjectCodec` and | `InboundHttp2ToHttpAdapter`) fails to deduplicate or validate `Host` | headers when an HTTP/2 client supplies both the `:authority` pseudo- | header and a literal `host` header in a single HEADERS frame. The | translator maps `:authority` to `Host` and separately copies the | literal `host` header, producing an `HttpRequest` object containing | two `Host` headers with attacker-controlled differing values. This | issue has been fixed in versions 4.1.136.Final and 4.2.16.Final. CVE-2026-59901[5]: | Netty is an asynchronous, event-driven network application | framework. Prior to versions 4.1.136.Final and 4.2.16.Final, the | `Bzip2Decoder` handler in Netty's compression codec pipeline is | vulnerable to a denial-of-service attack through a malformed bzip2 | stream that permanently captures the event-loop thread in an | infinite loop. The vulnerability exists in the run-length encoding | (RLE) state machine within [`Bzip2BlockDecompressor.read()`]. This | issue has been fixed in versions 4.1.136.Final and 4.2.16.Final. CVE-2026-59919[6]: | Netty is an asynchronous, event-driven network application | framework. In versions prior to 4.1.136.Final and 4.2.16.Final, | Netty's HAProxy encoder ( HAProxyMessageEncoder ) writes AF_UNIX | source and destination socket addresses into the HAProxy V1 text | protocol without validating them for CRLF characters, so an attacker | who controls an AF_UNIX address can inject \r\n sequences and | split the single PROXY header into multiple lines. This is possible | because the V1 protocol uses CRLF as its line terminator and, unlike | IPv4/IPv6 addresses whose format checks implicitly reject CRLF, | AF_UNIX addresses are only validated for length (up to 108 bytes), | allowing a forged second PROXY header line that spoofs the client | source/destination IP to a downstream server or load balancer. The | issue is fixed in versions 4.1.136.Final and 4.2.16.Final. CVE-2026-59920[7]: | Netty is an asynchronous, event-driven network application | framework. In versions prior to 4.1.136.Final and 4.2.16.Final, | Netty's STOMP encoder ( StompSubframeEncoder ) does not escape or | validate header values in CONNECT and CONNECTED frames, so raw | newline ( \n ) characters in a header value are written directly to | the wire, allowing an attacker who controls a header value to inject | additional STOMP headers. This happens because the encoder | intentionally skips escaping for CONNECT/CONNECTED frames per the | STOMP 1.2 specification but never rejects the raw newlines, and | since a broker parses each line as a separate header, an attacker | controlling a value such as a user-supplied login or passcode can | overwrite connection parameters or add authentication/role headers | to bypass authentication or escalate privileges (the actual impact | is broker-dependent). The issue is fixed in versions 4.1.136.Final | and 4.2.16.Final. CVE-2026-59921[8]: | Netty is an asynchronous, event-driven network application | framework. Prior to versions 4.1.136.Final and 4.2.16.Final, | HttpPostRequestEncoder constructs multipart HTTP request bodies by | directly concatenating user-supplied filenames and field names into | Content-Disposition MIME headers without validating or sanitizing | CRLF characters (\r\n). Since MIME headers are delimited by CRLF, an | attacker who controls the filename can inject arbitrary MIME headers | into the multipart body part. The root cause is that neither the | encoder nor the FileUpload implementations' setFilename() methods, | which only check for null, neutralize CRLF characters before the | filename is embedded into the header. This issue has been fixed in | versions 4.1.136.Final and 4.2.16.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-56821 https://www.cve.org/CVERecord?id=CVE-2026-56821 [1] https://security-tracker.debian.org/tracker/CVE-2026-56822 https://www.cve.org/CVERecord?id=CVE-2026-56822 [2] https://security-tracker.debian.org/tracker/CVE-2026-59898 https://www.cve.org/CVERecord?id=CVE-2026-59898 [3] https://security-tracker.debian.org/tracker/CVE-2026-59899 https://www.cve.org/CVERecord?id=CVE-2026-59899 [4] https://security-tracker.debian.org/tracker/CVE-2026-59900 https://www.cve.org/CVERecord?id=CVE-2026-59900 [5] https://security-tracker.debian.org/tracker/CVE-2026-59901 https://www.cve.org/CVERecord?id=CVE-2026-59901 [6] https://security-tracker.debian.org/tracker/CVE-2026-59919 https://www.cve.org/CVERecord?id=CVE-2026-59919 [7] https://security-tracker.debian.org/tracker/CVE-2026-59920 https://www.cve.org/CVERecord?id=CVE-2026-59920 [8] https://security-tracker.debian.org/tracker/CVE-2026-59921 https://www.cve.org/CVERecord?id=CVE-2026-59921 Regards, Salvatore __ This is the maintainer address of Debian's Java team <https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use [email protected] for discussions and questions.
