Netty CVE-2026-45674: Brief Summary of DNS Cache Poisoning via Bailiwick Bypass in CNAME Resolution

Introduction

Netty's DNS resolver was missing an origin validation check, so crafted DNS responses could poison its internal CNAME cache and silently redirect later domain resolutions to attacker-controlled hosts. Any Java application that uses Netty's netty-resolver-dns module for outbound connections is exposed. That includes transitive consumers across the ecosystems of Apple, Google, Netflix, Apache Hadoop, and Apache Spark. An attacker can intercept that traffic invisibly, without directly compromising the application.

Technical Information

Root Cause: Missing Bailiwick Validation in buildAliasMap

The vulnerability is in the buildAliasMap method of io.netty.resolver.dns.DnsResolveContext, the class that processes DNS query responses in Netty's resolver. When this method finds CNAME (Canonical Name) records in the ANSWER section of a DNS response, it caches every one of them. It never checks whether the responding name server is actually authoritative for the domain in the CNAME's owner name.

That missing check is known as bailiwick validation. RFC 5452 requires DNS resolvers to accept data only if the originator is authoritative for the QNAME or a parent of the QNAME. Netty's resolver ignored this requirement entirely. It cached any CNAME record in a DNS response as legitimate, whatever its relationship to the original query.

The vulnerability is classified under CWE-345 (Insufficient Verification of Data Authenticity), which MITRE defines as a condition where "the product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data."

Attack Flow

Exploitation of CVE-2026-45674 follows a DNS cache poisoning pattern:

1. Attacker positioning: The attacker must be able to inject or spoof DNS responses that reach the Netty resolver before (or instead of) legitimate responses. That takes either a man-in-the-middle position on the network path between the Netty resolver and its upstream DNS server, or the ability to race legitimate DNS responses.

2. Crafted DNS response: The attacker builds a response to a legitimate query (for example, a query for x.netty.io) that includes extra CNAME records for unrelated domains. The response might contain a valid CNAME mapping x.netty.io → cname.netty.io alongside a malicious out-of-bailiwick CNAME mapping cname.netty.io → evil.com.

3. Cache poisoning: The vulnerable buildAliasMap method does not check whether each CNAME record falls within the authority boundary of the original query, so it caches both the legitimate and the malicious records.

4. Traffic redirection: Later DNS resolutions that hit the poisoned cache entries resolve to the attacker-controlled destination. Downstream applications using the default Netty DNS resolver may then connect to malicious IPs, which opens the door to traffic interception, credential theft, or data exfiltration.

CVSS Vector Analysis

The CVSS v3.1 base score is 8.7 (HIGH), with vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N:

The scope is Changed because a poisoned DNS cache affects the resolver and every downstream component that relies on it for name resolution.

Amplification via Companion Vulnerabilities

Two companion vulnerabilities in the same netty-resolver-dns module significantly affect the overall risk.

CVE-2026-45673 covers a predictable PRNG and a default static source port in Netty's DNS resolver, which together enable classic Kaminsky-style DNS cache poisoning. An attacker who uses CVE-2026-45673 to predict DNS transaction IDs and send spoofed responses from a static source port can then use CVE-2026-45674 to get out-of-bailiwick CNAME records accepted and cached. Chained this way, two individually complex exploits become a more feasible combined attack.

CVE-2026-47691 covers insufficient bailiwick validation for NS (Name Server) records. It is the same class of vulnerability, applied to a different record type.

All three CVEs are fixed in the same versions (4.1.135.Final and 4.2.15.Final), and organizations should address them together.

Patch Information

The Netty project fixed CVE-2026-45674 in Pull Request #16873, authored by Norman Maurer (@normanmaurer) and merged on June 2, 2026 (commit 5749d782). The fix shipped on two release branches, Netty 4.1.135.Final and Netty 4.2.15.Final, both published the same day. The GitHub Security Advisory is GHSA-676x-f7gg-47vc.

What Changed

The core fix adds a bailiwick validation check to the buildAliasMap method of DnsResolveContext.java. The method signature now takes the original query name as a new parameter. Before writing a CNAME mapping into the cache, the method checks that the CNAME record's owner name falls within the authority boundary of the queried domain:

String queryNameWithDot = hostnameWithDot(queryName.toLowerCase(Locale.US));
// Only cache the CNAME if the owner is in the bailiwick of the original query name.
boolean inBailiwick = nameWithDot.equals(queryNameWithDot) ||
        nameWithDot.endsWith("." + queryNameWithDot);
if (inBailiwick) {
    cache.cache(nameWithDot, mappingWithDot, r.timeToLive(), loop);
}

If you query x.netty.io, a CNAME record whose owner name is x.netty.io (exact match) is treated as legitimate and cached. A CNAME for a subdomain such as sub.x.netty.io (ends with .x.netty.io.) also passes. A CNAME record for an unrelated domain like evil.com fails both conditions and is silently discarded.

Both call sites in DnsResolveContext.java that invoke buildAliasMap now pass the question name through:

// Before (vulnerable):
buildAliasMap(envelope.content(), cnameCache(), parent.executor())

// After (patched):
buildAliasMap(question.name(), envelope.content(), cnameCache(), parent.executor())

