CVE-2026-45674

What it actually does

Netty’s DNS resolver component did not correctly enforce DNS bailiwick rules for CNAME records. A malicious or manipulated DNS response could include a CNAME that redirects resolution outside the authoritative scope expected for the queried name, and vulnerable Netty versions could accept that answer. Applications that use Netty’s DNS resolver may therefore resolve trusted service names to attacker-controlled destinations. The practical impact can include traffic redirection, man-in-the-middle positioning, credential or token exposure, and data integrity compromise, especially for plaintext protocols, custom trust configurations, disabled hostname verification, or internal service-to-service traffic that relies heavily on DNS trust.

Why it matters to the business

Organizations using affected Netty versions may have applications silently connect to the wrong network destination when resolving hostnames. Because Netty is commonly embedded through frameworks, gateways, clients, and service runtimes, exposure may be indirect through transitive dependencies. Successful exploitation could allow interception or manipulation of application traffic, unauthorized access to sensitive data in transit, failed integrations, or operational disruption caused by misrouted service calls. The CVSS score is high, but exploitation requires favorable DNS manipulation conditions and there is no known KEV listing or mature public exploit indicated by the provided data.

How an attack unfolds

An attacker first needs a way to influence DNS answers seen by an application using Netty’s DNS resolver, such as operating a malicious DNS server used by the application, compromising an upstream resolver, spoofing DNS responses in a suitable network position, or inducing resolution through attacker-controlled DNS infrastructure. The attacker then crafts a DNS response for a legitimate queried hostname that includes a CNAME record pointing outside the expected DNS bailiwick. Because vulnerable Netty versions do not properly validate the CNAME origin, the resolver can follow or cache the attacker-supplied redirection and return an address controlled by the attacker. The application subsequently connects to the attacker-controlled endpoint while believing it resolved the intended service name. If transport security is weak, hostname verification is disabled, certificates are improperly trusted, or the protocol is not protected by TLS, the attacker may read or modify traffic. Even with strong TLS validation, the flaw can still cause connection failures or service disruption if traffic is redirected to an endpoint that cannot authenticate as the intended service.

How to fix it

Upgrade Netty to a patched release. For the 4.1.x line, upgrade to Netty 4.1.135.Final or later. For the 4.2.x line, upgrade to Netty 4.2.15.Final or later. Because Netty is often included transitively, update both direct and transitive dependencies in build manifests, dependency locks, containers, application servers, shaded JARs, and vendor-provided components. If immediate upgrade is not possible, reduce risk by using trusted DNS resolvers only, restricting egress DNS to approved resolvers, enforcing DNSSEC where applicable, enabling strong TLS certificate and hostname verification, avoiding plaintext service protocols, and monitoring for unexpected DNS CNAME chains or outbound connections to unapproved destinations. These mitigations reduce exploitability but do not replace upgrading.

How to confirm the fix worked

Confirm all deployed artifacts use Netty 4.1.135.Final or later on the 4.1 branch, or 4.2.15.Final or later on the 4.2 branch. Validate through dependency tooling such as Maven dependency:tree, Gradle dependencies, SBOM scans, container image scans, and runtime classpath inspection for netty-resolver-dns and related io.netty modules. Check for shaded or repackaged Netty copies inside application JARs. In a controlled test environment, configure a DNS server to return an out-of-bailiwick CNAME response for a test hostname and verify that the patched resolver rejects or does not trust the invalid CNAME chain. Also verify that outbound application connections still enforce TLS certificate and hostname validation after the upgrade.

Typical attack path

1. Identify an application or service that uses a vulnerable Netty DNS resolver version before 4.1.135.Final or 4.2.15.Final.
2. Gain the ability to influence DNS responses observed by that application, such as through a malicious resolver, compromised DNS path, local network spoofing, or attacker-controlled DNS delegation.
3. Wait for or trigger the application to resolve a target hostname used for outbound service communication.
4. Return a crafted DNS response containing a CNAME record whose origin is outside the valid bailiwick for the queried name.
5. Cause the vulnerable resolver to accept the out-of-bailiwick CNAME and resolve the name to attacker-controlled infrastructure.
6. Receive misdirected application traffic and attempt interception, credential capture, request manipulation, or denial of service depending on the protocol and TLS validation behavior.

How to detect it

There are no reliable exploit-specific indicators provided for this vulnerability, and successful exploitation may leave only normal-looking DNS and outbound connection records. To look for prior exploitation, review recursive DNS logs, endpoint DNS telemetry, application resolver logs, packet captures, and egress proxy or firewall logs for unusual CNAME chains associated with sensitive service names. Focus on CNAME responses that redirect from expected internal or trusted domains to unrelated external domains, newly registered domains, unexpected dynamic DNS providers, or destinations not previously contacted by the application. Correlate DNS answers with subsequent outbound connections from Netty-based applications to unexpected IP addresses or autonomous systems. Review application logs for TLS hostname mismatch errors, sudden certificate validation failures, unexplained connection resets, or traffic shifting to unfamiliar endpoints. If packet capture is available, inspect DNS responses for CNAME records whose owner name or target is outside the expected authoritative zone for the original query. Absence of these artifacts does not rule out exploitation, especially if DNS logs are unavailable or low-retention.

What your security team should do

• Prioritize inventory of all applications, services, containers, and third-party products that include Netty, especially those using netty-resolver-dns.
• Upgrade affected deployments to Netty 4.1.135.Final or later, or 4.2.15.Final or later, and rebuild artifacts that bundle or shade Netty.
• Review dependency locks and SBOMs for transitive Netty usage; do not rely only on top-level package manifests.
• Restrict DNS egress so workloads can query only approved internal or trusted recursive resolvers.
• Enable alerting for unusual CNAME chains, out-of-bailiwick DNS answers, and service traffic resolving to newly observed or unauthorized destinations.
• Confirm applications enforce TLS certificate validation and hostname verification for all service-to-service and external connections.
• Investigate recent DNS anomalies and unexpected outbound connections from Netty-based applications, particularly where DNS responses included CNAME redirection.
• Track vendor advisories for products embedding Netty and apply vendor-provided updates where direct dependency changes are not possible.