Bug#1143052: netty: CVE-2026-56821 CVE-2026-56822 CVE-2026-59898 CVE-2026-59899 CVE-2026-59900 CVE-2026-59901 CVE-2026-59919 CVE-2026-59920 CVE-2026-59921

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