CVE-2026-73508 is a memory leak (CWE-772) in the DNS codec of Netty, the Java network framework. Malformed domain names in DNS packets leave buffers unreleased until memory runs out. The record rates it Medium at 5.3. It is fixed in Netty 4.1.136.Final and 4.2.16.Final, so upgrade.
What's affected
The record says versions before 4.1.136.Final, and before 4.2.16.Final on the 4.2 line, are affected. The GitHub advisory (GHSA-mfg7-5gfp-c4w3) lists those same two versions as patched.
The advisory names the classes involved: AbstractDnsRecord, DefaultDnsRecordDecoder and DnsCodecUtil in the io.netty.handler.codec.dns package. You are exposed only if your application, or a library it uses, decodes DNS records with Netty, for example a DNS server, a resolver or a DNS proxy that accepts packets from untrusted sources. A plain web service that never touches the DNS codec is much less likely to be affected.
The record scores it 5.3 (Medium), with no privileges needed and availability as the only impact. Because the leak is gradual, the practical risk depends on how much traffic an attacker can send and how much direct memory your process has.
How to check if you're exposed
Netty is usually pulled in indirectly, so list the resolved versions rather than reading your own build file.
mvn dependency:tree -Dincludes=io.netty
./gradlew dependencies | grep netty
Look at netty-codec-dns, netty-handler and the netty-all artifact if you use it. Note that one application can resolve to more than one Netty version when frameworks bring their own, and some products bundle Netty inside a shaded jar that these commands do not show. For those, check the vendor's release notes, or scan the built artifact or container image instead of the source tree.
What to do now
- Upgrade Netty to 4.1.136.Final or later on the 4.1 line, or 4.2.16.Final or later on the 4.2 line.
- If Netty arrives through another framework, bump that framework or add a dependency management override, and confirm with the dependency tree.
- For shaded or bundled copies, ask the vendor which release contains the fixed Netty.
- Watch direct buffer memory on services that handle DNS packets. A slow upward line that never drops is the pattern the advisory describes.
- Restrict who can send DNS packets to those services where you can, for example to your own network.
Why it matters
The weakness is a failure to release a resource after its useful life, CWE-772. Netty uses reference counted buffers outside the Java heap. Code that creates or retains one must release it, including on error paths. The advisory explains that when IDN.toASCII rejects a malformed domain name, an exception is thrown before the record object can take ownership of the buffer, so nobody releases it.
Error paths are where this kind of bug hides, because tests cover the successful case. The impact is slow but real: each bad packet costs a little direct memory, and a patient sender can exhaust it. Direct memory is not visible in ordinary heap graphs, which makes it harder to spot. The record's KEV flag is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is the score only Medium?
The attack gives no access to data or code. It only affects availability, and it takes sustained traffic to matter.
Does a restart fix it?
A restart frees the memory and resets the clock, but the leak resumes as malformed packets arrive. Only the upgrade removes the cause.
Sources
- GitHub advisory GHSA-mfg7-5gfp-c4w3
- Netty 4.1.136.Final release notes
- Netty 4.2.16.Final release notes
Last reviewed: 18 October 2026.
