Netty
Monthly
netty-tcnative 2.0.83.Final and earlier can be driven into denial of service or silent TLS message corruption by ordinary TLS 1.3 traffic, because the tcn_write_to_bytebuffer BIO_write callback in ssl.c reports more bytes consumed than the caller actually asked to write. The inflation occurs when the internal side buffer (populated by queued post-handshake records such as NewSessionTicket, KeyUpdate or alerts) is non-empty at the moment a write-sink BIO_write runs, and the outcome is backend-specific: BoringSSL silently corrupts handshake or application data on the wire, an adjacent BoringSSL post-handshake path can abort the JVM process outright, and LibreSSL permanently wedges the connection's write path. The independent assessment rates this CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H - unauthenticated remote and requiring the coincidence of queued side-buffer data with a write-mode flush - while a public proof-of-concept reproduction is documented in the upstream advisory; it is not verified as turnkey exploit code and there is no CISA KEV confirmation of active exploitation at time of analysis.
A use-after-free in netty-tcnative 2.0.66.Final through 2.0.83.Final builds linked against OpenSSL 3.0 or newer lets a TLS handshake crash the server process when it issues or resumes a session ticket at the same moment the operator rotates ticket keys through SSLContext.setSessionTicketKeys0(). The handshake side of the race is reachable by unauthenticated remote clients (PR:N, UI:N), but the limiting precondition is the operator-initiated rotation happening inside a window only a few CPU instructions wide, which is why the assessed vector carries AT:P and AC:H and the reported CVSS 4.0 score of 8.2 resolves to an assessed CVSS 3.1 base of 5.9 with confidentiality and integrity impact unconfirmed and only availability (A:H) demonstrated. No CISA KEV entry exists and no weaponized exploit code has been identified, though the public advisory documents a reporter-side, repeatable SIGSEGV reproduction on a real compiled openssl-dynamic build using a race-widened test harness; patched builds are available and the priority label is this_week.
Heap buffer overflow in netty-tcnative's custom OpenSSL BIO wrapper (all releases through 2.0.83.Final, including netty-tcnative-boringssl-static) allows a remote TLS peer to crash the JVM process by pushing handshake continuation, renegotiation, or TLS 1.3 post-handshake bytes through the internal nonApplicationBuffer ring buffer until its un-normalized write index exceeds the buffer size, after which a memcpy runs with an out-of-bounds pointer and a negative length cast to size_t. No authentication or user interaction is required (PR:N/UI:N), but reliability is limited by the CVSS 4.0 AT:P flag: the overflow only materializes when the integrating application chose a comparatively small nonApplicationBufferSize via SSL.bioNewByteBuffer and traffic arrives in write/partial-drain cycles that never fully empty the buffer. The assessed impact is availability-only (VA:H) - a deterministic process crash - with no confirmed confidentiality or integrity effect; no CISA KEV listing exists and no released working exploit code was identified at time of analysis, although the upstream advisory documents a deterministic reproduction PoC built from the public JNI API.
Hostname verification bypass in Netty's QUIC client affects versions 4.2.11.Final through 4.2.17.Final when the application supplies a plain javax.net.ssl.X509TrustManager rather than an X509ExtendedTrustManager, allowing an attacker positioned on the network path to present a certificate chain for the wrong hostname that the trust manager still accepts. In practice exploitation requires an active man-in-the-middle position rather than a trivial remote attack, since the attacker must intercept the QUIC connection and hold a valid-but-mis-matched certificate; the CVSS 4.0 score of 8.7 (AV:N/AC:L/PR:N/UI:N) overstates this precondition. No public exploit code was identified at time of analysis, and clients using X509ExtendedTrustManager are not affected; Netty 4.2.18.Final resolves the issue.
Authority confusion in Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.2.Final through 4.2.17.Final allows a remote, unauthenticated attacker to make a Netty-based HTTP/1-to-HTTP/3 gateway validate, authorize, or route a request against a different authority than the one its upstream HTTP/3 peer actually receives. The flaw only manifests in gateway, proxy, or protocol-bridge deployments that pass HTTP/1 messages through Http3FrameToHttpObjectCodec(false) and then make security decisions (allow-lists, virtual-host routing, backend selection, cache keys, URL generation) based on the absolute-form request-target authority; a request such as 'GET https://trusted.example/admin HTTP/1.1' with 'Host: attacker.example' yields an RFC-compliant authority at the front door and an attacker-chosen :authority upstream. Impact is limited to integrity per the advisory and the independent assessment (no code execution, memory corruption, or availability loss); no public exploit code has been identified at time of analysis, no confirmed active exploitation (CISA KEV) has been reported, and a vendor patch is available in 4.2.18.Final.
HTTP/1-to-HTTP/3 tunnel policy bypass in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.2.Final through 4.2.17.Final) allows a remote, unauthenticated client to desynchronize a CONNECT request so that the tunnel authority forwarded over HTTP/3 is taken from the attacker-supplied Host header rather than the validated HTTP/1 authority-form request-target. A Netty-based proxy or gateway that performs its allow-list, egress, backend-selection, or audit checks against the request-target can therefore be induced to tunnel traffic to an attacker-chosen authority, an integrity-only impact (no confidentiality or availability loss) consistent with the vendor CVSS 4.0 score of 8.7 and the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N. The issue is fixed in 4.2.18.Final; no confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis, and exposure is limited to deployments that actually translate inbound HTTP/1 CONNECT requests to HTTP/3.
Unbounded per-connection heap growth in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.0.Final-4.2.17.Final) allows an unauthenticated remote peer holding an established HTTP/3 connection to exhaust server memory and trigger OutOfMemoryError, resulting in denial of service. The QPACK encoder-stream handler (QpackEncoderHandler, installed by default on the peer-initiated unidirectional encoder stream, type 0x02) 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, then retains and grows the per-connection decode buffer while the peer trickles fewer bytes than declared; existing HTTP/3 limits such as maxHeaderListSize, maxUnknownFramePayloadLength, and DEFAULT_MAX_FIELD_SECTION_SIZE are not applied to this handler and provide no mitigation. Netty 4.2.18.Final resolves the issue, and no public exploit code was identified at time of analysis; the practical exposure is limited to services that have explicitly adopted Netty's opt-in HTTP/3 codec.
Remote denial of service in Netty's HTTP/3 codec (io.netty:netty-codec-http3) 4.2.0.Final through 4.2.17.Final lets an unauthenticated remote peer exhaust server memory and CPU by opening a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and sending an all-prefix-bits first byte followed by an endless run of 0x80 continuation bytes. Because QpackUtil.decodePrefixedInteger returns -1 ("need more bytes") without consuming input, the ByteToMessageDecoder cumulator grows without bound and each decode() call re-scans the whole accumulated buffer at O(N^2) CPU cost, producing unbounded per-connection heap growth (OutOfMemoryError) and event-loop starvation. Netty's own advisory states the flaw is reachable in every configuration with no special flag or non-default setting, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms an availability-only impact with no confidentiality or integrity exposure; no public exploit code or CISA KEV entry was identified at time of analysis, and vendor-released patch 4.2.18.Final is available.
Unbounded heap growth in Netty's HTTP/3 codec (io.netty:netty-codec-http3) 4.2.0.Final through 4.2.17.Final allows a remote, unauthenticated HTTP/3 client to exhaust server memory and cause a denial of service. The QpackEncoder retains per-stream encoder state indefinitely because entries are only released when the peer sends a Section Acknowledgment or Stream Cancellation instruction, not when the HTTP/3 stream completes; an attacker advertising a non-zero QPACK dynamic-table capacity and withholding those acknowledgments across sequential requests on a single QUIC connection can accumulate unbounded tracked streams, field sections, and bytes, bypassing concurrent-stream limits. No public exploit code has been identified at time of analysis, and no CISA KEV confirmation of active exploitation is present; the practical exposure is limited because Netty's HTTP/3 (QUIC) support is not yet widely enabled in production. Vendor-released patch: 4.2.18.Final (GHSA-495p-pchh-r4mc).
Improper handling of HTTP/2 and HTTP/3 Extended CONNECT requests in Netty-based services can downgrade them to ordinary CONNECT requests, enabling request-smuggling or desynchronization in deployments where a fronting proxy and backend interpret the downgraded request differently. The issue carries a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N), meaning unauthenticated remote attackers can affect integrity, though the independent assessment raises attack complexity to High and scope to Changed and limits practical impact to proxy/gateway mismatches on endpoints that accept HTTP/2 or HTTP/3 Extended CONNECT. No CISA KEV entry or public exploit code was identified at time of analysis, so priority is moderate and conditional rather than urgent.
SMTP command injection in Netty's netty-codec-smtp allows unauthenticated remote attackers to inject arbitrary SMTP commands via CRLF sequences in the command-name field, affecting applications built on Netty such as Red Hat Build of Apache Camel for Spring Boot 4, Red Hat Fuse 7, JBoss EAP 7, and Red Hat Single Sign-On 7. This is an incomplete fix of CVE-2025-59419, requiring attacker-controlled input to reach the SMTP command name and a downstream SMTP server that acts on smuggled commands; no public exploit identified at time of analysis. Integrity impact is high, while confidentiality and availability are unaffected.
Netty's codec-rtsp component silently normalizes away trailing control bytes in RTSP method tokens, so a wire request whose method token ends in a byte with code point <= 0x20 immediately before the separating space (for example PLAY\x00 or PLAY\r) is decoded as a fully successful PLAY request with decoderResult().isSuccess() == true and request.method() referencing the same cached singleton object, leaving the application layer unable to distinguish it from a clean PLAY. This is a remote, unauthenticated, low-complexity integrity flaw (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) affecting any product that embeds Netty and exposes an RTSP listener, including the Red Hat components named in the advisory such as AMQ Broker 7, AMQ Clients, Quarkus, Camel for Quarkus 3/Spring Boot 4, Keycloak, JBoss EAP 7/8, Single Sign-On 7, Data Grid 8, Fuse 7, Debezium 3, and Apicurio Registry 3. Real security impact is gated on a downstream disagreement: a front-end proxy, WAF, gateway, or access-control layer must parse the RTSP method differently from Netty for method/request smuggling to produce genuine integrity effects, and exposure is narrow because RTSP listeners are far less commonly internet-facing than HTTP. Exploitation status: no public exploit identified at time of analysis and no CISA KEV confirmation, though the upstream advisory itself documents a minimal wire-level reproduction at a high level.
Remote unauthenticated attackers can exhaust memory in Netty-based services that parse PROXY protocol v2, due to a reference-count leak in the handling of nested TLVs within HAProxyMessageDecoder, leading to denial of service. The flaw is an incomplete fix of upstream PR #16881, so partially patched deployments may remain vulnerable through the grandchild-TLV code path. It affects numerous Red Hat products bundling Netty, such as JBoss EAP 7, Keycloak, and Quarkus, and no public exploit code has been identified at time of analysis.
Unbounded heap memory consumption in Netty's HttpServerCodec (io.netty:netty-codec-http) lets a remote, unauthenticated attacker drive a denial of service by exhausting server memory. An attacker who pipelines multiple HTTP/1.1 requests on a single connection and withholds reads prevents the internal methodOverflowQueue from being drained, so memory grows without limit; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is availability-only with no confidentiality or integrity impact, and no public exploit code was identified at time of analysis. Any HTTP/1.1 server built on the default Netty codec behavior is affected, and fixes ship in Netty 4.1.138.Final and 4.2.18.Final, with corresponding patched Red Hat product builds referenced through the Red Hat advisory.
Unbounded remote-initiated stream creation in Netty's SpdySessionHandler allows an unauthenticated, network-positioned attacker to exhaust JVM heap and direct memory on any application that exposes a SPDY endpoint, producing OutOfMemoryError and a denial of service. The handler initializes localConcurrentStreams to Integer.MAX_VALUE and provides no API to change it, so no supported configuration knob reduces the exposure once SPDY is reachable; Netty 4.1.x before 4.1.138.Final and 4.2.x before 4.2.18.Final are affected, along with the Red Hat products that bundle those versions (AMQ Broker and AMQ Clients, Camel for Quarkus 3 and for Spring Boot 4, Keycloak, Quarkus, Debezium, Apicurio Registry, Data Grid, Fuse, JBoss EAP 7/8, and RH-SSO 7). Exploitation requires the target application to have explicitly wired the SPDY handler into its Netty pipeline, since SPDY is a deprecated protocol that is not enabled by default; there is no public exploit identified at time of analysis, and the CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) reflects a low-complexity, availability-only denial of service with no confidentiality or integrity impact.
Heap exhaustion in Netty's Redis array aggregator, as shipped inside Red Hat products such as JBoss Enterprise Application Platform 7, Red Hat Fuse 7, Red Hat Build of Apache Camel for Spring Boot 4, and Red Hat Single Sign-On 7, lets a remote unauthenticated attacker crash the JVM by sending a tiny stream of nested RESP array headers. Because the decoder eagerly allocates an ArrayList sized to the declared array length before any child element arrives, roughly 12 KB of crafted input can reserve about 1.02 billion child slots when the default 1024-level nesting limit and default element limit are in effect; the impact is availability-only, with no data read or modified. Exploitation is limited to deployments that feed attacker-reachable, untrusted RESP/Redis-protocol traffic into the Netty codec with the default constructor; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Unauthenticated remote attackers can cause a gradual denial of service in applications that use Netty's STOMP codec by sending a STOMP frame body without the terminating null byte; StompSubframeDecoder leaks a ByteBuf for each such frame, so sustained traffic exhausts JVM heap or direct memory. The issue carries CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning network-reachable, no authentication or user interaction, availability-only impact. Red Hat middleware products listed in CPE data are affected when STOMP-over-TCP/WebSocket is enabled; no public exploit code or confirmed active exploitation was identified at time of analysis, and a practical DoS requires repeated frames rather than a single packet.
TLS hostname verification is silently bypassed in Netty's OpenSSL client path, allowing a network man-in-the-middle attacker to intercept encrypted communications by presenting a certificate issued for a different hostname. Affected are applications using io.netty:netty-handler versions 4.2.0.Final through 4.2.16.Final or any 4.1.x through 4.1.136.Final, specifically when the SslProvider.OPENSSL client path is configured with a plain X509TrustManager and running on Java 25 or later, where Unsafe-based trust-manager wrapping is unavailable. No public exploit code has been identified at time of analysis, but the confidentiality impact is high for any affected deployment that transmits sensitive data over TLS.
Mutual-TLS authentication bypass in the Netty network framework (io.netty.handler.ssl.SslClientHelloHandler) lets an unauthenticated remote attacker reach routes protected only by per-SNI clientAuth=REQUIRE. A ClientHello whose 4-byte handshake header is split across TLS records trips a wrong-offset bounds check, throwing IndexOutOfBoundsException and calling select(ctx, null), which falls back to the default SslContext (clientAuth NONE/OPTIONAL) instead of the SNI-matched context. Fixed in 4.1.137.Final and 4.2.17.Final; no public exploit identified at time of analysis, but the CVSS 4.0 base score is 9.1 (Critical).
Denial-of-service via quadratic CPU exhaustion in Netty's SniHandler affects all Netty deployments prior to 4.1.137.Final and 4.2.17.Final that use the default SniHandler constructors for TLS termination. An unauthenticated remote peer can fragment a large TLS ClientHello across thousands of small records, causing SslClientHelloHandler#decode to recopy all previously received bytes on every record arrival - O(N²) work that stalls the Netty event loop and denies TLS service to all concurrent clients. No active exploitation is confirmed (not in CISA KEV) and no public proof-of-concept has been identified, but the low attack complexity and zero-authentication requirement make this a credible threat for any internet-exposed Netty TLS endpoint.
Netty's HTTP CORS handler silently rewrites the Vary response header to Vary: Origin in releases before 4.1.137.Final and 4.2.17.Final, letting a shared caching proxy or CDN reuse authenticated, user-specific responses across users and leak sensitive data. Exposure is confined to deployments that install io.netty.handler.codec.http.cors.CorsHandler, also set their own Vary headers (such as Authorization or Cookie) for per-user caching, and sit behind a shared cache; because those three conditions must coincide, the assessed vector raises attack complexity to AC:H even though the published base score is 7.5 (AV:N/PR:N/UI:N/C:H). Publicly available exploit code exists (a public gist alongside the upstream fix PRs), but there is no evidence of active exploitation: the issue is not in CISA KEV, SSVC records Exploitation: none and Automatable: no, and EPSS is only 0.40% (33rd percentile), consistent with the assessment that real-world urgency is much lower than the headline score suggests.
Memory exhaustion in Netty's SctpMessageCompletionHandler (netty-transport-sctp) allows unauthenticated remote peers to drive a JVM into OutOfMemoryError by sending oversized, incomplete SCTP message fragments. The handler enforces limits on concurrent incomplete messages and per-message fragment counts - introduced as a fix for the prior CVE-2026-46340 - but omits a corresponding cap on total buffered bytes. With default settings of 128 messages and 128 fragments, an attacker can buffer approximately 1GB per connection; a small number of concurrent connections suffices to exhaust server heap. Vendor-released patches exist in versions 4.1.137.Final and 4.2.17.Final; no active exploitation or public POC has been identified at time of analysis.
Incremental direct-memory exhaustion in Netty's DNS codec (netty-codec-dns) allows unauthenticated remote attackers to drive a Netty-based DNS server or DnsNameResolver into denial of service by sending DNS packets that carry malformed domain names. Because IDN.toASCII() or the domain-name encoder throws an IllegalArgumentException inside the record constructor before the associated ByteBuf is stored and later released, each crafted packet leaks a small direct-memory buffer; the leak is cumulative, so a sustained packet stream is required to exhaust memory rather than a single request. Affected releases are netty-codec-dns up to and including 4.1.135.Final and 4.2.0.Final through 4.2.15.Final; vendor patches are available in 4.1.136.Final and 4.2.16.Final, EPSS is low (0.33%, 26th percentile), and no public exploit code or confirmed active exploitation was identified at time of analysis.
CPU exhaustion denial of service in Netty's XmlFrameDecoder allows an unauthenticated remote attacker to hang a server's EventLoop thread by trickle-feeding repeated `</` byte sequences to any port where XmlFrameDecoder is in the pipeline. Because the decoder fails to save parser state between `decode()` invocations, each new call rescans the entire accumulated buffer from scratch, producing O(n²) CPU growth that can fully pin a thread with as little as 1 MB of malformed XML data. No public exploit code has been identified at time of analysis, though the GitHub Security Advisory GHSA-v74w-7mr3-4qg3 supplies sufficient technical detail to reproduce the attack. Vendor-released patches are available as Netty 4.1.136.Final and 4.2.16.Final.
Certificate revocation-check bypass in the Netty network framework's OCSP client (io.netty:netty-handler-ssl-ocsp) affects versions 4.2.0.Final through 4.2.15.Final and all releases prior to 4.1.136.Final, where OcspClient.validateResponse never confirms that the CertificateID in an OCSP response matches the certificate being validated. An attacker holding any valid, non-revoked certificate from the same issuing CA can obtain a legitimately signed GOOD response and replay it to make Netty accept a revoked or compromised certificate as valid. Publicly available exploit code exists (a PoC test case in the GHSA advisory), but there is no public exploit identified as being used in active attacks and EPSS risk is low (0.30%, 22nd percentile).
Denial of service in the Netty network framework (4.2.0.Final-4.2.15.Final and 4.1.0.Final-4.1.135.Final) lets a remote unauthenticated peer exhaust JVM direct memory and crash the process. Applications that enable HTTP/2 content decompression via DelegatingDecompressorFrameListener leak one direct ByteBuf for every HTTP/2 DATA frame delivered to a stream whose decompressor has already been closed, because Http2Decompressor.decompress(...) retains the buffer for writeInbound but never releases it on the error path. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided.
XML external entity exposure in the Netty network framework affects the optional XmlDecoder handler in versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, where the underlying Aalto AsyncXMLInputFactory is instantiated without any security hardening. Any remote party able to push bytes into a channel pipeline that contains XmlDecoder can submit XML carrying a DOCTYPE/DTD declaration, and depending on Aalto async parser behavior DTD and entity processing remains active, creating a conditional path to reading local files or performing SSRF-style out-of-band requests. There is no public exploit identified at time of analysis, the issue is not on CISA KEV, and it is fixed in 4.1.136.Final and 4.2.16.Final.
Memory-exhaustion denial of service in Netty's HTTP/3 codec (Http3FrameCodec) affects all releases prior to 4.2.16.Final, where decodeFrame trusts the wire-supplied payLoadLength and buffers reserved-frame-type payloads without an upper bound. A remote unauthenticated attacker (CVSS 7.5, AV:N/PR:N) can open many QUIC streams and advertise very large payload lengths on reserved HTTP/3 frames to force unbounded heap allocation and crash the server. No public exploit or CISA KEV listing exists at time of analysis; a vendor patch (4.2.16.Final) is available.
Uncontrolled native-memory consumption in Netty's SPDY-to-HTTP codec (SpdyHttpDecoder) lets a remote unauthenticated peer exhaust off-heap memory and crash the server. Affected versions are 4.2.0.Final–4.2.15.Final and 4.1.0.Final–4.1.135.Final; the decoder allocates a pooled ByteBuf for an in-flight SYN_STREAM request but fails to release it when the stream is aborted via RST_STREAM or when content exceeds maxContentLength. There is no public exploit identified at time of analysis, and this CVE is not listed in CISA KEV; impact is denial of service only (VC:N/VI:N/VA:H).
Remote denial of service in the Netty networking framework (codec-haproxy module) versions 4.1.0.Final through 4.1.135 and 4.2.0.Final through 4.2.15.Final lets unauthenticated attackers exhaust JVM direct memory. The HAProxyMessageDecoder mis-parses a PROXY protocol v2 header whose version byte is 0xFF, sign-extending it to -1, which collides with the decoder's 'need more data' sentinel, so ByteToMessageDecoder accumulates inbound bytes in an unbounded cumulation buffer until the process runs out of direct memory. No public exploit identified at time of analysis; the CVSS 4.0 score of 8.7 reflects high availability impact with no confidentiality or integrity effect.
Compression-amplification denial of service in the Netty network framework (versions prior to 4.1.136.Final and 4.2.16.Final) allows a remote peer to send a small zlib-compressed SPDY HEADERS block that Netty keeps inflating even after the raw header parser exceeds maxHeaderSize and marks the frame truncated in SpdyFrameCodec. The result is disproportionate CPU consumption and allocation churn (CWE-400) from a tiny input, degrading or crashing services that expose the SPDY codec. No public exploit identified at time of analysis and it is not listed in CISA KEV; impact is availability-only per CVSS 7.5 (A:H).
Memory-amplification denial of service in the Netty network framework (SPDY/3.1 codec) prior to 4.1.136.Final and 4.2.16.Final allows a remote unauthenticated peer to send a single ~2 MiB SPDY SETTINGS frame that forces the server to materialize 262,144 map entries in DefaultSpdySettingsFrame, driving heap growth and ordered-map insertion CPU cost far out of proportion to the input. Affected are Java services that enable Netty's SPDY handler and accept untrusted connections; there is no public exploit identified at time of analysis, and while CVSS is 7.5 the low EPSS-style real-world footprint is tempered by SPDY/3.1 being a deprecated, rarely-enabled protocol.
Denial of service in Netty's io.netty:netty-codec-redis component (prior to 4.1.135.Final and 4.2.15.Final) allows remote attackers to trigger memory exhaustion by sending a crafted RESP array header that declares a huge element count, causing RedisArrayAggregator to pre-allocate an oversized ArrayList before any child messages arrive. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided in the input.
TLS hostname verification is silently disabled in Netty's netty-handler module for any client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager), allowing network attackers in a man-in-the-middle position to present a valid certificate for any host and intercept supposedly encrypted traffic. Affects all Netty versions prior to 4.1.135.Final and 4.2.15.Final; no public exploit identified at time of analysis and EPSS is very low (0.04%), but the defect bypasses a core TLS protection that Netty 4.2 explicitly advertises as enabled by default.
Denial of service in the Netty HTTP/3 codec (io.netty:netty-codec-http3) prior to version 4.2.15.Final allows remote unauthenticated attackers to exhaust server memory by triggering creation of an unbounded number of blocked streams, leading to an OutOfMemoryError. The flaw affects any Java application or service using Netty as an HTTP/3 server. No public exploit identified at time of analysis, and EPSS probability is very low (0.05%, 17th percentile), but the network-reachable nature of the HTTP/3 protocol surface makes patching a priority for exposed endpoints.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resources by rapidly opening and immediately canceling (RST_STREAM) large numbers of streams over a single connection, a technique dubbed the 'Rapid Reset' attack. The flaw is confirmed actively exploited (CISA KEV) following large-scale weaponization observed August through October 2023, with publicly available exploit code and an EPSS score of 94.45% placing it in the 100th percentile for likelihood of exploitation. Virtually every major HTTP/2 stack - including nghttp2, Netty, Envoy, and Eclipse Jetty - is affected.
netty-tcnative through 2.0.83.Final passes the raw SNI server_name from the ClientHello into JNI's NewStringUTF(), which decodes modified UTF-8 rather than standard UTF-8. A remote, unauthenticated client can therefore place the overlong two-byte sequence 0xC0 0x80 in the SNI extension and have it materialize as an embedded U+0000 character inside the Java hostname string handed to SniHostNameMatcher and returned by SSL.getSniHostname(), letting the attacker influence SNI-based certificate selection, access-control decisions and logging. The assessed severity is CVSS 3.1 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N); the library-level corruption is unconditional, but real-world impact is gated on the integrating application actually relying on that hostname for a trust decision or re-encoding it downstream. The advisory documents a deterministic researcher reproduction against an unmodified build; no public exploit code is referenced, and there is no KEV or EPSS signal in the provided data.
Unauthenticated remote attackers can desynchronize HTTP/1.1 response parsing in Netty's HttpServerCodec (io.netty:netty-codec-http) versions 4.2.0.Final through 4.2.16.Final and all versions up to and including 4.1.136.Final by pipelining a GET carrying 'Expect: 100-continue' immediately followed by a HEAD request on the same keep-alive connection. Because the codec pairs each outbound response - including the 100 Continue informational response - with a queued inbound method via pollMethod(), the GET's 200 OK is matched to HEAD and its entity body is dropped, while the following 200 OK (intended for HEAD) is emitted with a body; this misattributes content across responses, enabling response splitting and unsafe reuse of the connection. It is a genuine but moderate-priority integrity flaw (vendor CVSS 4.0 score 6.9; independent assessment CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), with no public exploit identified at time of analysis and vendor-released patches available in 4.2.17.Final and 4.1.137.Final.
Routing and access-control bypass in Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final allows a remote unauthenticated attacker to send a single HEADERS frame with conflicting :authority and host header values, causing different components in a multi-component request path to make inconsistent decisions. This moderate-severity integrity issue is fixed in 4.2.18.Final; no public exploit code or active exploitation has been identified at time of analysis.
HTTP request smuggling in Netty's HTTP/1 decoder lets remote, unauthenticated attackers bypass front-end security controls and reach resources they should not access by sending requests with malformed Transfer-Encoding headers. Netty is a widely embedded Java networking library, so the practical reach spans Red Hat products built on it - AMQ Broker 7, AMQ Clients, Red Hat Build of Keycloak, Red Hat Build of Quarkus, Red Hat Build of Apache Camel (Spring Boot 4 and Quarkus 3), Red Hat Build of Debezium 3, Red Hat Build of Apicurio Registry 3, Red Hat Data Grid 8 and Red Hat Fuse 7 - as well as JBoss EAP 7/8 and Red Hat Single Sign-On 7 per the associated advisory tags. CVSS 3.1 rates it 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), consistent with smuggling-style control bypass rather than full compromise; no public exploit code or confirmed active exploitation was identified at time of analysis, though the flaw is trivially reachable on any exposed HTTP endpoint.
HTTP request smuggling in Netty's netty-codec-http component lets unauthenticated remote attackers bypass front-end security controls by sending a crafted HTTP/1.1 chunk-size token containing whitespace after the hexadecimal digits, which Netty parses differently from other HTTP intermediaries. The flaw carries a CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L), meaning no authentication or user interaction is required, but integrity and availability impact is limited; meaningful exploitation generally depends on a multi-tier topology where a proxy, load balancer, or backend parses the chunk-size token inconsistently with Netty. Red Hat ships the affected library across a broad portfolio - including AMQ Broker 7, AMQ Clients, Quarkus, Keycloak and Red Hat Single Sign-On 7, JBoss EAP 7/8, Fuse 7, Data Grid 8, Camel for Spring Boot 4, Camel 4 for Quarkus 3, Apicurio Registry 3 and Debezium 3 - and no public exploit code has been identified at time of analysis, with no confirmed active exploitation (CISA KEV).
HTTP request smuggling and header injection in Netty's HTTP/2 stack (as bundled in multiple Red Hat products) allow remote unauthenticated attackers to bypass security controls and manipulate requests when HTTP/2 traffic is translated to HTTP/1.1. Affected deployments include Red Hat AMQ Broker 7, Camel, Keycloak, Quarkus, Data Grid, Fuse, EAP, Apicurio Registry, and Debezium. Assessed as high severity (CVSS 3.1 base 7.5, AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:N); exploitation requires the specific topology of an HTTP/2-to-HTTP/1.1 translation boundary, and no public exploit was identified at time of analysis.
This is a real but moderate-priority vulnerability whose severity depends almost entirely on deployment topology rather than the raw 6.5 CVSS score. Netty's HTTP decoder lets split or duplicated Transfer-Encoding header fields slip past its final-chunked validation, so an unauthenticated, remote attacker who can send a raw crafted request to a Netty listener that sits in an HTTP chain with a second HTTP parser (reverse proxy, load balancer, CDN, WAF, or upstream/downstream server) can desynchronize the two parsers and smuggle a request (CWE-444). Impact is confined to low confidentiality and integrity loss (C:L/I:L) with no availability impact, no authentication (PR:N) or user interaction (UI:N) is required, and no public exploit identified at time of analysis.
HTTP request smuggling in Netty's HTTP/1.1 decoder (HttpObjectDecoder and the HttpRequestDecoder built on it) lets remote, unauthenticated attackers send a chunk-size line containing an embedded bare carriage return - for example `0\rX` - because strict chunk-line validation is skipped whenever the size line carries no `;` chunk extension, causing a request-boundary desync when Netty shares a connection with a second HTTP intermediary that frames the message differently. The flaw reaches every application and Red Hat product that embeds Netty, including AMQ Broker 7, AMQ Clients, Quarkus, Camel 4 for Quarkus 3, Camel for Spring Boot 4, Keycloak / Red Hat Single Sign-On, JBoss EAP 7 and 8, Fuse 7, Data Grid 8, Apicurio Registry 3 and Debezium 3, while independent assessment keeps it at CVSS 6.5 with AC:H because a standalone Netty service with no disagreeing proxy in the chain yields little practical smuggling impact. The public report includes a reproducible PoC test harness, but there is no CISA KEV listing and no evidence of active exploitation.
Denial of service in Netty's HTTP/2 HPACK encoder (HpackEncoder) allows an unauthenticated remote attacker to force excessive CPU and memory consumption by sending SETTINGS frames that advertise an oversized MAX_HEADER_TABLE_SIZE, causing the encoder to retain an excessive number of unique header entries. The issue affects applications and Red Hat products that embed Netty and expose an HTTP/2 listener - including JBoss EAP 7 and 8, Keycloak, Red Hat Single Sign-On 7, AMQ Broker 7, Data Grid 8, Fuse 7, Quarkus, Camel 4 for Quarkus 3, Camel for Spring Boot 4, Apicurio Registry 3, and Debezium 3 - while HTTP/1.1-only endpoints are not exposed. Impact is bounded to availability (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, CVSS 5.3) with no data disclosure or modification; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation.
Certificate revocation validation performed by Netty's optional netty-handler-ssl-ocsp module can be silently skipped when the OCSP response omits the optional nextUpdate field, causing the application to proceed with a certificate that should have been rejected. The flaw is remote and requires no credentials or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9), but exploitation is conditional: the deployment must actually use the opt-in OCSP-stapling component, and the attacker must control or intercept the OCSP response seen by the client, typically through a man-in-the-middle position or by operating the TLS server whose certificate is being validated. There is no public exploit identified at time of analysis and no KEV listing, and the practical impact is confined to acceptance of a revoked or otherwise unvalidated certificate rather than code execution or data disclosure.
HTTP request smuggling in Netty 4.1.133-4.1.137.Final and 4.2.13-4.2.17.Final allows unauthenticated remote attackers to poison HTTP request queues and bypass intermediary security controls by submitting crafted Transfer-Encoding headers. The HttpObjectDecoder's final-coding validation was flawed: both split multi-line TE headers and comma-separated values like 'chunked, xchunked' bypassed the 'chunked must be last' check, causing Netty to interpret message framing differently from upstream proxies. Fixed releases 4.1.138.Final and 4.2.18.Final enforce RFC 9112-compliant validation across all TE header fields; no public exploit code or CISA KEV listing has been identified at time of analysis.
Null byte and CRLF injection in Netty's SOCKS4 and SOCKS5 client encoders (Socks4ClientEncoder, Socks5ClientEncoder) allows an attacker who controls domain address or authentication fields to truncate or alter proxy connection parameters, enabling domain spoofing, userid truncation, authentication data injection, and protocol confusion. Affected are all Netty releases in the 4.1.x branch through 4.1.136.Final and the 4.2.x branch through 4.2.16.Final - both branches have been patched. No public exploit code has been identified at time of analysis and this CVE is not listed in CISA KEV, but the integrity impact on downstream SOCKS proxy routing is concrete.
Netty's RedisArrayAggregator codec fails to release retained partial aggregate state when the maxElements limit is exceeded, unlike the symmetric maxNestedArrayDepth branch which correctly calls releaseAndClearDepths() before throwing. In applications that keep the channel alive after a codec exception - a common resilience pattern - an unauthenticated peer can exploit this inconsistency to keep attacker-controlled ByteBuf references pinned in Netty's pooled buffer allocator and cause subsequent messages to be consumed into the stale pre-error aggregate. A public proof-of-concept test is included in the GHSA advisory; fixed in Netty 4.1.136.Final and 4.2.16.Final with no KEV listing at time of analysis.
Cross-origin resource sharing controls in Netty's CorsHandler can be entirely bypassed by sending an `Origin: null` header, due to a logical operator error in the origin evaluation path. Affected are Netty 4.1.0.Final through 4.1.135.Final and 4.2.0.Final through 4.2.15.Final - a range spanning years of releases across both major active branches. An unauthenticated remote attacker who can induce a victim to initiate a cross-origin request can bypass the `shortCircuit()` enforcement entirely, causing unauthorized requests to be forwarded to the backend application as if they were permitted. No public exploit or KEV listing is identified at time of analysis, but the bypass mechanism is straightforward and vendor-confirmed.
Netty's HTTP/2 codec mishandles the SETTINGS_MAX_HEADER_LIST_SIZE client setting, enabling a denial-of-service attack functionally equivalent to HTTP/2 Rapid Reset (CVE-2023-44487) but with a distinct on-wire signature. Affected Netty versions prior to 4.1.135.Final and 4.2.15.Final fully process and proxy incoming requests to the origin before encountering an exception during response header serialization, consuming server resources without completing responses. No public exploit has been identified at time of analysis, and EPSS stands at 0.02% (5th percentile), though the attack technique parallels a well-documented catastrophic DDoS class.
HTTP request smuggling in Netty's HttpObjectDecoder (netty-codec-http) allows unauthenticated remote attackers to manipulate request-boundary parsing in pipelined or multiplexed deployments by injecting non-CRLF ISO control characters (NUL, SOH, STX, etc.) before the HTTP request-line. Affected are all Netty releases prior to 4.1.135.Final and 4.2.15.Final; both branches have vendor-confirmed patches. No public exploit code has been identified and EPSS is 0.04% (12th percentile), indicating low current exploitation likelihood, though the attack surface expands significantly in architectures fronted by proxies or load balancers that strip or interpret those control bytes differently than Netty does.
Stateless reset token leakage in Netty's QUIC codec (io.netty:netty-codec-classes-quic prior to 4.2.15.Final) enables an on-path attacker to derive the reset token for active connections and terminate them via spoofed Stateless Reset packets. The default HMAC-based generators expose a deterministic relationship between the source connection ID visible in QUIC headers and the server's stateless reset token - after a source-CID rotation, an observer can compute the token from the new connection-ID bytes. No public exploit identified at time of analysis; the CVSS 4.8 Medium rating reflects the on-path attacker prerequisite (AC:H), which meaningfully limits opportunistic exploitation.
Truncation of chunked Oblivious HTTP (OHTTP) streams in netty-incubator-codec-ohttp prior to 0.0.22.Final silently passes partial, cryptographically-incomplete messages to the receiving application with no decryption error or exception. An on-path adversary - the OHTTP relay itself or a MITM on the relay↔gateway or relay↔client transport - can cut a legitimate chunked-OHTTP message at any non-final chunk boundary and cleanly close the outer HTTP body, bypassing the cryptographic integrity guarantee the final-chunk marker is designed to provide. No public exploit is identified (CVSS E:U) and no CISA KEV listing exists, but the integrity impact is rated High (VI:H) given that receivers silently accept and may act on structurally incomplete messages.
Incorrect native memory address resolution in Netty's Oblivious HTTP (OHTTP) BoringSSL JNI bridge allows unauthenticated remote attackers to corrupt memory belonging to concurrent connections and disclose the contents of adjacent pooled direct buffers - including HPKE encryption key material - on affected OHTTP gateways. The flaw exists in versions prior to 0.0.22.Final of netty-incubator-codec-ohttp and is only reachable when the JVM is configured to deny `sun.misc.Unsafe` access, causing the vulnerable fallback address-resolution path to activate. This directly undermines the confidentiality guarantees Oblivious HTTP is designed to provide; no public exploit code exists and the vulnerability is not listed in the CISA KEV catalog (CVSS 4.0 E:U).
CRLF injection in Netty's io.netty.handler.codec.http.HttpRequestEncoder (netty-codec-http) allows an attacker-influenced request URI to be written verbatim into the outbound HTTP request line, enabling HTTP request smuggling against upstream/back-end servers. The flaw affects netty-codec-http versions prior to 4.1.129.Final and the 4.2.x line from 4.2.0.Alpha1 up to (but not including) 4.2.8.Final, and is unauthenticated per the CVSS vector (AV:N/PR:N/UI:N) with low confidentiality and integrity impact (CVSS 6.5). Publicly available exploit code exists, including a reproducer in the GitHub Security Advisory, and exploitation is conditional: it requires an application that uses HttpRequestEncoder (typically via HttpClientCodec) and passes unsanitized or attacker-controlled data into the request URI. There is no confirmed active exploitation (not in CISA KEV); Netty's default HTTP header validator blocks CRLF in headers but does not sanitize the URI.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 6.9), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty is an asynchronous event-driven network application framework for development of maintainable high performance protocol servers and clients. Rated low severity (CVSS 2.9), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty is an asynchronous, event-driven network application framework. Rated high severity (CVSS 8.2), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Netty, an asynchronous, event-driven network application framework, has a vulnerability in versions up to and including 4.1.118.Final. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Netty, an asynchronous, event-driven network application framework, has a vulnerability starting in version 4.1.91.Final and prior to version 4.1.118.Final. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Public exploit code available.
The netty incubator codec.bhttp is a java language binary http parser. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
netty-incubator-codec-ohttp is the OHTTP implementation for netty. Rated critical severity (CVSS 9.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Netty project is an event-driven asynchronous network application framework. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty project is an event-driven asynchronous network application framework. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Netty is an open-source, asynchronous event-driven network application framework. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Public exploit code available.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This HTTP Request/Response Smuggling vulnerability could allow attackers to manipulate HTTP request interpretation between frontend and backend servers.
The Snappy frame decoder function doesn't restrict the chunk length which may lead to excessive memory usage. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
The Bzip2 decompression decoder function doesn't allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression). Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. This HTTP Request/Response Smuggling vulnerability could allow attackers to manipulate HTTP request interpretation between frontend and backend servers.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. This HTTP Request/Response Smuggling vulnerability could allow attackers to manipulate HTTP request interpretation between frontend and backend servers.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Public exploit code available.
The ZlibDecoders in Netty 4.1.x before 4.1.46 allow for unbounded memory allocation while decoding a ZlibEncoded byte stream. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Allocation of Resources Without Limits vulnerability could allow attackers to exhaust system resources through uncontrolled allocation.
Netty 4.1.43.Final allows HTTP Request Smuggling because it mishandles Transfer-Encoding whitespace (such as a [space]Transfer-Encoding:chunked line) and a later Content-Length header. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a "Transfer-Encoding : chunked" line), which leads to HTTP request smuggling. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty before 3.9.8.Final, 3.10.x before 3.10.3.Final, 4.0.x before 4.0.28.Final, and 4.1.x before 4.1.0.Beta5 and Play Framework 2.x before 2.3.9 might allow remote attackers to bypass the httpOnly. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
handler/ssl/OpenSslEngine.java in Netty 4.0.x before 4.0.37.Final and 4.1.x before 4.1.1.Final allows remote attackers to cause a denial of service (infinite loop). Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
The SslHandler in Netty before 3.9.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted SSLv2Hello message. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
WebSocket08FrameDecoder in Netty 3.6.x before 3.6.9, 3.7.x before 3.7.1, 3.8.x before 3.8.2, 3.9.x before 3.9.1, and 4.0.x before 4.0.19 allows remote attackers to cause a denial of service (memory. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity.
netty-tcnative 2.0.83.Final and earlier can be driven into denial of service or silent TLS message corruption by ordinary TLS 1.3 traffic, because the tcn_write_to_bytebuffer BIO_write callback in ssl.c reports more bytes consumed than the caller actually asked to write. The inflation occurs when the internal side buffer (populated by queued post-handshake records such as NewSessionTicket, KeyUpdate or alerts) is non-empty at the moment a write-sink BIO_write runs, and the outcome is backend-specific: BoringSSL silently corrupts handshake or application data on the wire, an adjacent BoringSSL post-handshake path can abort the JVM process outright, and LibreSSL permanently wedges the connection's write path. The independent assessment rates this CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H - unauthenticated remote and requiring the coincidence of queued side-buffer data with a write-mode flush - while a public proof-of-concept reproduction is documented in the upstream advisory; it is not verified as turnkey exploit code and there is no CISA KEV confirmation of active exploitation at time of analysis.
A use-after-free in netty-tcnative 2.0.66.Final through 2.0.83.Final builds linked against OpenSSL 3.0 or newer lets a TLS handshake crash the server process when it issues or resumes a session ticket at the same moment the operator rotates ticket keys through SSLContext.setSessionTicketKeys0(). The handshake side of the race is reachable by unauthenticated remote clients (PR:N, UI:N), but the limiting precondition is the operator-initiated rotation happening inside a window only a few CPU instructions wide, which is why the assessed vector carries AT:P and AC:H and the reported CVSS 4.0 score of 8.2 resolves to an assessed CVSS 3.1 base of 5.9 with confidentiality and integrity impact unconfirmed and only availability (A:H) demonstrated. No CISA KEV entry exists and no weaponized exploit code has been identified, though the public advisory documents a reporter-side, repeatable SIGSEGV reproduction on a real compiled openssl-dynamic build using a race-widened test harness; patched builds are available and the priority label is this_week.
Heap buffer overflow in netty-tcnative's custom OpenSSL BIO wrapper (all releases through 2.0.83.Final, including netty-tcnative-boringssl-static) allows a remote TLS peer to crash the JVM process by pushing handshake continuation, renegotiation, or TLS 1.3 post-handshake bytes through the internal nonApplicationBuffer ring buffer until its un-normalized write index exceeds the buffer size, after which a memcpy runs with an out-of-bounds pointer and a negative length cast to size_t. No authentication or user interaction is required (PR:N/UI:N), but reliability is limited by the CVSS 4.0 AT:P flag: the overflow only materializes when the integrating application chose a comparatively small nonApplicationBufferSize via SSL.bioNewByteBuffer and traffic arrives in write/partial-drain cycles that never fully empty the buffer. The assessed impact is availability-only (VA:H) - a deterministic process crash - with no confirmed confidentiality or integrity effect; no CISA KEV listing exists and no released working exploit code was identified at time of analysis, although the upstream advisory documents a deterministic reproduction PoC built from the public JNI API.
Hostname verification bypass in Netty's QUIC client affects versions 4.2.11.Final through 4.2.17.Final when the application supplies a plain javax.net.ssl.X509TrustManager rather than an X509ExtendedTrustManager, allowing an attacker positioned on the network path to present a certificate chain for the wrong hostname that the trust manager still accepts. In practice exploitation requires an active man-in-the-middle position rather than a trivial remote attack, since the attacker must intercept the QUIC connection and hold a valid-but-mis-matched certificate; the CVSS 4.0 score of 8.7 (AV:N/AC:L/PR:N/UI:N) overstates this precondition. No public exploit code was identified at time of analysis, and clients using X509ExtendedTrustManager are not affected; Netty 4.2.18.Final resolves the issue.
Authority confusion in Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.2.Final through 4.2.17.Final allows a remote, unauthenticated attacker to make a Netty-based HTTP/1-to-HTTP/3 gateway validate, authorize, or route a request against a different authority than the one its upstream HTTP/3 peer actually receives. The flaw only manifests in gateway, proxy, or protocol-bridge deployments that pass HTTP/1 messages through Http3FrameToHttpObjectCodec(false) and then make security decisions (allow-lists, virtual-host routing, backend selection, cache keys, URL generation) based on the absolute-form request-target authority; a request such as 'GET https://trusted.example/admin HTTP/1.1' with 'Host: attacker.example' yields an RFC-compliant authority at the front door and an attacker-chosen :authority upstream. Impact is limited to integrity per the advisory and the independent assessment (no code execution, memory corruption, or availability loss); no public exploit code has been identified at time of analysis, no confirmed active exploitation (CISA KEV) has been reported, and a vendor patch is available in 4.2.18.Final.
HTTP/1-to-HTTP/3 tunnel policy bypass in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.2.Final through 4.2.17.Final) allows a remote, unauthenticated client to desynchronize a CONNECT request so that the tunnel authority forwarded over HTTP/3 is taken from the attacker-supplied Host header rather than the validated HTTP/1 authority-form request-target. A Netty-based proxy or gateway that performs its allow-list, egress, backend-selection, or audit checks against the request-target can therefore be induced to tunnel traffic to an attacker-chosen authority, an integrity-only impact (no confidentiality or availability loss) consistent with the vendor CVSS 4.0 score of 8.7 and the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N. The issue is fixed in 4.2.18.Final; no confirmed active exploitation (CISA KEV) and no public exploit code identified at time of analysis, and exposure is limited to deployments that actually translate inbound HTTP/1 CONNECT requests to HTTP/3.
Unbounded per-connection heap growth in Netty's HTTP/3 codec (io.netty:netty-codec-http3 4.2.0.Final-4.2.17.Final) allows an unauthenticated remote peer holding an established HTTP/3 connection to exhaust server memory and trigger OutOfMemoryError, resulting in denial of service. The QPACK encoder-stream handler (QpackEncoderHandler, installed by default on the peer-initiated unidirectional encoder stream, type 0x02) 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, then retains and grows the per-connection decode buffer while the peer trickles fewer bytes than declared; existing HTTP/3 limits such as maxHeaderListSize, maxUnknownFramePayloadLength, and DEFAULT_MAX_FIELD_SECTION_SIZE are not applied to this handler and provide no mitigation. Netty 4.2.18.Final resolves the issue, and no public exploit code was identified at time of analysis; the practical exposure is limited to services that have explicitly adopted Netty's opt-in HTTP/3 codec.
Remote denial of service in Netty's HTTP/3 codec (io.netty:netty-codec-http3) 4.2.0.Final through 4.2.17.Final lets an unauthenticated remote peer exhaust server memory and CPU by opening a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and sending an all-prefix-bits first byte followed by an endless run of 0x80 continuation bytes. Because QpackUtil.decodePrefixedInteger returns -1 ("need more bytes") without consuming input, the ByteToMessageDecoder cumulator grows without bound and each decode() call re-scans the whole accumulated buffer at O(N^2) CPU cost, producing unbounded per-connection heap growth (OutOfMemoryError) and event-loop starvation. Netty's own advisory states the flaw is reachable in every configuration with no special flag or non-default setting, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms an availability-only impact with no confidentiality or integrity exposure; no public exploit code or CISA KEV entry was identified at time of analysis, and vendor-released patch 4.2.18.Final is available.
Unbounded heap growth in Netty's HTTP/3 codec (io.netty:netty-codec-http3) 4.2.0.Final through 4.2.17.Final allows a remote, unauthenticated HTTP/3 client to exhaust server memory and cause a denial of service. The QpackEncoder retains per-stream encoder state indefinitely because entries are only released when the peer sends a Section Acknowledgment or Stream Cancellation instruction, not when the HTTP/3 stream completes; an attacker advertising a non-zero QPACK dynamic-table capacity and withholding those acknowledgments across sequential requests on a single QUIC connection can accumulate unbounded tracked streams, field sections, and bytes, bypassing concurrent-stream limits. No public exploit code has been identified at time of analysis, and no CISA KEV confirmation of active exploitation is present; the practical exposure is limited because Netty's HTTP/3 (QUIC) support is not yet widely enabled in production. Vendor-released patch: 4.2.18.Final (GHSA-495p-pchh-r4mc).
Improper handling of HTTP/2 and HTTP/3 Extended CONNECT requests in Netty-based services can downgrade them to ordinary CONNECT requests, enabling request-smuggling or desynchronization in deployments where a fronting proxy and backend interpret the downgraded request differently. The issue carries a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N), meaning unauthenticated remote attackers can affect integrity, though the independent assessment raises attack complexity to High and scope to Changed and limits practical impact to proxy/gateway mismatches on endpoints that accept HTTP/2 or HTTP/3 Extended CONNECT. No CISA KEV entry or public exploit code was identified at time of analysis, so priority is moderate and conditional rather than urgent.
SMTP command injection in Netty's netty-codec-smtp allows unauthenticated remote attackers to inject arbitrary SMTP commands via CRLF sequences in the command-name field, affecting applications built on Netty such as Red Hat Build of Apache Camel for Spring Boot 4, Red Hat Fuse 7, JBoss EAP 7, and Red Hat Single Sign-On 7. This is an incomplete fix of CVE-2025-59419, requiring attacker-controlled input to reach the SMTP command name and a downstream SMTP server that acts on smuggled commands; no public exploit identified at time of analysis. Integrity impact is high, while confidentiality and availability are unaffected.
Netty's codec-rtsp component silently normalizes away trailing control bytes in RTSP method tokens, so a wire request whose method token ends in a byte with code point <= 0x20 immediately before the separating space (for example PLAY\x00 or PLAY\r) is decoded as a fully successful PLAY request with decoderResult().isSuccess() == true and request.method() referencing the same cached singleton object, leaving the application layer unable to distinguish it from a clean PLAY. This is a remote, unauthenticated, low-complexity integrity flaw (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) affecting any product that embeds Netty and exposes an RTSP listener, including the Red Hat components named in the advisory such as AMQ Broker 7, AMQ Clients, Quarkus, Camel for Quarkus 3/Spring Boot 4, Keycloak, JBoss EAP 7/8, Single Sign-On 7, Data Grid 8, Fuse 7, Debezium 3, and Apicurio Registry 3. Real security impact is gated on a downstream disagreement: a front-end proxy, WAF, gateway, or access-control layer must parse the RTSP method differently from Netty for method/request smuggling to produce genuine integrity effects, and exposure is narrow because RTSP listeners are far less commonly internet-facing than HTTP. Exploitation status: no public exploit identified at time of analysis and no CISA KEV confirmation, though the upstream advisory itself documents a minimal wire-level reproduction at a high level.
Remote unauthenticated attackers can exhaust memory in Netty-based services that parse PROXY protocol v2, due to a reference-count leak in the handling of nested TLVs within HAProxyMessageDecoder, leading to denial of service. The flaw is an incomplete fix of upstream PR #16881, so partially patched deployments may remain vulnerable through the grandchild-TLV code path. It affects numerous Red Hat products bundling Netty, such as JBoss EAP 7, Keycloak, and Quarkus, and no public exploit code has been identified at time of analysis.
Unbounded heap memory consumption in Netty's HttpServerCodec (io.netty:netty-codec-http) lets a remote, unauthenticated attacker drive a denial of service by exhausting server memory. An attacker who pipelines multiple HTTP/1.1 requests on a single connection and withholds reads prevents the internal methodOverflowQueue from being drained, so memory grows without limit; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is availability-only with no confidentiality or integrity impact, and no public exploit code was identified at time of analysis. Any HTTP/1.1 server built on the default Netty codec behavior is affected, and fixes ship in Netty 4.1.138.Final and 4.2.18.Final, with corresponding patched Red Hat product builds referenced through the Red Hat advisory.
Unbounded remote-initiated stream creation in Netty's SpdySessionHandler allows an unauthenticated, network-positioned attacker to exhaust JVM heap and direct memory on any application that exposes a SPDY endpoint, producing OutOfMemoryError and a denial of service. The handler initializes localConcurrentStreams to Integer.MAX_VALUE and provides no API to change it, so no supported configuration knob reduces the exposure once SPDY is reachable; Netty 4.1.x before 4.1.138.Final and 4.2.x before 4.2.18.Final are affected, along with the Red Hat products that bundle those versions (AMQ Broker and AMQ Clients, Camel for Quarkus 3 and for Spring Boot 4, Keycloak, Quarkus, Debezium, Apicurio Registry, Data Grid, Fuse, JBoss EAP 7/8, and RH-SSO 7). Exploitation requires the target application to have explicitly wired the SPDY handler into its Netty pipeline, since SPDY is a deprecated protocol that is not enabled by default; there is no public exploit identified at time of analysis, and the CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) reflects a low-complexity, availability-only denial of service with no confidentiality or integrity impact.
Heap exhaustion in Netty's Redis array aggregator, as shipped inside Red Hat products such as JBoss Enterprise Application Platform 7, Red Hat Fuse 7, Red Hat Build of Apache Camel for Spring Boot 4, and Red Hat Single Sign-On 7, lets a remote unauthenticated attacker crash the JVM by sending a tiny stream of nested RESP array headers. Because the decoder eagerly allocates an ArrayList sized to the declared array length before any child element arrives, roughly 12 KB of crafted input can reserve about 1.02 billion child slots when the default 1024-level nesting limit and default element limit are in effect; the impact is availability-only, with no data read or modified. Exploitation is limited to deployments that feed attacker-reachable, untrusted RESP/Redis-protocol traffic into the Netty codec with the default constructor; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Unauthenticated remote attackers can cause a gradual denial of service in applications that use Netty's STOMP codec by sending a STOMP frame body without the terminating null byte; StompSubframeDecoder leaks a ByteBuf for each such frame, so sustained traffic exhausts JVM heap or direct memory. The issue carries CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning network-reachable, no authentication or user interaction, availability-only impact. Red Hat middleware products listed in CPE data are affected when STOMP-over-TCP/WebSocket is enabled; no public exploit code or confirmed active exploitation was identified at time of analysis, and a practical DoS requires repeated frames rather than a single packet.
TLS hostname verification is silently bypassed in Netty's OpenSSL client path, allowing a network man-in-the-middle attacker to intercept encrypted communications by presenting a certificate issued for a different hostname. Affected are applications using io.netty:netty-handler versions 4.2.0.Final through 4.2.16.Final or any 4.1.x through 4.1.136.Final, specifically when the SslProvider.OPENSSL client path is configured with a plain X509TrustManager and running on Java 25 or later, where Unsafe-based trust-manager wrapping is unavailable. No public exploit code has been identified at time of analysis, but the confidentiality impact is high for any affected deployment that transmits sensitive data over TLS.
Mutual-TLS authentication bypass in the Netty network framework (io.netty.handler.ssl.SslClientHelloHandler) lets an unauthenticated remote attacker reach routes protected only by per-SNI clientAuth=REQUIRE. A ClientHello whose 4-byte handshake header is split across TLS records trips a wrong-offset bounds check, throwing IndexOutOfBoundsException and calling select(ctx, null), which falls back to the default SslContext (clientAuth NONE/OPTIONAL) instead of the SNI-matched context. Fixed in 4.1.137.Final and 4.2.17.Final; no public exploit identified at time of analysis, but the CVSS 4.0 base score is 9.1 (Critical).
Denial-of-service via quadratic CPU exhaustion in Netty's SniHandler affects all Netty deployments prior to 4.1.137.Final and 4.2.17.Final that use the default SniHandler constructors for TLS termination. An unauthenticated remote peer can fragment a large TLS ClientHello across thousands of small records, causing SslClientHelloHandler#decode to recopy all previously received bytes on every record arrival - O(N²) work that stalls the Netty event loop and denies TLS service to all concurrent clients. No active exploitation is confirmed (not in CISA KEV) and no public proof-of-concept has been identified, but the low attack complexity and zero-authentication requirement make this a credible threat for any internet-exposed Netty TLS endpoint.
Netty's HTTP CORS handler silently rewrites the Vary response header to Vary: Origin in releases before 4.1.137.Final and 4.2.17.Final, letting a shared caching proxy or CDN reuse authenticated, user-specific responses across users and leak sensitive data. Exposure is confined to deployments that install io.netty.handler.codec.http.cors.CorsHandler, also set their own Vary headers (such as Authorization or Cookie) for per-user caching, and sit behind a shared cache; because those three conditions must coincide, the assessed vector raises attack complexity to AC:H even though the published base score is 7.5 (AV:N/PR:N/UI:N/C:H). Publicly available exploit code exists (a public gist alongside the upstream fix PRs), but there is no evidence of active exploitation: the issue is not in CISA KEV, SSVC records Exploitation: none and Automatable: no, and EPSS is only 0.40% (33rd percentile), consistent with the assessment that real-world urgency is much lower than the headline score suggests.
Memory exhaustion in Netty's SctpMessageCompletionHandler (netty-transport-sctp) allows unauthenticated remote peers to drive a JVM into OutOfMemoryError by sending oversized, incomplete SCTP message fragments. The handler enforces limits on concurrent incomplete messages and per-message fragment counts - introduced as a fix for the prior CVE-2026-46340 - but omits a corresponding cap on total buffered bytes. With default settings of 128 messages and 128 fragments, an attacker can buffer approximately 1GB per connection; a small number of concurrent connections suffices to exhaust server heap. Vendor-released patches exist in versions 4.1.137.Final and 4.2.17.Final; no active exploitation or public POC has been identified at time of analysis.
Incremental direct-memory exhaustion in Netty's DNS codec (netty-codec-dns) allows unauthenticated remote attackers to drive a Netty-based DNS server or DnsNameResolver into denial of service by sending DNS packets that carry malformed domain names. Because IDN.toASCII() or the domain-name encoder throws an IllegalArgumentException inside the record constructor before the associated ByteBuf is stored and later released, each crafted packet leaks a small direct-memory buffer; the leak is cumulative, so a sustained packet stream is required to exhaust memory rather than a single request. Affected releases are netty-codec-dns up to and including 4.1.135.Final and 4.2.0.Final through 4.2.15.Final; vendor patches are available in 4.1.136.Final and 4.2.16.Final, EPSS is low (0.33%, 26th percentile), and no public exploit code or confirmed active exploitation was identified at time of analysis.
CPU exhaustion denial of service in Netty's XmlFrameDecoder allows an unauthenticated remote attacker to hang a server's EventLoop thread by trickle-feeding repeated `</` byte sequences to any port where XmlFrameDecoder is in the pipeline. Because the decoder fails to save parser state between `decode()` invocations, each new call rescans the entire accumulated buffer from scratch, producing O(n²) CPU growth that can fully pin a thread with as little as 1 MB of malformed XML data. No public exploit code has been identified at time of analysis, though the GitHub Security Advisory GHSA-v74w-7mr3-4qg3 supplies sufficient technical detail to reproduce the attack. Vendor-released patches are available as Netty 4.1.136.Final and 4.2.16.Final.
Certificate revocation-check bypass in the Netty network framework's OCSP client (io.netty:netty-handler-ssl-ocsp) affects versions 4.2.0.Final through 4.2.15.Final and all releases prior to 4.1.136.Final, where OcspClient.validateResponse never confirms that the CertificateID in an OCSP response matches the certificate being validated. An attacker holding any valid, non-revoked certificate from the same issuing CA can obtain a legitimately signed GOOD response and replay it to make Netty accept a revoked or compromised certificate as valid. Publicly available exploit code exists (a PoC test case in the GHSA advisory), but there is no public exploit identified as being used in active attacks and EPSS risk is low (0.30%, 22nd percentile).
Denial of service in the Netty network framework (4.2.0.Final-4.2.15.Final and 4.1.0.Final-4.1.135.Final) lets a remote unauthenticated peer exhaust JVM direct memory and crash the process. Applications that enable HTTP/2 content decompression via DelegatingDecompressorFrameListener leak one direct ByteBuf for every HTTP/2 DATA frame delivered to a stream whose decompressor has already been closed, because Http2Decompressor.decompress(...) retains the buffer for writeInbound but never releases it on the error path. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided.
XML external entity exposure in the Netty network framework affects the optional XmlDecoder handler in versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, where the underlying Aalto AsyncXMLInputFactory is instantiated without any security hardening. Any remote party able to push bytes into a channel pipeline that contains XmlDecoder can submit XML carrying a DOCTYPE/DTD declaration, and depending on Aalto async parser behavior DTD and entity processing remains active, creating a conditional path to reading local files or performing SSRF-style out-of-band requests. There is no public exploit identified at time of analysis, the issue is not on CISA KEV, and it is fixed in 4.1.136.Final and 4.2.16.Final.
Memory-exhaustion denial of service in Netty's HTTP/3 codec (Http3FrameCodec) affects all releases prior to 4.2.16.Final, where decodeFrame trusts the wire-supplied payLoadLength and buffers reserved-frame-type payloads without an upper bound. A remote unauthenticated attacker (CVSS 7.5, AV:N/PR:N) can open many QUIC streams and advertise very large payload lengths on reserved HTTP/3 frames to force unbounded heap allocation and crash the server. No public exploit or CISA KEV listing exists at time of analysis; a vendor patch (4.2.16.Final) is available.
Uncontrolled native-memory consumption in Netty's SPDY-to-HTTP codec (SpdyHttpDecoder) lets a remote unauthenticated peer exhaust off-heap memory and crash the server. Affected versions are 4.2.0.Final–4.2.15.Final and 4.1.0.Final–4.1.135.Final; the decoder allocates a pooled ByteBuf for an in-flight SYN_STREAM request but fails to release it when the stream is aborted via RST_STREAM or when content exceeds maxContentLength. There is no public exploit identified at time of analysis, and this CVE is not listed in CISA KEV; impact is denial of service only (VC:N/VI:N/VA:H).
Remote denial of service in the Netty networking framework (codec-haproxy module) versions 4.1.0.Final through 4.1.135 and 4.2.0.Final through 4.2.15.Final lets unauthenticated attackers exhaust JVM direct memory. The HAProxyMessageDecoder mis-parses a PROXY protocol v2 header whose version byte is 0xFF, sign-extending it to -1, which collides with the decoder's 'need more data' sentinel, so ByteToMessageDecoder accumulates inbound bytes in an unbounded cumulation buffer until the process runs out of direct memory. No public exploit identified at time of analysis; the CVSS 4.0 score of 8.7 reflects high availability impact with no confidentiality or integrity effect.
Compression-amplification denial of service in the Netty network framework (versions prior to 4.1.136.Final and 4.2.16.Final) allows a remote peer to send a small zlib-compressed SPDY HEADERS block that Netty keeps inflating even after the raw header parser exceeds maxHeaderSize and marks the frame truncated in SpdyFrameCodec. The result is disproportionate CPU consumption and allocation churn (CWE-400) from a tiny input, degrading or crashing services that expose the SPDY codec. No public exploit identified at time of analysis and it is not listed in CISA KEV; impact is availability-only per CVSS 7.5 (A:H).
Memory-amplification denial of service in the Netty network framework (SPDY/3.1 codec) prior to 4.1.136.Final and 4.2.16.Final allows a remote unauthenticated peer to send a single ~2 MiB SPDY SETTINGS frame that forces the server to materialize 262,144 map entries in DefaultSpdySettingsFrame, driving heap growth and ordered-map insertion CPU cost far out of proportion to the input. Affected are Java services that enable Netty's SPDY handler and accept untrusted connections; there is no public exploit identified at time of analysis, and while CVSS is 7.5 the low EPSS-style real-world footprint is tempered by SPDY/3.1 being a deprecated, rarely-enabled protocol.
Denial of service in Netty's io.netty:netty-codec-redis component (prior to 4.1.135.Final and 4.2.15.Final) allows remote attackers to trigger memory exhaustion by sending a crafted RESP array header that declares a huge element count, causing RedisArrayAggregator to pre-allocate an oversized ArrayList before any child messages arrive. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided in the input.
TLS hostname verification is silently disabled in Netty's netty-handler module for any client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager), allowing network attackers in a man-in-the-middle position to present a valid certificate for any host and intercept supposedly encrypted traffic. Affects all Netty versions prior to 4.1.135.Final and 4.2.15.Final; no public exploit identified at time of analysis and EPSS is very low (0.04%), but the defect bypasses a core TLS protection that Netty 4.2 explicitly advertises as enabled by default.
Denial of service in the Netty HTTP/3 codec (io.netty:netty-codec-http3) prior to version 4.2.15.Final allows remote unauthenticated attackers to exhaust server memory by triggering creation of an unbounded number of blocked streams, leading to an OutOfMemoryError. The flaw affects any Java application or service using Netty as an HTTP/3 server. No public exploit identified at time of analysis, and EPSS probability is very low (0.05%, 17th percentile), but the network-reachable nature of the HTTP/3 protocol surface makes patching a priority for exposed endpoints.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resources by rapidly opening and immediately canceling (RST_STREAM) large numbers of streams over a single connection, a technique dubbed the 'Rapid Reset' attack. The flaw is confirmed actively exploited (CISA KEV) following large-scale weaponization observed August through October 2023, with publicly available exploit code and an EPSS score of 94.45% placing it in the 100th percentile for likelihood of exploitation. Virtually every major HTTP/2 stack - including nghttp2, Netty, Envoy, and Eclipse Jetty - is affected.
netty-tcnative through 2.0.83.Final passes the raw SNI server_name from the ClientHello into JNI's NewStringUTF(), which decodes modified UTF-8 rather than standard UTF-8. A remote, unauthenticated client can therefore place the overlong two-byte sequence 0xC0 0x80 in the SNI extension and have it materialize as an embedded U+0000 character inside the Java hostname string handed to SniHostNameMatcher and returned by SSL.getSniHostname(), letting the attacker influence SNI-based certificate selection, access-control decisions and logging. The assessed severity is CVSS 3.1 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N); the library-level corruption is unconditional, but real-world impact is gated on the integrating application actually relying on that hostname for a trust decision or re-encoding it downstream. The advisory documents a deterministic researcher reproduction against an unmodified build; no public exploit code is referenced, and there is no KEV or EPSS signal in the provided data.
Unauthenticated remote attackers can desynchronize HTTP/1.1 response parsing in Netty's HttpServerCodec (io.netty:netty-codec-http) versions 4.2.0.Final through 4.2.16.Final and all versions up to and including 4.1.136.Final by pipelining a GET carrying 'Expect: 100-continue' immediately followed by a HEAD request on the same keep-alive connection. Because the codec pairs each outbound response - including the 100 Continue informational response - with a queued inbound method via pollMethod(), the GET's 200 OK is matched to HEAD and its entity body is dropped, while the following 200 OK (intended for HEAD) is emitted with a body; this misattributes content across responses, enabling response splitting and unsafe reuse of the connection. It is a genuine but moderate-priority integrity flaw (vendor CVSS 4.0 score 6.9; independent assessment CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), with no public exploit identified at time of analysis and vendor-released patches available in 4.2.17.Final and 4.1.137.Final.
Routing and access-control bypass in Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final allows a remote unauthenticated attacker to send a single HEADERS frame with conflicting :authority and host header values, causing different components in a multi-component request path to make inconsistent decisions. This moderate-severity integrity issue is fixed in 4.2.18.Final; no public exploit code or active exploitation has been identified at time of analysis.
HTTP request smuggling in Netty's HTTP/1 decoder lets remote, unauthenticated attackers bypass front-end security controls and reach resources they should not access by sending requests with malformed Transfer-Encoding headers. Netty is a widely embedded Java networking library, so the practical reach spans Red Hat products built on it - AMQ Broker 7, AMQ Clients, Red Hat Build of Keycloak, Red Hat Build of Quarkus, Red Hat Build of Apache Camel (Spring Boot 4 and Quarkus 3), Red Hat Build of Debezium 3, Red Hat Build of Apicurio Registry 3, Red Hat Data Grid 8 and Red Hat Fuse 7 - as well as JBoss EAP 7/8 and Red Hat Single Sign-On 7 per the associated advisory tags. CVSS 3.1 rates it 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), consistent with smuggling-style control bypass rather than full compromise; no public exploit code or confirmed active exploitation was identified at time of analysis, though the flaw is trivially reachable on any exposed HTTP endpoint.
HTTP request smuggling in Netty's netty-codec-http component lets unauthenticated remote attackers bypass front-end security controls by sending a crafted HTTP/1.1 chunk-size token containing whitespace after the hexadecimal digits, which Netty parses differently from other HTTP intermediaries. The flaw carries a CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L), meaning no authentication or user interaction is required, but integrity and availability impact is limited; meaningful exploitation generally depends on a multi-tier topology where a proxy, load balancer, or backend parses the chunk-size token inconsistently with Netty. Red Hat ships the affected library across a broad portfolio - including AMQ Broker 7, AMQ Clients, Quarkus, Keycloak and Red Hat Single Sign-On 7, JBoss EAP 7/8, Fuse 7, Data Grid 8, Camel for Spring Boot 4, Camel 4 for Quarkus 3, Apicurio Registry 3 and Debezium 3 - and no public exploit code has been identified at time of analysis, with no confirmed active exploitation (CISA KEV).
HTTP request smuggling and header injection in Netty's HTTP/2 stack (as bundled in multiple Red Hat products) allow remote unauthenticated attackers to bypass security controls and manipulate requests when HTTP/2 traffic is translated to HTTP/1.1. Affected deployments include Red Hat AMQ Broker 7, Camel, Keycloak, Quarkus, Data Grid, Fuse, EAP, Apicurio Registry, and Debezium. Assessed as high severity (CVSS 3.1 base 7.5, AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:N); exploitation requires the specific topology of an HTTP/2-to-HTTP/1.1 translation boundary, and no public exploit was identified at time of analysis.
This is a real but moderate-priority vulnerability whose severity depends almost entirely on deployment topology rather than the raw 6.5 CVSS score. Netty's HTTP decoder lets split or duplicated Transfer-Encoding header fields slip past its final-chunked validation, so an unauthenticated, remote attacker who can send a raw crafted request to a Netty listener that sits in an HTTP chain with a second HTTP parser (reverse proxy, load balancer, CDN, WAF, or upstream/downstream server) can desynchronize the two parsers and smuggle a request (CWE-444). Impact is confined to low confidentiality and integrity loss (C:L/I:L) with no availability impact, no authentication (PR:N) or user interaction (UI:N) is required, and no public exploit identified at time of analysis.
HTTP request smuggling in Netty's HTTP/1.1 decoder (HttpObjectDecoder and the HttpRequestDecoder built on it) lets remote, unauthenticated attackers send a chunk-size line containing an embedded bare carriage return - for example `0\rX` - because strict chunk-line validation is skipped whenever the size line carries no `;` chunk extension, causing a request-boundary desync when Netty shares a connection with a second HTTP intermediary that frames the message differently. The flaw reaches every application and Red Hat product that embeds Netty, including AMQ Broker 7, AMQ Clients, Quarkus, Camel 4 for Quarkus 3, Camel for Spring Boot 4, Keycloak / Red Hat Single Sign-On, JBoss EAP 7 and 8, Fuse 7, Data Grid 8, Apicurio Registry 3 and Debezium 3, while independent assessment keeps it at CVSS 6.5 with AC:H because a standalone Netty service with no disagreeing proxy in the chain yields little practical smuggling impact. The public report includes a reproducible PoC test harness, but there is no CISA KEV listing and no evidence of active exploitation.
Denial of service in Netty's HTTP/2 HPACK encoder (HpackEncoder) allows an unauthenticated remote attacker to force excessive CPU and memory consumption by sending SETTINGS frames that advertise an oversized MAX_HEADER_TABLE_SIZE, causing the encoder to retain an excessive number of unique header entries. The issue affects applications and Red Hat products that embed Netty and expose an HTTP/2 listener - including JBoss EAP 7 and 8, Keycloak, Red Hat Single Sign-On 7, AMQ Broker 7, Data Grid 8, Fuse 7, Quarkus, Camel 4 for Quarkus 3, Camel for Spring Boot 4, Apicurio Registry 3, and Debezium 3 - while HTTP/1.1-only endpoints are not exposed. Impact is bounded to availability (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, CVSS 5.3) with no data disclosure or modification; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation.
Certificate revocation validation performed by Netty's optional netty-handler-ssl-ocsp module can be silently skipped when the OCSP response omits the optional nextUpdate field, causing the application to proceed with a certificate that should have been rejected. The flaw is remote and requires no credentials or user interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9), but exploitation is conditional: the deployment must actually use the opt-in OCSP-stapling component, and the attacker must control or intercept the OCSP response seen by the client, typically through a man-in-the-middle position or by operating the TLS server whose certificate is being validated. There is no public exploit identified at time of analysis and no KEV listing, and the practical impact is confined to acceptance of a revoked or otherwise unvalidated certificate rather than code execution or data disclosure.
HTTP request smuggling in Netty 4.1.133-4.1.137.Final and 4.2.13-4.2.17.Final allows unauthenticated remote attackers to poison HTTP request queues and bypass intermediary security controls by submitting crafted Transfer-Encoding headers. The HttpObjectDecoder's final-coding validation was flawed: both split multi-line TE headers and comma-separated values like 'chunked, xchunked' bypassed the 'chunked must be last' check, causing Netty to interpret message framing differently from upstream proxies. Fixed releases 4.1.138.Final and 4.2.18.Final enforce RFC 9112-compliant validation across all TE header fields; no public exploit code or CISA KEV listing has been identified at time of analysis.
Null byte and CRLF injection in Netty's SOCKS4 and SOCKS5 client encoders (Socks4ClientEncoder, Socks5ClientEncoder) allows an attacker who controls domain address or authentication fields to truncate or alter proxy connection parameters, enabling domain spoofing, userid truncation, authentication data injection, and protocol confusion. Affected are all Netty releases in the 4.1.x branch through 4.1.136.Final and the 4.2.x branch through 4.2.16.Final - both branches have been patched. No public exploit code has been identified at time of analysis and this CVE is not listed in CISA KEV, but the integrity impact on downstream SOCKS proxy routing is concrete.
Netty's RedisArrayAggregator codec fails to release retained partial aggregate state when the maxElements limit is exceeded, unlike the symmetric maxNestedArrayDepth branch which correctly calls releaseAndClearDepths() before throwing. In applications that keep the channel alive after a codec exception - a common resilience pattern - an unauthenticated peer can exploit this inconsistency to keep attacker-controlled ByteBuf references pinned in Netty's pooled buffer allocator and cause subsequent messages to be consumed into the stale pre-error aggregate. A public proof-of-concept test is included in the GHSA advisory; fixed in Netty 4.1.136.Final and 4.2.16.Final with no KEV listing at time of analysis.
Cross-origin resource sharing controls in Netty's CorsHandler can be entirely bypassed by sending an `Origin: null` header, due to a logical operator error in the origin evaluation path. Affected are Netty 4.1.0.Final through 4.1.135.Final and 4.2.0.Final through 4.2.15.Final - a range spanning years of releases across both major active branches. An unauthenticated remote attacker who can induce a victim to initiate a cross-origin request can bypass the `shortCircuit()` enforcement entirely, causing unauthorized requests to be forwarded to the backend application as if they were permitted. No public exploit or KEV listing is identified at time of analysis, but the bypass mechanism is straightforward and vendor-confirmed.
Netty's HTTP/2 codec mishandles the SETTINGS_MAX_HEADER_LIST_SIZE client setting, enabling a denial-of-service attack functionally equivalent to HTTP/2 Rapid Reset (CVE-2023-44487) but with a distinct on-wire signature. Affected Netty versions prior to 4.1.135.Final and 4.2.15.Final fully process and proxy incoming requests to the origin before encountering an exception during response header serialization, consuming server resources without completing responses. No public exploit has been identified at time of analysis, and EPSS stands at 0.02% (5th percentile), though the attack technique parallels a well-documented catastrophic DDoS class.
HTTP request smuggling in Netty's HttpObjectDecoder (netty-codec-http) allows unauthenticated remote attackers to manipulate request-boundary parsing in pipelined or multiplexed deployments by injecting non-CRLF ISO control characters (NUL, SOH, STX, etc.) before the HTTP request-line. Affected are all Netty releases prior to 4.1.135.Final and 4.2.15.Final; both branches have vendor-confirmed patches. No public exploit code has been identified and EPSS is 0.04% (12th percentile), indicating low current exploitation likelihood, though the attack surface expands significantly in architectures fronted by proxies or load balancers that strip or interpret those control bytes differently than Netty does.
Stateless reset token leakage in Netty's QUIC codec (io.netty:netty-codec-classes-quic prior to 4.2.15.Final) enables an on-path attacker to derive the reset token for active connections and terminate them via spoofed Stateless Reset packets. The default HMAC-based generators expose a deterministic relationship between the source connection ID visible in QUIC headers and the server's stateless reset token - after a source-CID rotation, an observer can compute the token from the new connection-ID bytes. No public exploit identified at time of analysis; the CVSS 4.8 Medium rating reflects the on-path attacker prerequisite (AC:H), which meaningfully limits opportunistic exploitation.
Truncation of chunked Oblivious HTTP (OHTTP) streams in netty-incubator-codec-ohttp prior to 0.0.22.Final silently passes partial, cryptographically-incomplete messages to the receiving application with no decryption error or exception. An on-path adversary - the OHTTP relay itself or a MITM on the relay↔gateway or relay↔client transport - can cut a legitimate chunked-OHTTP message at any non-final chunk boundary and cleanly close the outer HTTP body, bypassing the cryptographic integrity guarantee the final-chunk marker is designed to provide. No public exploit is identified (CVSS E:U) and no CISA KEV listing exists, but the integrity impact is rated High (VI:H) given that receivers silently accept and may act on structurally incomplete messages.
Incorrect native memory address resolution in Netty's Oblivious HTTP (OHTTP) BoringSSL JNI bridge allows unauthenticated remote attackers to corrupt memory belonging to concurrent connections and disclose the contents of adjacent pooled direct buffers - including HPKE encryption key material - on affected OHTTP gateways. The flaw exists in versions prior to 0.0.22.Final of netty-incubator-codec-ohttp and is only reachable when the JVM is configured to deny `sun.misc.Unsafe` access, causing the vulnerable fallback address-resolution path to activate. This directly undermines the confidentiality guarantees Oblivious HTTP is designed to provide; no public exploit code exists and the vulnerability is not listed in the CISA KEV catalog (CVSS 4.0 E:U).
CRLF injection in Netty's io.netty.handler.codec.http.HttpRequestEncoder (netty-codec-http) allows an attacker-influenced request URI to be written verbatim into the outbound HTTP request line, enabling HTTP request smuggling against upstream/back-end servers. The flaw affects netty-codec-http versions prior to 4.1.129.Final and the 4.2.x line from 4.2.0.Alpha1 up to (but not including) 4.2.8.Final, and is unauthenticated per the CVSS vector (AV:N/PR:N/UI:N) with low confidentiality and integrity impact (CVSS 6.5). Publicly available exploit code exists, including a reproducer in the GitHub Security Advisory, and exploitation is conditional: it requires an application that uses HttpRequestEncoder (typically via HttpClientCodec) and passes unsanitized or attacker-controlled data into the request URI. There is no confirmed active exploitation (not in CISA KEV); Netty's default HTTP header validator blocks CRLF in headers but does not sanitize the URI.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 6.9), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty is an asynchronous event-driven network application framework for development of maintainable high performance protocol servers and clients. Rated low severity (CVSS 2.9), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty is an asynchronous, event-driven network application framework. Rated high severity (CVSS 8.2), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Netty, an asynchronous, event-driven network application framework, has a vulnerability in versions up to and including 4.1.118.Final. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Netty, an asynchronous, event-driven network application framework, has a vulnerability starting in version 4.1.91.Final and prior to version 4.1.118.Final. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Public exploit code available.
The netty incubator codec.bhttp is a java language binary http parser. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
netty-incubator-codec-ohttp is the OHTTP implementation for netty. Rated critical severity (CVSS 9.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Netty project is an event-driven asynchronous network application framework. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty project is an event-driven asynchronous network application framework. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Netty is an open-source, asynchronous event-driven network application framework. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Public exploit code available.
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This HTTP Request/Response Smuggling vulnerability could allow attackers to manipulate HTTP request interpretation between frontend and backend servers.
The Snappy frame decoder function doesn't restrict the chunk length which may lead to excessive memory usage. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
The Bzip2 decompression decoder function doesn't allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression). Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. This HTTP Request/Response Smuggling vulnerability could allow attackers to manipulate HTTP request interpretation between frontend and backend servers.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.9), this vulnerability is remotely exploitable, no authentication required. This HTTP Request/Response Smuggling vulnerability could allow attackers to manipulate HTTP request interpretation between frontend and backend servers.
Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Public exploit code available.
The ZlibDecoders in Netty 4.1.x before 4.1.46 allow for unbounded memory allocation while decoding a ZlibEncoded byte stream. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Allocation of Resources Without Limits vulnerability could allow attackers to exhaust system resources through uncontrolled allocation.
Netty 4.1.43.Final allows HTTP Request Smuggling because it mishandles Transfer-Encoding whitespace (such as a [space]Transfer-Encoding:chunked line) and a later Content-Length header. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a "Transfer-Encoding : chunked" line), which leads to HTTP request smuggling. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Netty before 3.9.8.Final, 3.10.x before 3.10.3.Final, 4.0.x before 4.0.28.Final, and 4.1.x before 4.1.0.Beta5 and Play Framework 2.x before 2.3.9 might allow remote attackers to bypass the httpOnly. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
handler/ssl/OpenSslEngine.java in Netty 4.0.x before 4.0.37.Final and 4.1.x before 4.1.1.Final allows remote attackers to cause a denial of service (infinite loop). Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
The SslHandler in Netty before 3.9.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a crafted SSLv2Hello message. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
WebSocket08FrameDecoder in Netty 3.6.x before 3.6.9, 3.7.x before 3.7.1, 3.8.x before 3.8.2, 3.9.x before 3.9.1, and 4.0.x before 4.0.19 allows remote attackers to cause a denial of service (memory. Rated medium severity (CVSS 5.0), this vulnerability is remotely exploitable, low attack complexity.