CVE-2026-45674 is a DNS cache poisoning flaw in Netty's resolver, scored 8.7 (high) in NVD. It trusts CNAME records without checking they belong to the queried domain. Upgrade netty-resolver-dns to 4.1.135.Final or 4.2.15.Final.
What's affected
The GitHub advisory names the Maven artifact io.netty:netty-resolver-dns:
- 4.2.0.Final through 4.2.14.Final, fixed in 4.2.15.Final
- 4.1.134.Final and earlier, fixed in 4.1.135.Final
The advisory lists no workaround. Upgrading is the only remedy it gives. Red Hat has also published errata for its own builds (RHSA-2026:26017, RHSA-2026:26018 and RHSA-2026:26586), so if you run Red Hat packaged software, check those.
The CVSS vector is AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N. High attack complexity reflects that an attacker has to be in a position to influence DNS responses.
How to check if you're exposed
Netty is pulled in by many frameworks, so look at the resolved dependency tree.
mvn dependency:tree -Dincludes=io.netty:netty-resolver-dns
gradle dependencies | grep netty-resolver-dns
If the artifact is absent, the DNS resolver module is not on your classpath. If it is present, note the version. Also check fat jars and container images, since they bundle their own copies and a source tree check will miss them.
What to do now
- Run the commands above for each Java service and write down the netty-resolver-dns version.
- Move 4.1 users to 4.1.135.Final or later, and 4.2 users to 4.2.15.Final or later.
- If a framework pins Netty, override it with a dependency management entry, or upgrade the framework to a release that ships the fix.
- Rebuild and redeploy. Scan container images for old jars.
- Where you cannot upgrade soon, use resolvers you trust and consider DNSSEC validating resolvers upstream. This is general hardening, not advisory guidance.
Why it matters
The weaknesses are CWE-345, insufficient verification of data authenticity, and CWE-346, origin validation error. In DnsResolveContext#buildAliasMap, the resolver reads the answer section of a DNS response and caches every CNAME it finds. It does not check that the record falls inside the bailiwick, the domain the query was meant for. RFC 5452 advises that check.
Without it, a response can carry an alias for a name nobody asked about, and later lookups of that name resolve wrongly. For a service that makes outbound calls by hostname, that can send traffic to the wrong place. The KEV flag is false and I found no report of exploitation.
Try it yourself
Many Netty jars sit deep in the tree and never get called by your own code. Reachability analysis helps decide what to patch first.
Click through it at your own pace, or open it full screen.
Quick check
Does this affect me if I use Netty only as an HTTP server?
The flaw is in the DNS resolver module. A server that never resolves names through Netty's DNS resolver is less likely to hit it, but confirm that with the dependency tree and your code, and upgrade anyway.
Is there a configuration switch that turns the problem off?
The advisory lists none. Plan on the upgrade.
Sources
Last reviewed: 19 October 2026.
