CVE-2026-47691: Netty DNS Cache Poisoning Vulnerability – Bailiwick Validation Bypass
Netty, a widely-used framework for building networked applications, contains a DNS cache poisoning vulnerability in how it validates nameserver records. An attacker who controls an authoritative nameserver for a subdomain can trick Netty into caching false DNS records for parent domains—such as the entire `.co.uk` domain. This happens because Netty's validation logic is too permissive: it accepts nameserver claims from subdomains without properly checking whether those subdomains should actually be trusted to answer queries about their parents. Once the cache is poisoned, all future DNS lookups under the parent domain serve the attacker's malicious responses.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.7 HIGH · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
- Weaknesses (CWE)
- CWE-345, CWE-346
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-12 / 2026-07-15
NVD description (verbatim)
Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates the bailiwick of NS records, enabling DNS Cache Poisoning. An attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains (like `.co.uk`). In `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` method accepts any NS record from the AUTHORITY section as long as the record's name is a suffix of the questionName. Subsequently, the `handleWithAdditional` method caches the associated A records from the ADDITIONAL section directly into the `authoritativeDnsServerCache` under the parent domain's key. This bypasses standard bailiwick rules, where a server authoritative for a subdomain should not be trusted to provide authoritative records for its parent. The poisoned cache is then used for all future resolutions under the parent domain's key. Versions 4.1.135.Final and 4.2.15.Final patch the issue.
11 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
The vulnerability exists in Netty's `DnsResolveContext.AuthoritativeNameServerList#add` method, which validates NS records from the AUTHORITY section of DNS responses using insufficient bailiwick enforcement. The method accepts any NS record whose name is a suffix of the question name, violating the principle that a nameserver authoritative for a subdomain should not be trusted for its parent domain. Subsequently, the `handleWithAdditional` method caches associated A records from the ADDITIONAL section directly into `authoritativeDnsServerCache` under the parent domain's key. This cached poisoned state persists and is reused for all future resolutions under that parent domain key. The flaw bypasses standard DNS security practices and enables cache persistence attacks. Affected versions prior to 4.1.135.Final and 4.2.15.Final.
Business impact
Organizations relying on Netty for DNS resolution in microservices, application servers, or protocol clients face exposure to DNS hijacking attacks. A successful exploit could redirect application traffic to attacker-controlled servers, enabling credential theft, malware delivery, or service disruption. The impact scales with deployment breadth: organizations with Netty deployed across multiple services or customer-facing applications face wider blast radius. Long-lived DNS cache pollution means attacks can persist across application restarts until patches are applied. Financial services, SaaS platforms, and any organization where DNS integrity is critical to service availability should treat this as high priority.
Affected systems
Netty versions prior to 4.1.135.Final (4.1.x branch) and prior to 4.2.15.Final (4.2.x branch) are vulnerable. Applications embedding Netty's DNS resolver component are affected. The vulnerability does not require Netty to be the system-wide DNS resolver; it impacts only DNS queries executed through Netty's `DnsResolveContext` within the application. Applications using Netty solely for non-DNS network protocols (TCP/UDP proxying, HTTP servers without custom DNS logic) are not affected unless they explicitly use Netty's DNS resolver.
Exploitability
Exploitation requires an attacker to control an authoritative nameserver for a subdomain and to position themselves on the network path or manipulate DNS responses. The CVSS score of 8.7 reflects HIGH severity with a vector indicating network-accessible attack, high complexity (AC:H—suggesting the attacker must craft responses to align with Netty's validation logic), no privileges required, and scope change with high impact to confidentiality and integrity. This is not trivial to exploit but feasible for a motivated attacker, especially in scenarios involving compromised hosting providers or rogue ISP infrastructure. The vulnerability is not currently listed in CISA's KEV catalog, suggesting either limited in-the-wild exploitation or recent discovery.
Remediation
Organizations must upgrade Netty to version 4.1.135.Final or later (for the 4.1.x branch) or 4.2.15.Final or later (for the 4.2.x branch). The patched versions enforce proper bailiwick validation, preventing subdomains from poisoning parent domain cache entries. Upgrades should be treated as critical within 30 days of deployment readiness. Organizations unable to upgrade immediately should review and limit DNS resolution through Netty to trusted, authenticated sources and consider using system-level DNS resolvers where feasible.
Patch guidance
Patch versions 4.1.135.Final and 4.2.15.Final address the bailiwick validation flaw. Verify these versions are available in your dependency repository (Maven Central, Gradle, etc.) before upgrading. For Maven projects, update the netty dependency version in pom.xml and run full regression testing on DNS resolution paths. For Gradle projects, update the version in build.gradle. Organizations on Netty 4.0.x or earlier should plan concurrent upgrades to 4.1.135.Final or newer. Test patches in a staging environment replicating production DNS patterns before deploying. No configuration workarounds mitigate this vulnerability; patching is mandatory.
Detection guidance
Monitor DNS queries originating from Netty applications for unusual patterns: sudden switches in authoritative nameservers for previously-stable domains, or A records that differ from known-good mappings. Enable application-level logging of `DnsResolveContext` cache entries if possible. Network intrusion detection can flag abnormal authoritative nameserver responses claiming authority over parent domains (e.g., a subdomain NS record claiming authority for a top-level domain). DNS query logs should be correlated with application behavior changes. After patching, validate that DNS resolution patterns normalize to pre-exploit baselines.
Why prioritize this
This vulnerability merits immediate prioritization due to its HIGH CVSS score (8.7), scope change impact, and the foundational role of DNS in application integrity. Unlike many vulnerabilities affecting a single feature, DNS cache poisoning undermines trust in all downstream communication. The vulnerability is not yet widely exploited (per KEV status), providing a window to patch before opportunistic attacks scale. Organizations with Netty deployments in customer-facing, payment-processing, or authentication services should prioritize within 1–2 weeks.
Risk score, explained
The CVSS 3.1 score of 8.7 reflects: (1) Network-accessible attack surface requiring no authentication; (2) High complexity reflecting the need for attacker control of a subdomain nameserver and network positioning; (3) Scope change—cache poisoning affects the entire parent domain, beyond just the targeted application; (4) High confidentiality impact (responses can be redirected to attacker infrastructure); (5) High integrity impact (DNS records are falsified). Severity stops short of 'CRITICAL' (9.0+) because exploitation requires some attacker capability and preconditions, not a trivial remote code execution.
Frequently asked questions
Does this vulnerability affect my application if we use system DNS (e.g., `/etc/resolv.conf`) instead of Netty's DNS resolver?
No. This vulnerability is specific to Netty's `DnsResolveContext` component. If your application delegates DNS queries to the operating system's resolver, you are not affected by this flaw. You are only at risk if your application code explicitly uses Netty's DNS resolver APIs.
Can an attacker exploit this without direct control of a nameserver?
Unlikely. Exploitation requires the attacker to either control an authoritative nameserver for a subdomain or intercept and modify DNS responses en route. Purely passive network eavesdropping is insufficient. In rare cases of compromised ISP infrastructure or rogue BGP hijacking, risk increases.
If we patch Netty, do we need to flush existing DNS caches or restart the application?
Patching resolves future cache poisoning attempts. However, if your application's cache is already poisoned before patching, the malicious entries may persist in memory until evicted or the application restarts. After patching, monitor the first few DNS queries to confirm resolution normalizes to legitimate nameservers.
What if we cannot upgrade Netty immediately due to dependency compatibility?
Conduct a compatibility analysis with your full dependency tree. Often, transitive updates are possible. If genuine blocking exists, consider network segmentation: restrict outbound DNS from your application to a curated set of trusted resolvers via firewall rules, reducing attack surface. Plan a timeline for upgrade; do not leave this vulnerability unaddressed long-term.
This analysis is based on CVE-2026-47691 data published by NVD and vendor advisories as of July 2026. CVSS scores and vulnerability details are subject to clarification by Netty maintainers. Organizations should verify patch availability and compatibility in their environment before deployment. This document does not constitute legal or compliance advice. For incident response or breach assessment, consult your security operations team or a qualified cybersecurity firm. SEC.co assumes no liability for patching decisions or outcomes arising from this guidance. Source: NVD (public-domain), retrieved 2026-07-20. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-45674HIGHNetty DNS CNAME Validation Bypass (CVSS 8.7 HIGH)
- CVE-2026-44894HIGHNetty QUIC Amplification Attack via NoQuicTokenHandler Default
- CVE-2022-4992HIGHDräger Infinity M540 Patient Monitor Network Message Vulnerability
- CVE-2026-10846HIGHNLnet Labs ldns DNS Spoofing Vulnerability - Off-Path Poisoning Attack
- CVE-2026-11693HIGHGoogle Chrome Site Isolation Bypass via Plugin Flaw
- CVE-2026-41577HIGHAuthentik SAML Assertion Validation Bypass (CWE-345)
- CVE-2026-41700HIGHSpring for GraphQL WebSocket Cross-Site Hijacking Vulnerability
- CVE-2026-42558HIGHXibo Stored XSS and Iframe Sandbox Escape in Data Connector