That covers the explicit CNAME query path (onResponseCNAME) and the A/AAAA resolution path (onExpectedResponse), so no caller is left on the old behavior.

Regression Test

The commit also adds a unit test, testCnameCacheBailiwick, in DnsNameResolverTest.java. The test starts a mock DNS server that returns both a valid in-bailiwick CNAME (x.netty.io → cname.netty.io) and a malicious out-of-bailiwick CNAME (cname.netty.io → evil.com). It then asserts that the valid mapping is cached and the out-of-bailiwick mapping is rejected. The assertion assertNull(cache.get("cname.netty.io.")) confirms the poisoning vector is blocked.

In total, the patch touches 2 files with 87 additions and 5 deletions: 18 lines changed in DnsResolveContext.java for the production logic, and 74 lines added to DnsNameResolverTest.java for the regression test.

Detection Methods

CVE-2026-45674 is a logic flaw (missing bailiwick validation), not a typical exploit that drops files or generates distinctive network signatures. As a result, there are no publicly available YARA rules, Sigma rules, Snort/Suricata IDS signatures, or traditional Indicators of Compromise at this time. Detection relies on two complementary approaches: dependency-level identification and code-level auditing.

Software Composition Analysis (SCA) and Dependency Scanning

The most practical method is SCA tooling that checks whether your projects depend on a vulnerable version of io.netty:netty-resolver-dns:

• GitHub Dependabot tracks this vulnerability under advisory GHSA-676x-f7gg-47vc. Repositories with Dependabot alerts enabled will surface this CVE automatically.
• Snyk catalogs the issue as SNYK-JAVA-IONETTY-17262734 and rates it high severity under "Insufficient Verification of Data Authenticity." The Snyk CLI or CI/CD integration will detect it during snyk test or snyk monitor runs.
• Docker Scout lists the CVE across multiple advisory sources and can identify container images that bundle the vulnerable Netty JAR. Running docker scout cves against your images will flag it.
• GitLab Dependency Scanning also indexes CVE-2026-45674 and will detect it in Maven-based projects during pipeline scans.

Tenable / Nessus Plugin Status

Tenable's plugin page for this CVE confirms there are currently no Nessus plugins for it. Scanners that rely on Tenable's plugin feed will not yet detect this issue through network-based or host-based scanning. This is expected to change once the NVD enrichment process completes.

Vulnerable Code Pattern Identification

For manual code audits or custom static analysis rules, the place to look is the buildAliasMap method of io.netty.resolver.dns.DnsResolveContext. In the vulnerable version, this method caches all CNAME records without checking that the CNAME owner name falls within the bailiwick of the original query. The fix, introduced in commit eeed84177eb584ff10bbfa7e0fe0ae233ee68a9d, changes the buildAliasMap method signature to accept the original queryName and adds the bailiwick check described in the Patch Information section. If you have forked or vendored Netty's DNS resolver, check whether your copy of DnsResolveContext.java includes this validation.

EPSS Context

The EPSS probability for this CVE is 0.00015 (4th percentile), and Docker Scout reports no known exploits in the wild. This suggests the priority should be SCA-based detection and proactive remediation rather than IoC hunting for incident response.

Affected Systems and Versions

The vulnerable Maven artifact is io.netty:netty-resolver-dns. The affected version ranges are:

Any application that uses Netty's built-in DNS resolver (the DnsNameResolver class and its associated DnsResolveContext) for outbound DNS resolution is affected, including applications that pull in Netty transitively through other frameworks and libraries. Automated scanners have flagged projects such as com.giffing.wicket.spring.boot.starter:wicket-spring-boot-starter because of their transitive Netty dependency.

Vendor Security History

The Netty project runs an active, transparent security disclosure process. On May 5, 2026, it published a coordinated batch of ten security advisories across a wide range of components:

Five of the ten were rated High severity, which reflects how much attack surface comes with a framework that handles so many network protocols. The DNS resolver alone has had three dedicated advisories (CVE-2026-45673, CVE-2026-45674, CVE-2026-47691), which suggests this component needed focused security hardening.

Netty publishes patches promptly alongside its advisories. The patched versions for CVE-2026-45674 were released on June 1 and 2, 2026, ten days before the NVD publication date of June 12, 2026.

References

• NVD: CVE-2026-45674
• GitHub Security Advisory: GHSA-676x-f7gg-47vc
• Netty 4.1.135.Final Release
• Netty 4.2.15.Final Release
• Pull Request #16873: Bailiwick Validation Fix
• Patch Commit 5749d782
• Patch Commit eeed84177
• GitLab Advisory: CVE-2026-45674
• Snyk: SNYK-JAVA-IONETTY-17262734
• Docker Scout: CVE-2026-45674
• Tenable: CVE-2026-45674
• Tenable Plugins: CVE-2026-45674
• Cybersecurity Help: SB2026060813
• Vulert: CVE-2026-45674
• CWE-345: Insufficient Verification of Data Authenticity
• GitLab Advisory: CVE-2026-45673 (Companion)
• GitLab Advisory: CVE-2026-47691 (Companion)
• GitHub Advisory: GHSA-xmv7-r254-6q78 (CVE-2026-45673)
• Netty Security Advisories
• Netty (Wikipedia)