CVE-2026-45416: Netty excessive memory allocation in SNIHandler

CVE-2026-45416 · Severity: high · CVSS 7.5 · Published 2026-06-12

Netty is a widely used networking framework for building high-performance servers and clients. A vulnerability in its TLS handling component allows an attacker to force the server to allocate large amounts of memory using very small network requests. This can lead to a denial-of-service (DoS) condition where the server runs out of memory and crashes or becomes unresponsive, disrupting business operations.

Technologies: io.netty:netty-handler (Maven). Vendors: Maven.

Quick answers

Is CVE-2026-45416 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-45416 being exploited in the wild.
How severe is CVE-2026-45416?
High severity, with a CVSS score of 7.5, published 12 June 2026.
Which products and versions are affected?
io.netty:netty-handler (Maven) ECOSYSTEM:introduced=4.2.0.Final,fixed=4.2.15.Final.
Is there a fix for CVE-2026-45416?
Yes. io.netty:netty-handler (Maven): upgrade to 4.2.15.Final or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-45416 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-45416?
Check whether you run io.netty:netty-handler (Maven) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • io.netty:netty-handler (Maven): upgrade to 4.2.15.Final or later
    # set io.netty:netty-handler to 4.2.15.Final in your pom.xml or build.gradle

Technical details

A resource exhaustion vulnerability exists in Netty's SslClientHelloHandler.decode() due to improper validation of the TLS handshake length. When using common SniHandler or AbstractSniHandler constructors, the 'maxClientHelloLength' guard is disabled (set to 0), allowing the handler to eagerly allocate a buffer based on the 24-bit handshake length provided in the ClientHello. An attacker can send a small request (as few as nine bytes) that specifies a 16 MiB handshake length, forcing an immediate unpooled memory allocation that is retained until the channel closes. This can be exploited remotely without authentication to exhaust server memory. The issue is fixed in versions 4.1.135.Final and 4.2.15.Final by implementing sane default limits for ClientHello length and timeouts.

Affected products

  • Netty netty-handler < 4.1.135.Final, 4.2.0.Final - 4.2.14.Final

Identifiers

  • CVE-2026-45416
  • GHSA-x4gw-5cx5-pgmh

Timeline

  • 2026-06-02: patched: Versions 4.1.135.Final and 4.2.15.Final released
  • 2026-06-05: advisory: GitHub Security Advisory GHSA-x4gw-5cx5-pgmh published
  • 2026-06-12: disclosed: NVD publication date

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.