CVE-2026-47691

What it actually does

Netty's DNS resolver accepted out-of-bailiwick NS records from DNS AUTHORITY responses and cached associated ADDITIONAL A records under a parent-domain authority key. A malicious authoritative DNS server for a delegated subdomain could therefore cause Netty-based clients or servers using the affected resolver to treat attacker-supplied name servers as authoritative for a broader parent domain. Once poisoned, subsequent DNS lookups for names under that parent domain could be resolved through attacker-controlled infrastructure, enabling traffic redirection, interception, credential capture, or service impersonation depending on how the application uses DNS results.

Why it matters to the business

Applications that rely on affected Netty DNS resolution could be silently redirected to attacker-controlled systems, creating risk of data exposure, fraudulent transactions, failed integrations, and loss of trust in service-to-service communications. The issue has a high CVSS score because successful exploitation can compromise confidentiality and integrity, but the attack complexity is high, EPSS is currently low, no public exploit maturity is reported, and it is not listed in CISA KEV, so remediation should be prioritized for internet-facing, high-trust, or security-sensitive Netty deployments rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first controls an authoritative DNS server for a subdomain that a vulnerable Netty-based application is likely to resolve, such as through a domain they own, a delegated subdomain, or a user-influenced hostname lookup. When the application performs a DNS query using Netty's affected resolver, the attacker-controlled authoritative server returns a crafted DNS response containing NS records in the AUTHORITY section that refer to a parent domain rather than only the attacker's legitimate delegation scope. The response also includes corresponding A or AAAA records in the ADDITIONAL section pointing those name servers to attacker-controlled IP addresses. Because affected Netty versions insufficiently validate bailiwick boundaries, the resolver caches these attacker-supplied records under the parent domain's authoritative DNS server cache entry. Later lookups under that parent domain can be sent to or influenced by the attacker's name servers, allowing the attacker to redirect application connections to infrastructure they control. Follow-on impact depends on protocol protections: strong TLS hostname validation may block some impersonation attempts, while plaintext protocols, weak certificate validation, service discovery, webhook callbacks, metadata fetchers, or internal trust-by-DNS designs are at higher risk.

How to fix it

Upgrade Netty to a patched release: use Netty 4.1.135.Final or later on the 4.1.x line, or Netty 4.2.15.Final or later on the 4.2.x line. Ensure all Netty artifacts are aligned to the same fixed version, especially resolver-related modules such as netty-resolver-dns and transitive dependencies pulled in by frameworks, SDKs, RPC clients, API gateways, proxies, or reactive networking stacks. After upgrading, restart affected applications to clear in-memory DNS caches; where long-running resolver caches or custom caches are used, explicitly flush them. If immediate upgrade is not possible, reduce risk by routing DNS through trusted recursive resolvers, limiting application-driven resolution of untrusted hostnames, enforcing strict TLS hostname and certificate validation, restricting outbound connections to approved destinations, and monitoring for anomalous DNS authority responses. Mitigations should be considered temporary because the flaw is in resolver cache validation behavior.

How to confirm the fix worked

Confirm exposure by inventorying dependencies and verifying that no deployed application includes affected Netty versions earlier than 4.1.135.Final on the 4.1.x branch or earlier than 4.2.15.Final on the 4.2.x branch. Use build tooling such as Maven dependency:tree, Gradle dependencies/dependencyInsight, SBOM scans, container image scans, and runtime classpath inspection to find transitive Netty copies. Confirm remediation by verifying the runtime classpath contains the fixed Netty resolver artifacts and by restarting services so old resolver cache entries cannot persist in memory. For higher assurance, run a controlled DNS test in a non-production environment using a delegated test domain and an authoritative server that attempts to return parent-domain NS records with ADDITIONAL glue; patched versions should reject or avoid caching out-of-bailiwick authority data for the parent. Also verify application-layer safeguards such as TLS hostname validation and outbound destination allow-lists remain enforced.

Typical attack path

1. Identify a Netty-based application that performs DNS resolution through the affected Netty DNS resolver versions before 4.1.135.Final or 4.2.15.Final.
2. Cause the application to resolve a hostname in a domain or delegated subdomain whose authoritative DNS server is controlled by the attacker.
3. Return a crafted DNS response with misleading NS records in the AUTHORITY section for a broader parent domain and matching attacker-controlled A or AAAA records in the ADDITIONAL section.
4. Rely on the vulnerable Netty resolver to cache the attacker-supplied authoritative server information under the parent-domain key.
5. Wait for or trigger subsequent DNS lookups under the poisoned parent domain.
6. Redirect those lookups to attacker-controlled infrastructure to intercept, modify, or impersonate downstream communications where higher-layer protections do not prevent it.

How to detect it

Retrospective detection is difficult because the primary artifact is an in-memory DNS resolver cache entry that may disappear after restart. Review application logs, Netty resolver DEBUG or TRACE logs if enabled, DNS resolver logs, packet captures, egress DNS telemetry, proxy logs, firewall logs, TLS handshake logs, and application connection logs. Look for DNS responses where an authoritative server for a child domain returns NS records for a broader parent domain, especially when the ADDITIONAL section supplies A or AAAA records for those name servers. Investigate sudden changes where many unrelated hostnames under the same parent domain begin resolving to the same unusual IPs or networks, especially immediately after resolving a domain controlled by a third party. Correlate suspicious DNS activity with outbound connections to unexpected IP addresses, TLS certificate hostname mismatches, certificate validation failures, unusual SNI-to-IP relationships, HTTP Host headers that do not match expected infrastructure, authentication failures against known services, or traffic to newly observed autonomous systems. If packet capture is available, inspect AUTHORITY and ADDITIONAL sections for out-of-bailiwick glue. If runtime introspection is available, dump Netty authoritative DNS server cache state and compare cached name servers against known legitimate delegation data from public DNS. No named threat actors or ransomware campaigns are currently associated with this issue in the provided intelligence.

What your security team should do

• Prioritize upgrades for internet-facing services, API clients, service discovery components, proxies, gateways, and applications that resolve hostnames influenced by users, partners, webhooks, configuration, or external data feeds.
• Upgrade all Netty components to 4.1.135.Final or later, or 4.2.15.Final or later, and avoid mixed Netty module versions in the same application.
• Generate or refresh SBOMs and search for transitive Netty usage in Java applications, containers, vendor packages, and embedded SDKs.
• Restart remediated applications and flush any custom DNS caches after deployment to remove potentially poisoned in-memory entries.
• Enable DNS and egress telemetry for high-value applications so anomalous authority records, unexpected resolver destinations, and unusual connection targets can be investigated.
• Enforce TLS certificate and hostname validation and block plaintext or trust-by-DNS communication patterns where possible.
• If patching must be delayed, restrict DNS resolution to trusted recursive resolvers and limit outbound network access to approved IP ranges and domains.
• Because this is not currently in CISA KEV, has no reported exploit maturity, and has low EPSS, track it through expedited patch management rather than emergency incident response unless suspicious DNS or traffic anomalies are observed.