Skip to main content

Netty CVE-2026-45416

| EUVDEUVD-2026-36436 HIGH
Allocation of Resources Without Limits or Throttling (CWE-770)
2026-06-08 https://github.com/netty/netty GHSA-x4gw-5cx5-pgmh
Denial Of Service
7.5
CVSS 3.1 · Vendor: https://github.com/netty/netty
Share

Severity by source

Vendor (https://github.com/netty/netty) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
SUSE
HIGH
qualitative
Red Hat
7.5 HIGH
qualitative

Primary rating from Vendor (https://github.com/netty/netty).

CVSS VectorVendor: https://github.com/netty/netty

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 08, 2026 - 23:30 vuln.today
Analysis Generated
Jun 08, 2026 - 23:30 vuln.today

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 686 maven packages depend on io.netty:netty-handler (317 direct, 369 indirect)

Ecosystem-wide dependent count for version 4.2.0.Final.

DescriptionCVE.org

SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates ctx.alloc().buffer(handshakeLength) (line 161). The guard at line 140 is handshakeLength > maxClientHelloLength && maxClientHelloLength != 0, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes.

AnalysisAI

Remote denial-of-service in Netty's netty-handler component allows unauthenticated attackers to exhaust server memory by sending a crafted TLS ClientHello with an attacker-controlled 24-bit handshake length field, triggering an immediate ~16 MiB unpooled heap allocation per connection. Affects Netty 4.1.x through 4.1.134.Final and 4.2.x through 4.2.14.Final when using the default SniHandler/AbstractSniHandler constructors, which disable both the length guard and handshake timeout. No public exploit identified at time of analysis, but the trivial nine-byte trigger and CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/A:H) make weaponization straightforward.

Technical ContextAI

Netty is a high-performance asynchronous network application framework widely used to build Java-based servers, proxies, and clients (Spring WebFlux, Vert.x, gRPC-Java, Elasticsearch, etc.). The vulnerable code path is in SslClientHelloHandler.decode() within io.netty:netty-handler: it parses the 24-bit handshake length from a TLS ClientHello and, when the record spans multiple TLS records, calls ctx.alloc().buffer(handshakeLength) at line 161 to pre-allocate the full reassembly buffer. The guard at line 140 only fires when maxClientHelloLength is non-zero, but the commonly used SniHandler(Mapping), SniHandler(AsyncMapping), and AbstractSniHandler() constructors default both maxClientHelloLength and handshakeTimeoutMillis to 0, disabling the size check and any timeout. Because 16 MiB exceeds Netty's default pooled chunk size, the allocator falls back to an unpooled huge allocation that is retained until the channel closes - the textbook CWE-770 (Allocation of Resources Without Limits or Throttling) pattern.

RemediationAI

Vendor-released patches are available: upgrade io.netty:netty-handler to 4.1.135.Final on the 4.1 branch or 4.2.15.Final on the 4.2 branch (see https://github.com/netty/netty/security/advisories/GHSA-x4gw-5cx5-pgmh). If immediate upgrade is not possible, the supported workaround is to instantiate SniHandler/AbstractSniHandler with explicit non-zero values for maxClientHelloLength (a realistic ClientHello rarely exceeds 16 KiB - values in the 16384-65535 range cap the allocation while preserving legitimate large ClientHellos with many SNI/ALPN extensions) and handshakeTimeoutMillis (e.g. 10000) so the length guard and timeout become active; the trade-off is that legitimate clients sending oversized ClientHellos will be dropped, which is generally acceptable. Additional compensating controls include placing a TLS-terminating reverse proxy (nginx, HAProxy, AWS NLB/ALB with TLS) in front of the Netty endpoint, rate-limiting new TLS connections per source IP at the network edge, and lowering JVM heap or container memory limits combined with monitoring for sudden direct/heap buffer growth so a DoS attempt triggers alerts before exhaustion.

Same weakness CWE-770 – Allocation of Resources Without Limits or Throttling

View all
CVE-2017-8779 HIGH POC
7.5
CVE-2025-53521 CRITICAL POC
9.3
CVE-2017-5850 HIGH POC
7.5
CVE-2025-26682 HIGH
7.5
CVE-2025-26466 MEDIUM
5.9
CVE-2020-37067 CRITICAL POC
9.8
CVE-2021-47875 CRITICAL POC
9.8
CVE-2023-38507 CRITICAL POC
9.8

Same technique Denial Of Service

View all
CVE-2015-5119 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2011-0611 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8
CVE-2012-0507 CRITICAL POC
9.8
CVE-2014-1761 HIGH POC
7.8
CVE-2015-5122 CRITICAL POC
9.8
CVE-2011-0609 HIGH POC
7.8

Vendor StatusVendor

SUSE

Severity: Important
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise High Performance Computing 15 SP4-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-LTSS Affected

Share

CVE-2026-45416 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy