CVE-2026-73508

Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.dns.AbstractDnsRecord, io.netty.handler.codec.dns.DefaultDnsRecordDecoder.decodeRecord(), and io.netty.handler.codec.dns.DnsCodecUtil.decompressDomainName() failed to release retained or newly allocated ByteBuf objects when IDN.toASCII() or encodeDomainName() rejected a malformed domain name, allowing unauthenticated remote DNS packets to leak direct memory incrementally until denial of service. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

Summary

A memory leak can be caused in Netty's DNS codec by sending malicious DNS packets containing invalid domain names. Because the leak occurs incrementally per packet, sustained malicious requests will cause a gradual Denial of Service.

Details

Inside io.netty.handler.codec.dns.AbstractDnsRecord, the parsed domain name string is passed to IDN.toASCII(name). If the domain name contains characters that violate IDNA rules, IDN.toASCII throws an IllegalArgumentException.

Because this exception occurs inside the constructor before the DnsRecord instance can assign the buffer to its content field for later release, the ByteBuf whose reference count was incremented (or newly allocated) is never released, resulting in a direct memory leak.

There are several places where variants of this leak happen:

• io.netty.handler.codec.dns.DefaultDnsRecordDecoder#decodeRecord(java.lang.String, io.netty.handler.codec.dns.DnsRecordType, int, long, io.netty.buffer.ByteBuf, int, int) invokes in.retainedDuplicate() or creates a new buffer out when constructing DefaultDnsRawRecord
• io.netty.handler.codec.dns.DnsCodecUtil#decompressDomainName allocates a new ByteBuf and passes it to encodeDomainName(). If the decompressed domain name contains a null byte (\0), encodeDomainName() throws an IllegalArgumentException, leaking the newly allocated buffer.

Impact

Resource Exhaustion. Any application utilizing Netty's DnsRecordDecoder (such as DnsNameResolver or custom DNS servers) is vulnerable.

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Red Hat Lightwell has released io.netty:netty-codec-dns 4.1.100.Final-rhlw-00001 with backported fixes for CVE-2026-42579 and CVE-2026-73508.

CVE-2026-42579: Netty: DNS Codec Input Validation Bypass in Netty (Encoder + Decoder)

CVE-2026-73508: Netty: Memory Leak in DNS Record Decoder via Malformed Domain Names

This patched artifact is a drop-in replacement for io.netty:netty-codec-dns 4.1.100.Final from Maven Central.

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.dns.AbstractDnsRecord, io.netty.handler.codec.dns.DefaultDnsRecordDecoder.decodeRecord(), and io.netty.handler.codec.dns.DnsCodecUtil.decompressDomainName() failed to release retained or newly allocated ByteBuf objects when IDN.toASCII() or encodeDomainName() rejected a malformed domain name, allowing unauthenticated remote DNS packets to leak direct memory incrementally until denial of service. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

TuxCare rebuilt 47 io.netty packages to address 23 CVEs. Fixed in 4.1.135.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 23 CVEs. Fixed in 4.1.130.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 59 CVEs. Fixed in 4.1.122.Final-tuxcare.2.

TuxCare rebuilt 47 io.netty packages to address 60 CVEs. Fixed in 4.1.119.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 41 CVEs. Fixed in 4.1.112.Final-tuxcare.6.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.111.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 48 CVEs. Fixed in 4.1.117.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.108.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.107.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.94.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 14 CVEs. Fixed in 4.1.115.Final-tuxcare.8.

TuxCare rebuilt 46 io.netty packages to address 22 CVEs. Fixed in 4.1.79.Final-tuxcare.4.