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

Introduction

A missing origin validation check in Netty's DNS resolver allowed crafted DNS responses to poison the internal CNAME cache, silently redirecting future domain resolutions to attacker controlled hosts. For any Java application relying on Netty's netty-resolver-dns module for outbound connections, and that includes transitive consumers across the ecosystems of Apple, Google, Netflix, Apache Hadoop, and Apache Spark, this vulnerability creates a path to invisible traffic interception without any direct compromise of the application itself.

Technical Information

Root Cause: Missing Bailiwick Validation in buildAliasMap

The vulnerability resides in the buildAliasMap method of io.netty.resolver.dns.DnsResolveContext, the class responsible for processing DNS query responses within Netty's resolver. When this method encounters CNAME (Canonical Name) records in the ANSWER section of a DNS response, it caches every CNAME record it finds without verifying whether the responding name server is actually authoritative for the domain referenced in the CNAME's owner name.

This missing check is called a "bailiwick validation." RFC 5452 explicitly mandates that DNS resolvers must only accept data if the originator is authoritative for the QNAME or a parent of the QNAME. Netty's resolver violated this requirement entirely: any CNAME record present in a DNS response would be cached as legitimate, regardless of its relationship to the original query.

The vulnerability is classified under CWE-345 (Insufficient Verification of Data Authenticity), defined by MITRE 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

The 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. This requires 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 constructs a DNS response to a legitimate query (for example, a query for x.netty.io) that includes additional CNAME records for unrelated domains. For instance, 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: Because the vulnerable buildAliasMap method does not validate whether each CNAME record falls within the authority boundary of the original query, both the legitimate and malicious CNAME records are cached.

4. Traffic redirection: Subsequent DNS resolutions that reference the poisoned cache entries will resolve to the attacker controlled destination. Downstream applications using the default Netty DNS resolver may then connect to malicious IPs, enabling traffic interception, credential theft, or data exfiltration.

CVSS Vector Analysis

The CVSS v3.1 base score of 8.7 (HIGH) with vector AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N breaks down as follows:

The "Changed" scope is particularly significant here: the poisoned DNS cache affects not just the resolver itself but any downstream component that relies on it for name resolution.

Amplification via Companion Vulnerabilities

CVE-2026-45674 does not exist in isolation. Two companion vulnerabilities in the same netty-resolver-dns module significantly affect the overall risk profile:

CVE-2026-45673 addresses a predictable PRNG and default static source port in Netty's DNS resolver, enabling classic Kaminsky style DNS cache poisoning. An attacker who leverages CVE-2026-45673 to predict DNS transaction IDs and send spoofed responses from a static source port can then exploit CVE-2026-45674 to have out of bailiwick CNAME records accepted and cached. This chaining transforms two individually complex exploits into a more feasible combined attack.

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

All three CVEs share the same patched versions (4.1.135.Final and 4.2.15.Final), and organizations should address them simultaneously.

Patch Information

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

What Changed

The core fix introduces a bailiwick validation check into the buildAliasMap method of DnsResolveContext.java. The method signature was updated to accept the original query name as a new parameter. Before writing a CNAME mapping into the cache, the method now verifies 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);
}

This logic ensures that if you issue a query for x.netty.io, a CNAME record with an owner name of x.netty.io (exact match) is legitimate and will be cached. A CNAME for a subdomain like sub.x.netty.io (ends with .x.netty.io.) would also pass the check. However, a CNAME record for an unrelated domain like evil.com will fail both conditions and be silently discarded.

The two call sites in DnsResolveContext.java that invoke buildAliasMap were updated to pass the question name through:

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

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

This change covers both the explicit CNAME query path (onResponseCNAME) and the A/AAAA resolution path (onExpectedResponse), ensuring complete coverage.

Regression Test

The commit also adds a unit test (testCnameCacheBailiwick) in DnsNameResolverTest.java. The test stands up 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 while the out of bailiwick mapping is correctly rejected: 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

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

Software Composition Analysis (SCA) and Dependency Scanning

The most practical detection method is to use SCA tooling to identify 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, classifying it as 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 impacted container images that bundle the vulnerable Netty JAR. Running docker scout cves against your images will flag this issue.
• GitLab Dependency Scanning also indexes CVE-2026-45674 and will detect it in Maven based projects during pipeline scans.

Tenable / Nessus Plugin Status

As confirmed from Tenable's plugin page for this CVE, there are currently no Nessus plugins available. Vulnerability scanners relying on Tenable's plugin feed will not yet detect this issue through network or host based scanning. This is expected to change as the NVD enrichment process completes.

Vulnerable Code Pattern Identification

For teams performing manual code audits or writing custom static analysis rules, the vulnerability resides specifically in the buildAliasMap method of io.netty.resolver.dns.DnsResolveContext. In the vulnerable version, this method caches all CNAME records without verifying that the CNAME owner name falls within the bailiwick of the original query. The fix, introduced in commit eeed84177eb584ff10bbfa7e0fe0ae233ee68a9d, modifies the buildAliasMap method signature to accept the original queryName and adds the bailiwick check described in the Patch Information section. If your codebase has forked or vendored Netty's DNS resolver, inspect whether your version 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 that SCA based detection for proactive remediation is the priority rather than incident response oriented IoC hunting.

Affected Systems and Versions

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

Any application that uses Netty's built in DNS resolver (the DnsNameResolver class and its associated DnsResolveContext) for outbound DNS resolution is affected. This includes applications that consume Netty transitively through other frameworks and libraries. Notably, projects like com.giffing.wicket.spring.boot.starter:wicket-spring-boot-starter have been flagged by automated scanners due to their transitive Netty dependency.

Vendor Security History

The Netty project maintains an active and transparent security disclosure process. On May 5, 2026, the project published a coordinated batch of ten security advisories covering a wide range of components:

Five of the ten advisories were rated High severity, reflecting the breadth of attack surface inherent in a framework that handles diverse network protocols. The DNS resolver subsystem specifically has seen three dedicated advisories (CVE-2026-45673, CVE-2026-45674, CVE-2026-47691), suggesting this component required focused security hardening.

The Netty project publishes patches promptly alongside 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)