{
 "version": "https://jsonfeed.org/version/1.1",
 "title": "netty: all CVE events",
 "home_page_url": "https://patchwire.jonathanross.dev/products/netty--netty/",
 "feed_url": "https://patchwire.jonathanross.dev/feeds/products/netty--netty/all.json",
 "authors": [
  {
   "name": "Patchwire"
  }
 ],
 "language": "en",
 "items": [
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-100666/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-100666/",
   "title": "CVE-2026-100666 · netty · disclosed",
   "content_text": "Netty's HttpServerCodec (io.netty:netty-codec-http) in versions 4.2.0.Final through 4.2.16.Final and in versions up to and including 4.1.136.Final pairs each outbound response with an inbound request by calling pollMethod() once per response, including for 1xx informational responses. If a client pipelines an HTTP/1.1 GET carrying an Expect: 100-continue header followed by a HEAD request, the 100 Continue response consumes the queued GET method, so the subsequent 200 OK for the GET is paired with HEAD and its body is dropped, while the following 200 OK for the HEAD request is written with a body. This desynchronizes HTTP parsing on the connection: the GET entity is never delivered and the HEAD response body is interpreted as the GET body, resulting in response splitting and unsafe connection reuse. Fixed in 4.2.17.Final and 4.1.137.Final.",
   "date_published": "2026-09-26T13:23:31Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-100665/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-100665/",
   "title": "CVE-2026-100665 · netty · disclosed",
   "content_text": "Netty versions from 4.2.11.Final before 4.2.18.Final contain an incomplete hostname verification fix in the QUIC certificate verification path when using a plain X509TrustManager. The BoringSSLCertificateVerifyCallback discards the SSLEngine for plain trust managers, preventing endpoint identification from running even when HTTPS verification is configured. Attackers on the network path can present a certificate chain for the wrong hostname that the plain trust manager accepts, bypassing hostname authentication for QUIC clients.",
   "date_published": "2026-09-26T13:23:31Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-100664/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-100664/",
   "title": "CVE-2026-100664 · netty · disclosed",
   "content_text": "Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.2.Final through 4.2.17.Final builds the HTTP/3 :authority pseudo-header from the HTTP/1 Host header before considering the authority of an absolute-form HTTP/1 request-target. In HttpConversionUtil.toHttp3Headers(HttpMessage, boolean) — reached via Http3FrameToHttpObjectCodec(false) — a non-empty Host header takes precedence over the request-target authority, contrary to the HTTP/1.1 rule that a server receiving an absolute-form request-target must ignore the Host header. In a Netty-based HTTP/1-to-HTTP/3 gateway, proxy, or protocol bridge, a remote client can send a request such as \"GET https://trusted.example/admin HTTP/1.1\" with \"Host: attacker.example\", causing components that validate, authorize, or route on the RFC-defined request-target authority to reach a different decision than the upstream HTTP/3 peer, which receives :authority derived from the conflicting Host header. This authority confusion can affect virtual-host routing, allow-list checks, backend selection, cache keys, and URL generation. The advisory reports integrity impact only (no code execution, memory corruption, or availability impact). Fixed in 4.2.18.Final.",
   "date_published": "2026-09-26T13:23:30Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-100663/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-100663/",
   "title": "CVE-2026-100663 · netty · disclosed",
   "content_text": "Netty's HTTP/3 codec (io.netty:netty-codec-http3) from 4.2.2.Final through 4.2.17.Final does not special-case HTTP/1 CONNECT authority-form request-targets when converting HTTP/1 messages to HTTP/3 in HttpConversionUtil.toHttp3Headers. The authority-form target (e.g., \"CONNECT trusted.example:443\") is parsed as a URI, so its host is emitted as :scheme, :path is set to \"/\", and the HTTP/1 Host header is used as :authority; if no Host header is present the CONNECT target is dropped. In a Netty-based HTTP/1-to-HTTP/3 proxy or gateway, a remote client can send a CONNECT request whose Host header names a different authority than the request-target, producing a malformed HTTP/3 CONNECT whose tunnel :authority is attacker-controlled. This can bypass tunnel allow-lists, egress policy, backend selection, or audit controls that validate the HTTP/1 CONNECT request-target before forwarding over HTTP/3. The issue is fixed in 4.2.18.Final.",
   "date_published": "2026-09-26T13:23:29Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-100662/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-100662/",
   "title": "CVE-2026-100662 · netty · disclosed",
   "content_text": "Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final contain an uncontrolled resource consumption vulnerability in the QPACK encoder-stream instruction decoder (QpackEncoderHandler, installed on the peer-initiated unidirectional QPACK encoder stream, type 0x02). The handler accepts an attacker-declared string-literal length of up to Integer.MAX_VALUE (~2 GiB) for the Name Length and Value Length fields of the \"Insert With Literal Name\" instruction (RFC 9204 §4.3.3), with no per-instruction or per-literal length cap and no cumulation-size limit; the existing HTTP/3 limits (maxHeaderListSize, maxUnknownFramePayloadLength, DEFAULT_MAX_FIELD_SECTION_SIZE) are not applied to this handler. A remote, unauthenticated peer with an established HTTP/3 connection to a default Netty HTTP/3 server can declare a very large literal length and then trickle fewer bytes than declared, causing the ByteToMessageDecoder MERGE cumulator to retain and grow the per-connection buffer, and ultimately triggering a large byte-array allocation. This leads to unbounded per-connection heap growth and OutOfMemoryError, resulting in denial of service. Fixed in 4.2.18.Final.",
   "date_published": "2026-09-26T13:23:28Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-100661/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-100661/",
   "title": "CVE-2026-100661 · netty · disclosed",
   "content_text": "Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final contain a denial-of-service vulnerability in the QPACK prefixed-integer decoder (QpackUtil.decodePrefixedInteger), which does not bound the number of continuation bytes it will process. A remote, unauthenticated peer can open a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and send a first byte with all prefix bits set (e.g. 0xFF for a 7-bit prefix or 0x3F for a 5-bit prefix) followed by an endless run of 0x80 continuation bytes. The decoder returns -1 ('need more bytes'), so callers never consume the input, the ByteToMessageDecoder cumulator grows without bound, and each decode() invocation re-scans the whole accumulated buffer, yielding O(N^2) CPU cost. The result is unbounded per-connection heap growth (OutOfMemoryError) and event-loop CPU starvation, reachable in every configuration. Fixed in 4.2.18.Final.",
   "date_published": "2026-09-26T13:23:28Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-100660/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-100660/",
   "title": "CVE-2026-100660 · netty · disclosed",
   "content_text": "Netty's HTTP/3 codec (io.netty:netty-codec-http3) from 4.2.0.Final through 4.2.17.Final retains unbounded per-stream QPACK encoder state. QpackEncoder stores a queue and a dynamic-table index tracker for every encoded field section that references the QPACK dynamic table, keyed by the peer-controlled QUIC stream ID, and these entries are released only when the remote decoder sends a Section Acknowledgment or Stream Cancellation instruction — not when the HTTP/3 stream completes. There is no limit on the number of tracked streams, field sections, or retained bytes. A remote, unauthenticated HTTP/3 client can advertise a non-zero QPACK dynamic-table capacity, acknowledge the table insertion so the server reuses a dynamically indexed response header, and then omit all mandatory Section Acknowledgments while issuing sequential requests over a single QUIC connection, bypassing concurrent-stream limits and causing unbounded heap growth until the server exhausts memory (denial of service). Fixed in 4.2.18.Final.",
   "date_published": "2026-09-26T13:23:27Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-100659/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-100659/",
   "title": "CVE-2026-100659 · netty · disclosed",
   "content_text": "Netty's HTTP/3 codec (io.netty:netty-codec-http3) in versions 4.2.0.Final through 4.2.17.Final does not enforce the RFC 9114 requirement that the :authority pseudo-header field and a literal host header field, when both present, carry the same value. A remote unauthenticated peer can send a single HEADERS frame containing both fields with differing, attacker-controlled values; the request is accepted and delivered to the application with two conflicting authorities, allowing routing, virtual-host, and access-control decisions to be bypassed when different components in the request path consult different fields. This issue is fixed in 4.2.18.Final.",
   "date_published": "2026-09-26T13:23:26Z"
  }
 ]
}